February 2005 - Test - lists.nanog.org

Spoofing and Internet Filtering
by Robert Beverly 28 Mar '05

28 Mar '05

Hi all, I'm working on a project designed to determine the extent of ingress and egress filtering on the Internet. Specifically interested in the ability to forge headers and source spoofed packets. The project relies on clients running an active measurement program from as wide a distribution of netblocks as possible. If you're curious about your connection, your upstream or how prevalent filtering is on other's networks, try out the source or one of the binaries from: http://momo.lcs.mit.edu/spoofer/ Many more details of the program, methodology and current results are on the web site as well. Thanks! rob

1 1

NANOG 33 (Las Vegas) Meeting Information
by Carol Wadsworth 15 Mar '05

15 Mar '05

Registration is now open for the NANOG 33 meeting, January 30-February 1, 2005 in Las Vegas, Nevada. The meeting will be hosted by UltraDNS and will be held at The Rio. Please see www.nanog.org for additional meeting information. See you there!

1 1

Announcing the 2005 NANOG Program Survey
by Steve Feldman 03 Mar '05

03 Mar '05

In light of the recent discussions about the future direction of NANOG, the program committee would like your input on the area we can affect the most: the content of NANOG meetings. We have created a short survey, and would like to invite all NANOG list subscribers to participate. We're interested in everyone's thoughts, including those of you who have never attended a meeting. The survey can be reached via the "Community Survey" link on http://www.nanog.org/surveys.html If you have any questions about the content of the servey, feel free contact me or the whole program committee (nanogpc(a)nanog.org) For any technical issues, contact me directly; I'm the one who threw this together, so any bugs are my fault. Thanks for your time, Steve (for the pc)

1 1

AOL scomp
by Edward B. Dreger 02 Mar '05

02 Mar '05

Can AOL's "this is spam" feedback loop be abused with a single person responding to a single message many, many times? Inquiring minds want to know. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

22 31

Why do so few mail providers support Port 587?
by Sean Donelan 02 Mar '05

02 Mar '05

Although RFC2476 was published in December 1998, its amazing how few mail providers support the Message Submission protocol for e-mail on Port 587. Even odder, some mail providers use other ports such as 26 or 2525, but not the RFC recommended Port 587 for remote authenticated mail access for users. Large mail providers like AOL, GMAIL and Yahoo support authenticated mail on port 587; and some also support Port 465 for legacy SMTP/SSL. But a lot of universities and smaller mail providers don't. They still use SMTP Port 25 for roaming users. With AT&T, Earthlink, COX, Netzero and other ISPs filtering port 25 for years, I would have thought most mail providers would have started supporting Port 587 by now. What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587? What can be done to encourage the mail client software programers (i.e. Outlook, Eudora, etc) to make Port 587 the default (or at least the first try) and let the user change it back to port 25 (or automatically fallback) if they are still using a legacy mail server. Sendmail now includes Port 587, although some people disagree how its done. But Exchange and other mail servers are still difficult for system administrators to configure Port 587 (if it doesn't say click here for Port 587 during the Windows installer, its too complicated).

46 118

High volume WHOIS queries
by Dan Lockwood 02 Mar '05

02 Mar '05

I'm in a disagreement with ARIN about my application for bulk whois data. I've got a software program that needs resolve AS numbers to the Company Name of the owner. The software app has need to do this on a very high volume. E.g. I run a report that returns the top 100 AS destinations for my network and I want to resolve the numbers to the names as part of the report generation. Since ARIN throttles the number of queries that you can execute against their servers I seems to "just make sense" that you would do the processing using local data. That is all fine and good, but the problem comes when I distribute the software to users. ARIN's AUP for bulk whois states: "Redistributing bulk ARIN WHOIS data is explicitly forbidden. It is permissible to publish the data on an individual query or small number of queries at a time basis, as long as reasonable precautions are taken to prevent automated querying by database harvesters." My original AUP application stated that I would transfer the data to the users using an XML file on a regular basis. Clearly in violation of the first point. Fine. But now after a phone conversation they are telling me that I can not operate a server to distribute the data on a "per query" basis too. Providing a server that answers whois queries just like ARIN seems to be clearly permissible based on the remaining AUP verbage. At this point the only thing I can get out of the guy/gal on the phone is "NO!". Does anyone have any experience doing something like this? How about a sanity check? Am I completely wrong in how I'm interpreting the AUP? Thanks, Dan

8 7

RE: Why do so few mail providers support Port 587?
by Hannigan, Martin 02 Mar '05

02 Mar '05

Hi Folks, It's time to take this thread to SPAM-L or some other spam oriented list. Thanks in advance, -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > just me > Sent: Friday, February 25, 2005 5:26 PM > To: Frank Louwers > Cc: nanog(a)merit.edu > Subject: Re: Why do so few mail providers support Port 587? > > > > On Fri, 25 Feb 2005, Frank Louwers wrote: > > The trick is to config port 587 in such a way that it ONLY accepts > smtp-auth mail, not regular smtp. > > That way, virii/spam junk won't be able to use that port. > > What are you, stupid? The spammers have drone armies of machines > with completely compromised operating systems. What makes you think > that their mail credentials will be hard to obtain? > > matt ghali > > --matt(a)snark.net------------------------------------------<darwin>< > The only thing necessary for the triumph > of evil is for good men to do nothing. - Edmund Burke >

