- Test - lists.nanog.org

Re: williams spamhaus blacklist
by jlewis＠lewis.org 25 Sep '03

25 Sep '03

On Wed, 24 Sep 2003, Leo Bicknell wrote: > What you're missing in my argument is that it doesn't matter. I > have no idea who Eddy Marin is, nor do I care. Blocking wcg's > corporate mail servers is not the solution. Sure, it may get > someone's attention at wcg, but it may also harm a lot of "innocent" > communications, sales talking to clients, other wiltel customers > requesting support, heck, the secretary ordering lunch to be > delivered. But it's ok when AboveNet does it?...or actually does much worse by secretly and arbitrarily blackholing various networks at will, while advertising connectivity to those networks to their BGP customers and peers? This means anyone connected to AboveNet will be unable to reach those blackholed victims if the routes to those destinations propogated by AboveNet appear to be their "best route" to the affected networks. This breaks connectivity even though we have multiple other transit providers. This is much worse than a Spamhaus (or any other DNSBL) listing since anyone using such services does so by choice and can decide for themself what action to take, if any, for listed addresses. With AboveNet blackhole routing, our only option, once we're aware of the problem, is to make changes to our routing policy and force traffic away from AboveNet and onto one of our other transit providers. We only find out about such AboveNet blackhole routes when we open a ticket with AboveNet to ask why your network is broken when our customers complain of networks they can't reach when using our service (i.e. banks that can't reach their staff training web sites), but they can reach from other service providers, so they inform us that our network is broken. Who's attention is AboveNet trying to get? Anyone taking BGP routes from AboveNet, or worse yet, single homed to AboveNet, ought to be aware of this policy. At the very least, you should make sure whoever does your BGP is aware of it and knows how to reroute traffic when the "best route" doesn't actually work. You also might bring it up with your sales person when it's time to renew. The central image on www.above.net boasts of "Unconstrained Information Exchange". I wish that were true. ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

3 2

RE: What about joe-jobs?
by Darren Foo 25 Sep '03

25 Sep '03

>Speaking of joe-jobs, what's the "proper" proceedure > for >dealing with such? The company I work for is > currently >undergoing an admitedly minor joe-job. > (about 300 or so >bounces that I've seen since mid > last week or so.) > > Any suggestions for dealing with this? What domains are you seeing the joe-jobs from? We > see alot of joe jobbing attacks from the large webmail providers eg. yahoo.com, hotmail.com, aol.com, netscape.net, etc. A promising response that we've been following is Sender Permitted From http://spf.pobox.com . It's basically a reverse RBL. The owner of a domain identifies ip's that are allowed to send mail for that domain in a TXT DNS record. The rest are tagged with a wildcard deny or probably softdeny initially. If yahoo.com, hotmail.com etc alone just added the DNS records, we'd all be able to identify joe-jobbers of these domains. It won't help their own spam situation but it'd help our massive attacks of spoofed email. Spammers seem to use these big providers since blocking all of hotmail.com or yahoo.com is tough for other providers.

3 3

RE: Re[2]: williams spamhaus blacklist
by netadm 25 Sep '03

25 Sep '03

>> Ehm, that was because you, infolink.com WERE the spam outfit, of >> course we block your 'entire network', it was an entire network of >> spammers with no real customers. You can pretend Infolink is an >> 'EyeEshPee' all you like Mr Leary but what we see is this, from your >> ROKSO record: >> This is exactly the problem with certain e-mail block lists (i.e. www.spamhaus.org) A few zealots who control this particular block list have made a decision based on inaccurate information. Mr. Linford has listed (in his block list) 48 /24s allocated to Infolink (yes we are a real ISP with real customers) for 2 customers we are working to terminate. In addition, as previously mentioned, Mr. Linford refuses to remove listings once we notify him of the termination. Given the above, it is imprudent for any network operator (North American or Other) to use Mr. Linford's SBL to restrict the delivery of e-mail. Dynamic block lists such as Spamcop will be much more effective at blocking spam, while allowing normal e-mail to flow as it should. Jon Ham/Infolink Network Administration Toll Free (USA) +1 877 293 2095 ext. 1422 Tel. +1 305 324 1616 ext. 1422 www.infolink.com