3 2

SMTP Port Blocking: Success or Failure?
by Claydon, Tom 28 Feb '05

28 Feb '05

We are considering filtering outbound SMTP traffic from our ISP customers, except from our own mail servers, to help reduce the amount of spam originating from our network. How successful/unsucessful has implementing outbound SMTP filtering done in stopping or slowing down spam from your network? Also, if outbound SMTP filtering has not worked for you, are there any other things that you have implemented that have helped with spam traffic? Thanks, = TC -- Tom Claydon, IT/ATM Network Engineer Dobson Telephone Company http://www.dobsonteleco.com

8 7

SNMP-ALG
by Tomas Daniska 28 Feb '05

28 Feb '05

Hi, can anyone recommend me anything that supports SNMP-ALG as per RFC2692? So far I only managed to find netfilter/iptables should support it, via a long-time no-progress plugin. However, the plugin simply does not seem to work (I've done loads of debugging, and as well I only managed to find other people complaining about the same symptoms, with no hints on how to resolve the issue). I'll post a summary to the list so direct reply is preferable. Thanks! -- Tomas Daniska systems engineer Tronet, a.s. Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 Nobody ever got rich by telling the American public that what they had was good enough and that they really didn't need anything better! -- Bob Atkins

1 0

Re: AOL scomp
by Robert Bonomi 26 Feb '05

26 Feb '05

> From owner-nanog(a)merit.edu Sat Feb 26 13:42:19 2005 > Date: Sat, 26 Feb 2005 10:27:40 -0500 > From: Rich Kulawiec <rsk(a)gsp.org> > To: nanog(a)merit.org > Subject: Re: AOL scomp > > > On Fri, Feb 25, 2005 at 01:34:21AM -0600, Robert Bonomi wrote: > > Because the recipient *expressly* requested that "all mail which would reach > > my inbox on your system be sent to me at AOL (or any other "somewhere else"). > > I have three somewhat-overlapping responses to that -- and I'll try to > stay focused on operational issues, since this is NANOG, not Spam-L. > (But if you to delve further into this, I would suggest shifting the > discussion there, as it's probably more appropriate.) > > 1. SMTP spam is not mail. "Spam -- it's about _consent_, not *content*." If I, the forwarding system operator have the _consent_ of the mailbox owner on the destination system to forward messages to him, they are *not* spam on _that_ system. This *is* a separaate issue as to whether or not they are spam _on_the_forwarding_system_. Yes, the forwarding system should do everything "reasonable" to suppress spam from (a) reaching the local inbox *or* (b) being forwarded, if the customer has requested mail forwarding. If the recipient has a problem with receiving the forwarded message, he should complain _to_the_FORWARDING_system_ about it. *NOT* to the destinaiton system. > So while the end user on some remote system may have in fact said > "send me everything, including the spam" (although this seems very > unlikely) How about various 'spamtrap' mailboxes, auto-forwarded to a central location for "further processing"? <evil grin> > > This means that every such message from the 'forwarding' system to the > > destination system is, BY DEFINITON, "solicited". The mailbox owner has > > expressly and explicictly requested those messages be sent to him at the > > receiving system. > > This is a definition of "solicited" which is wholly at odds with that > in common practice for the last few decades. By your definition, > the victim of a mailbombing attack would have somehow "solicited" that > abuse merely because they have a forwarding alias on your system. NOT AT ALL. It *IS* 'unsolicited' on _my_ system. It is *not* unsolicited at the final destination system. Questions/complaints/help-requests should be sent *TO*ME*, not to the destination system. He's *MY* customer, too. I've got an incentive to 'make things right'. > I'm not having any. UBE (the proper definition of SMTP spam) doesn't > magically become not-UBE just because it gets forwarded by somebody. Suppose my user "manually" forwards a 'spam' message to an account of his on another system. And then _forgets_ that *he* did it. And reports it to *that* provider as spam coming from my system. Is this _my_ fault? IS spam originating from my system? Should I terminate this user for 'spamming'? > It's still spam, and anyone sending/forwarding it is personally > responsible for their choice to do so. "It's about *consent*, not _content_." Want to try to deny that the recipient _consented_ to the forwarding from his other account? It is _not_ 'unsolicited' (the first word of UBE / UCE) on the destination system. It *may*well* be 'unsolicited' at the system where the customer has the forwarding mailbox. Complaints should be directed to *THAT* system operator, *not* the operator of the destination system. Note: I *agree* that "anyone sending/forwarding it is personally responsible fortheri choice to do so." The person that *made* that choice -- to forward that message -- however, is _the_customer_; the 'owner' of mailbox on the 'forwarding' system, *and* the 'owner' of the mailbox on the destination system. If "my customer" (in his identity on the receiving system) reports "my customer" (in his identity on _my_ system) as sending spam, should I terminate him from my system? After all, he's identified _himself_ as the spammer. > (Yes, I realize that it's not possible to achieve perfection, but that > isn't an excuse for failure to keep trying, continuously. It's not > difficult to block 90% of spam using simple, free measures that rely > entirely on open-source software and freely-accessible data. There's > thus no valid excuse for not doing at least that much -- today.) Yup. Keep it from getting to the point it 'would' get to his inbox, and it won't get forwarded, either. But, if it _does_ get through, the recipient should be complaining about it _to_me_, not to the operator of the destination system.

1 0