2 1

Experience with McLeodUSA
by Carrara, Richard 25 Sep '03

25 Sep '03

I am looking into a point-to-point DS3 from McLeodUSA in the Dallas/Ft. Worth area and was wondering what type of experience anyone on the list has had with them? Customer service, billing, response to issues, etc. Any information would be greatly appreciated! Thanks, Richard

1 0

Re: VeriSign SMTP reject server updated
by Gregory Hicks 25 Sep '03

25 Sep '03

> Date: Thu, 25 Sep 2003 11:12:05 -0400 (EDT) > From: Gerald <gcoon(a)inch.com> [...snip...] > > Ugh...sucked in. Can we get back to network operation discussions. Someone > make a Verisign gripe/commiserate list. I'll sign up. nanog-offtopic(a)lists.blank.org ...? Regards, Gregory Hicks > > G > > - How are ya? Never been better, ... Just once I'd like to be better. ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. Just because "We've always done it that way" is not necessarily a good reason to continue to do so... Grace Hopper, Rear Admiral, United States Navy

1 0

Nothing like viruses with bugs in them (Swen)
by Mark Radabaugh 25 Sep '03

25 Sep '03

Seems like this virus/worm has a bug where it will occasionally send out 1 byte attachments rather than the correct worm payload. Since the virus is not truly attached it tends to pass through e-mail virus scanners. It's causing a fair amount of end user confusion today -- lots of 'why is your/my virus scanner not working?' questions. Mark Radabaugh Amplex (419) 720-3635

7 7

VeriSign SMTP reject server updated
by Matt Larson 25 Sep '03

25 Sep '03

Folks, One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. This server was designed to be the most modest of SMTP implementations and supported only the most common sequence of SMTP commands. In response to this feedback, we have deployed an alternate SMTP implementation using Postfix that should address many of the concerns we've heard. Like snubby, this server rejects any mail sent to it (by returning 550 in response to any number of RCPT TO commands). We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. In fact, to achieve sufficient performance, all logging has been disabled. We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we are considering is rejecting the SMTP transaction by returning a 554 response code as described in Section 3.1 of RFC 2821. Our concern is if this response effectively causes most SMTP servers to bounce the message, which is the desired reaction. We are researching common SMTP servers' handling of this response code; at least one popular server appears to requeue mail after receiving 554. Another option is remaining with the more standard SMTP sequence (returning 250 in response to HELO/EHLO), but then returning 550 in response to MAIL FROM as well as RCPT TO. I would welcome feedback on these options sent to me privately or the list; I will summarize the former. Matt -- Matt Larson <mlarson(a)verisign.com> VeriSign Naming and Directory Services

29 36

RE: Re[2]: williams spamhaus blacklist
by netadm 25 Sep '03

25 Sep '03

>> That describes the escalation procedure of SPEWS, but is not at all >> accurate for the SBL, we do not expand listings sideways into >> customer space or block whole ISPs [*]. >> Mr. Linford's Spamhaus has recently blocked our entire ISP because of 2 entities on our network we are working to terminate (it is a bit more complicated than simply pulling the plug). In addition, we have recently requested removal of listings once we have terminated the customer in question, but received no response. We can vouch for the fact that www.spamhaus.org blocks far more than just sources of UCE. In our case, it is our entire network. -----Original Message----- From: Steve Linford [mailto:linford@spamhaus.org] Sent: Thursday, September 25, 2003 8:22 AM To: Hank Nussbacher; nanog(a)merit.edu Subject: Re[2]: williams spamhaus blacklist At 12:50 +0200 (GMT) 25/9/03, Hank Nussbacher wrote: > AS3339 has a zero tolerance for spamming. With just one spam > complaint we block the IP in question. We have a downstream customer > that has many cybercafes in Africa that generate http and smtp spam > and we block each complaint within 48 hours. > > None the less, here is a recent email extract I received from > someone: > > "Hank, I am not a Spamhaus.org representative in any shape or form. > I do not claim to speak for Spamhaus.org in any capacity. The > University of xxxxxx is, however, a customer (i.e. as of this > morning, we block e-mails from IP addresses listed on Spamhaus SBL). > > I am just guessing what might happen if the problem is not sorted > out. > > I am sure you already know that the standard escalation procedure for > many blocklists is first to block the single offending IP address, > then the immediate smallest block that it is contained in according > to WHOIS, then the entire block of the ISP, and if that fails to stop > the spam, then the corporate MXes of the upstream ISP may be > blocklisted." That describes the escalation procedure of SPEWS, but is not at all accurate for the SBL, we do not expand listings sideways into customer space or block whole ISPs [*]. > Basically, we are being told if we don't drop the customer, our > corporate MXes will be blocked. I would not call this an "extreme > case", but it would appear that overzealous anti-spammers are perhaps > going a bit overboard. Luckily he claimed up-front to not be speaking for Spamhaus. I can sympathize with the level of frustration of someone being bombarded in spam, however we do not run escalations for single spammers (unless the problem is chronic, but even then we'd always contact the ISP and exhaust all other avenues). [*] Although we do not list whole U.S. or European ISPs, that's not strictly true for other areas of the net the "offshore" spammers have gravitated to. We are currently leaning on China heavily and are at this moment blocking large parts of Chinanet Shanghai (online.sh.cn) ADSL netblocks, as it's the worst of the China spam problems with 120 separate SBL listings all of US-based spammers (all the usual make-penis-fast crowd) hosted mainly on Shanghai ADSL lines. Spammers like Alan Ralsky these days pump everything out via SoBig-opened proxies with everything hosted in China, all run from Detroit using VPN. The Chinese are now understanding this but it's taken some time. That escalation should resolve itself 'any moment now' too as they say they're starting the process of tracking down and kicking off the hoard of pests they've acquired these last months. -- Steve Linford The Spamhaus Project http://www.spamhaus.org

2 1

Latency between Global Crossing & AT&T
by Steven Schecter 25 Sep '03

25 Sep '03

Has anyone noticed excessively high latency between Global Crossing and AT&T? From what I've gathered, the PNIs between Global Crossing and AT&T are completely maxed out. The word is AT&T will not increase peering capacity with Global Crossing since their in bankruptcy protection. I am certain that this is affecting a large number of both Global Crossing and AT&T customers. I think it's fair to say that both Global Crossing and AT&T are amongst the larger Tier 1 providers out there, it's shameful that they can't come to an agreement on upgrading capacity. bash-2.05a$ traceroute www.att.net traceroute to www.att.net (204.127.166.135), 64 hops max, 40 byte packets [..] 4 0.so-0-2-0.gbr2.nwr.nac.net (209.123.11.234) 1.991 ms 2.254 ms 1.908 ms 5 5.ge-0-0-0.gbr1.nwr.nac.net (209.123.11.221) 2.063 ms 10.506 ms 2.075 ms 6 so-0-2-1.ar1.JFK1.gblx.net (64.211.83.61) 2.576 ms 2.704 ms 4.343 ms 7 pos3-0-2488M.cr2.JFK1.gblx.net (67.17.72.17) 2.564 ms 2.577 ms 2.125 ms 8 pos0-0-2488M.cr2.NYC1.gblx.net (67.17.64.138) 2.681 ms 2.698 ms 2.270 ms 9 so6-0-0-2488M.ar2.NYC1.gblx.net (67.17.64.158) 2.760 ms 2.724 ms 2.748 ms 10 208.51.134.6 (208.51.134.6) 144.483 ms 146.267 ms 143.238 ms 11 tbr1-p011601.n54ny.ip.att.net (12.123.1.122) 148.627 ms 153.665 ms 150.902 ms 12 tbr1-cl1.cgcil.ip.att.net (12.122.10.2) 171.625 ms 175.044 ms 170.965 ms 13 tbr2-p012501.cgcil.ip.att.net (12.122.9.134) 175.628 ms 172.361 ms 174.355 ms 14 tbr2-cl7.sl9mo.ip.att.net (12.122.10.46) 179.093 ms^C regards, /sjs -- Steven J. Schecter :: Just a spoon full of MEDs <sjs(a)nac.net> :: make the routes flow down

4 3

RE: Proposed changes to the AUP.
by Wesley Vaux 25 Sep '03

25 Sep '03

owner-nanog(a)merit.edu is sending me virus infected emails. Wes Vaux, CCNA, CCDA Network Security Engineer, 9000 Regency Pkwy Ste 500 Cary, NC 27511 t 919.463.6782 f 919.463.1290 Global Knowledge Experts Teaching Experts http://www.globalknowledge.com -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Thursday, September 25, 2003 10:13 AM To: nanog(a)merit.edu Subject: Proposed changes to the AUP. Two recent e-mails made me take a new look at the Nanog AUP, and I'd like to propose several changes to help clarify the policy. Several recent discussions have descended into the weeds. I'll take my share of the blame for my participation. That said, one on-list event, and several off list events have raised some lingering questions about the Nanog AUP and how it is enforced. I believe that there are a couple of changes to the AUP that would help prevent these threads from happening, and those are the issues I want to raise. If you're not familiar, the AUP is at http://www.nanog.org/aup.thml. I suspect many of you have no idea how the Nanog AUP is enforced, so I will go into that first. Moments ago we saw a glimpse on the list. The first attachment to my message (it's not in the archive yet to give you a URL) entitled "srh-jrace" is a copy of an e-mail I believe Susan accidently copied to nanog(a)merit.edu. If you look at the CC list you'll see the intended target was nanog-support(a)merit.edu. To help show that assumption is probably correct, I attach three more messages, first, second, and third. These are three cases, in chronological order, where I have been given similar warnings for AUP violations. For full context, these three messages were part of the following threads: first - http://www.cctec.com/maillists/nanog/historical/0109/threads.html#01538 second - http://www.cctec.com/maillists/nanog/historical/0110/threads.html#00577 (Note, there are at least three other thread roots right under it as some follow ups didn't get attributed correctly.) third - http://www.merit.edu/mail.archives/nanog/threads.html#14454 To be clear, I'm not trying to "appeal my conviction" on any of these, the first thread clearly drifted way off topic, the second I clearly mention the law and politics. The third gives me a bit more trouble, as the reason I posted was to see if anyone could operationally use this new (admittedly legal) tool, but heck, it was about law so I'm ok with being wrong on that one. I show you these as I am unhappy about the method by which these were handled. So, what are my proposals? Simple: 1) Change item 6 on http://www.nanog.org/aup.html to read "prohibited" rather than "discouraged". Discouraged suggests to me general discussion about those topics is bad, but if it has operational significance or general interest on the list it may still be appropriate. However, it appears that there is no clear way to define what would or would not be appropriate, and that the enforcement is more in line with prohibited. Changing that one word should make it much more clear, and remove all doubt. Most likely item #3 should also be prohibited and not discouraged as well. 2) The current AUP states: ] Individuals who violate these guidelines will be contacted personally ] and asked to adhere to the guidelines. If an individual persists ] in violating the guidelines, the convener of NANOG, Merit Network, ] Inc., will take action to filter the offender's messages to the ] list. I have several problems with this: * There is no way for the nanog membership to review that the policy is being applied evenly and fairly. * Where there are ambiguities in the appropriateness of a topic there is no way to know that the moderators are using the same criteria the general membership would use. * It does nothing to educate other mailing list participants as to what is or is not appropriate. This method provides a gentle and constant reminder of the AUP that always provides new and relevant examples. * It does nothing to stop the thread. Several people have received these after others for the same thread -- I think we all have an implicit assumption that if it's allowed to continue by the moderators it must be ok to reply. To that end, I propose the following new method of handling things, which I believe is more in-line with what other mailing lists do: When inappropriate messages are sent to the list the convener will reply both to the list and to the poster pointing out that the topic is in violation of the AUP and should cease. Chronic offenders will be notified personally that their messages may be filtered or that they may be removed from the list as deemed appropriate by the conveners. -- Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

1 0