- Test - lists.nanog.org

OPERATIONAL Question - Spamblock protocol
by Karl Denninger 19 Nov '97

19 Nov '97

Hi folks, I have an actual, no-bullshit operational opinion question relating to spamming and spamblocking :-) I'm working on the "intelligent bounce" software here for our spamblocker. Right now we don't support bounces for spamblocked messages, for the reason that the headers are often forged and thus the cycles to do this are wasted (or annoying the wrong person). Also, queueing the bounce back through Sendmail is usually a *bad* thing to do, because sendmail is way to aggressive in trying to deliver mail when you really want to make one pass at it and then give up. So I'm having the spamblocker dump the spam into a different place, where I then pick it up and post-process it to try to send the bounces back. The problem is the algorythm. My options appear to be: 1) Go to the "From" line WITHOUT MX resolution, and deliver there. If it fails, go to the relay which connected to us and send to {postmaster|abuse}. Advantages: We try to hit the exact machine the mail claims to be from. There's a good chance that if it DOES have an SMTP listener on it we'll get back a good reply to the RCPT TO command (either positive or negative). Disadvantages: Many sites don't run SMTP listeners on their machines which resolve to the domain name in the headers, and some don't even HAVE such a machine mapped with an "A" record to send to. This will send to abuse and postmaster where a real person might be reachable otherwise. 2) Go to the From line WITH MX resolution. I've already figured out that hitting secondary MXs is a bad idea, for the simple reason that most of them will say "220" to anything in the domain they're secondarying for, and what you REALLY want is to get back 400 or 500 errors if the username is forged (as it frequently is) so you can then hit the relay abuse address INSTEAD. Advantages: This follows most closely the real Internet standards practice. Its still not 100% complient, but again, we don't care if we're "wrong" in the area of failing to deliver one of these bounces. Disadvantages: The lookup time is non-trivial, and if the FROM line is forged you're going to harass the wrong person with the bounce. The second problem is particularly severe, since a "bad guy" can now pick on someone like "President(a)whitehouse.gov" and you're going to send the bounces to Mr. Clinton. Once its figured out what you're doing, now these spammers have a nice denial-of-service attack they can launch. This is already being done to some extent, and I'm not sure that its a good idea to give them more fuel. 3) Screw the From line and hit the relay site directly; try to deliver to the user there, and if it fails then hit abuse and postmaster instead. Don't bother trying to look up the From line on the premise that its forged anyway. Advantages: The relay site either has an SMTP server on it or it does not. If it does, then you just got to someone who SHOULD be able to put a stop to it. If it does not, then you're wasting your time ANYWAY, but you probably know about it almost immediately when it comes back with an RST to your SYN. If its some jerk on a dialup dynamic address account you'll probably time out (unless someone else is on the IP number now, in which case you get an RST) but again, its reasonably fast. Disadvantages: The user who sent the spam will frequently not get notified. If your spamfilter blocks a legitimate user, you may never get notification to that person using this method. In any case, if I fail to deliver the bounce on the first attempt I'm going to ditch it and NOT retry. Its not a big deal from my point of view if you don't get back every one of the 452,223 spams you send me - - if I return 450,000 of them that's enough :-) The intent here is to do the following: 1) Alert the real sender if we can reasonably reach the person. 2) Alert the relay owner if they were relayed through without knowing about it (and pressure them to fix it - pronto!) 3) If we can't do either right away, toss the bounce on the floor on the premise that its better to give up than keep screwing around and clog up the pipeline. What do the rest of you here think? Option (1) doesn't look very sound; the fight right now is between (2) and (3). -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

2 2

routing to 147.73/16
by Phil Wood 19 Nov '97

19 Nov '97

Folks, If any of you BGP peer with DREN, as we do, you will be getting (as part of their AS668) a couple of subnets of 147.73/16: B 147.240.0.0/16 [5/0] via 138.18.169.1, 01:44:58 147.73.0.0/16 is variably subnetted, 2 subnets, 2 B 147.73.234.0/28 [5/0] via 138.18.169.1, 01:40:24 B 147.73.234.128/27 [5/0] via 138.18.169.1, 01:39:54 This could cause customers visiting SC97 to complain about connectivity to their local network from SC97 unless you are also receiving routing for the remaining 147.73 space from some other peer. I thought some subset of the nanog population might want to know since it caused me a bit of trouble shooting this morning, and nobody at DREN is available. Phil

3 2

Outage mailing lists
by Mark Milhollan 19 Nov '97

19 Nov '97

While mentioning DALnet's outage list Scott VanRavenswaay <scottvr(a)dfw.net> wrote: >Posts from MCI's list, while less frequent, are also redirected >here. Bah. MCI has been an almost total loss is this regard, since mid-July though it really began in February. Prior to that there were prior notices for all planned events, and follow-up messages for all unplanned events. Many of both have occurred since then, yet only a handful of messages were sent. I'm hoping that they're just over-worked, and that even that is being resolved.

1 0

Re: hmm..
by dean＠av8.com 19 Nov '97

19 Nov '97

>This sort of revenge is very common among spammers, in my first-hand >experience. Block a spammer from your site and shortly thereafter >various malicious things begin happening with disturbing frequency. I've heard of some malicious things happening to spammers with disturbing frequency. Some people have a tendency to get into personal wars with other people, rather than any sort of rational argument. That tends to bring out further anti-social behavior in the people they fight with. Just like schoolyard brawls. I urge everyone to stop for a moment and consider that people who disagree with you aren't subhuman bastards who should be tortured and deprived of life without a trial. Especially since we are the ones who generally have the "bats and guns". We all need to exercise a little moderation and restraint. If "I'm sorry that I published a route that knocked spamford off the net for 16 hours, it was a mistake" is acceptable for the things we do, then "I'm sorry, I shouldn't have sent that 300K message to your users when 1K or 2K bytes would do" should be acceptable for what they do wrong. Moreover, I would like to point out to people that the obnoxious mail relaying is a response to return mail attacks from some ISP's. -- The spammers just try to screw the return address and the headers so that those automatic programs don't work. Then innocent providers are bombed as relays. Twice. Once by the spammer, once by the autoreply scripts. Both parties need to knock it off. I would also note that (for the US, at least) the postmaster general has declared that pyramid schemes and such will be investigated and prosecuted even if they are perpetrated over email. Forward copies this emails to your local postal inspector c/o the post office. Child porn should be forwarded to the FBI. http://www.usps.gov/websites/depart/inspect/chainlet.htm >Well, allow me to point out that, analogously, spam is not a >commercial thing... I think a lot of the extreme anti-spam is also a power thing: >From an anonymous source: >I suspect he does it purely in the hope that it will annoy ISPs like >me, and no doubt a certain amount of adolescent "no one tells me what >to do" (well, spamford, in fact, we do, with our filters etc.) Adolecent #1 meets adolecent #2. The funny thing about kids is that they'll tell you right away what they did wrong, but refuse to accept responsibility for it. "I knocked over the table, but it wasn't my fault" Since July (July 11 to be precise), I have kept every piece of spam (even the duplicates). I now have 658 messages comprising 2.8 Meg, costing me 0.017 cents to download, and costing me 20 cents to store. I estimate that it took me 2 seconds to classify and refile each one, for a total of 21.9 minutes, and at my rate of $90/hr costing $32.85 dollars of my time, spread over 149 days (or approximately 5 months). So the true cost of spam has been approximately $6.00 per month, due mainly to my stubborn insistence on not using a software filter to delete them automatically. If I deleted all the illegal messages, I think the number shrinks down to about a 200 or so spams from companies or people (appearing, at least) to conduct legitimate (non-illegal, non-immoral) business, or at least fall in about the same category as the junk postal mail that I receive each day. I think if we are really concerned about net clutter, we should stop irc. But people make money off of that. So screw it. Let them send garbage. Charge 'em by the packet or the bandwidth, and buy more hardware. If you're downstream and can't keep up, drop the packets, send back source quenches, drop the newsgroups. But lets stop the silliness, and stop bombing innocents. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Re: opening tickets with peers
by Sean Donelan 19 Nov '97

19 Nov '97

>Is there a resource (phone list, email list, smoke-signal protocol) for >opening trouble tickets with peers? I've had a heck of a time opening >trouble tickets with Sprint among others. I've given up calling their >trouble center, since nobody seems to want to open a ticket unless you're >a customer. I've been able to get most issues resolved by contacting >engineers directly, but would much rather open a real ticket through the >NOC. While there are many proposed trouble ticket protocols, they all fail when there isn't management support to do something on the other end. As some providers like to remind me every once in a while, usually just before they do something incrediblely stupid like announcing the deaggregated global routing table from one of their customers, if opening up trouble tickets was important you should have put it in your peering agreement with them. I'm not sure why some managers think it is a more effecient use of their resources for me to get out my stash of businesss cards, and start calling various network engineers directly to get a problem fixed. But they do, so I start calling. If nothing else, it would let the managers keep better track of the problems they are having. However, this works both ways. If the other provider gave you their method for opening trouble tickets, and you don't follow it or you don't bother to tell your NOC staff about the other provider's procedures, then its your own fault. If you were told to call a particular phone number, or send e-mail to a particular address; and instead you sent it to the general customer support address; you will get the general customer support response. Some providers funnel both peers and customers through the same support center, others have seperate contact methods for reporting problems. Its like the small print on the back of your credit card bill, if you send the payment to any other address, it may delay things five working days. The same concept holds for making trouble reports with other providers. In general, you need to provide as much information (even more) as you would want to receive if the other person was reporting the problem. If you expect to get a ticket number from the other provider, you should provide your own ticket number. If you expect a response from the other provider, you should provide a call-back number and your e-mail address. Don't assume e-mail headers will pass unscathed through the other provider's trouble ticket system, if it is important include it in the text of the trouble report. If there is time-dependent information, be sure to include the timezone and confidence level the time period is correct. Saying someone broke into your machine a 9:00am doesn't help me if I don't know what timezone 9:00am is in. If you supply a traceroute, include the *SOURCE* of the traceroute as well as the destination. And so on. One important note, if it involves security issue, don't expect much information to come back via e-mail. If you haven't exchanged crypto keys, you might want to call ahead and find out the FAX number you should send the report. For some reason, if it requires involvement of the legal community, law enforcement and lawyers can deal with FAXes better than e-mail messages. >Most of the time the issues aren't time critical, but when another >provider is advertising a netblock that you own, being told that only >customers can open a ticket is more than a little frustrating. There are a different terms used for people who cause you harm, and people who will only stop causing harm if you pay them money. One of them involves treble damages. Unfortunately, reaching the correct level of management at some companies requires rather ugly actions. Although managers act shocked when a distaster hits, most disasters have precursors. Tit-for-tat is somewhat childish, but can be very effective in getting the other provider's attention. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Real..Live...SPAM
by Rob Wilson 19 Nov '97

19 Nov '97

Take a moment to read the details within the body of this email. Someone might want to track this guy down... Perhaps a little "Black Ops" mission may be in order?? I'll leave it up to you smart guys. rw

1 0

Re: hmm..
by Sanjay Dani 19 Nov '97

19 Nov '97

> > Someone *is* playing with us. > One likely explanation is that a spammer is reading nanog and is > showing his/her/its displeasure with the anti-spam tone on this list > recently. > > This sort of revenge is very common among spammers, in my first-hand > experience. Block a spammer from your site and shortly thereafter > various malicious things begin happening with disturbing frequency. Unfortuntely the same can be said about some anti-spammers today (while there are several honorable exceptions) as I can testify from an on-going breakin by a juvenile. Feel free to email me if you want an example or like to help. These anti-spammer hackers are lower scums than all the spammers I've encountered. The spammers have never destroyed information (yet). And we are not even close to being spammer friendly. Isn't it always easy to generalize and find scapegoats instead of treating every case as unique?

1 0

NANOG mailing list charter
by Rodney Joffe 19 Nov '97

19 Nov '97

I stand corrected. And I apologize to the list. This morning I posted a 'heads-up' about an AOL problem. My rationale for doing so was that the information was important to my operations group, because AOL represents 10 million end users who spend a portion of their online life connecting to websites that we host. And our customers measure our performance based on the number of hits per minute/hour/day that they are getting. When this rate changes uncharacteristically, the web customer immediately assumes that it is our network that is failing, and calls our operations group to complain, or inquire. Knowing that AOL is experiencing a problem (which would not show up in any of our peer monitors) helps our ops guys to avoid a wild goose chase. I assumed this was the case for most ISPs. I received a number of (thankfully) private flames, asking me why I thought anyone on the list cared. Obviously I thought many of you would. I was wrong. So I went to look at the NANOG charter (based on the crud that shows up on NANOG, one could be forgiven for being confused). I thought that the charter covered operational issues. It doesn't. Specifically, from the NANOG web site: "The NANOG mailing list is established to provide a forum for the exchange of technical information and the discussion of specific implementation issues that require cooperation among network service providers. <snip>." It covers implementation and co-operation issues. Sorry to create improper noise. Is anyone aware of a good newsgroup that does cover mundane issues like fiber cuts, DNS and root server failures, NAP problems, Route leaks, backbone poisoning, etc? Or is NANOG a good place for this, depending on who is doing the posting? In which case, where should the clueless unwashed like me go? Thanks... Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net

4 4

hmm..
by James D. Butt 19 Nov '97

19 Nov '97

Is it just me or.. I just received 2 "Welcome to nanog" messages and then this...a bounce.. Is someone playing with us? From: nanog(a)merit.edu To: listserv(a)roadrunner.gateway2000.com Subject: Subscribe join new.product join web.contests join press.releases -------------------------------------------------------------------------- James D. Butt 'J.D.' Network Engineer Voice 319-557-8463 Network Operations Center Fax 319-557-9771 MidWest Communications, Inc. Pager 319-557-6347 241 Main St. noc(a)mwci.net Dubuque, IA 52001 jbutt(a)mwci.net --------------------------------------------------------------------------

18 19

MAE-East work?
by Chris A. Icide 18 Nov '97

18 Nov '97

I assume that MFS/WorldCom was performing some work at MAE-East this morning? It looks like I lost most of my peers for a bit.. Seems to have been restored about 0945 EST. Chris ---------------------------------------------------------------------- Chris A. Icide Genuity, Inc. / Nap.Net, L.L.C. Sr. Network Engineer 4041 North Central Ave. Suite 400 602-207-6409 Phoenix, AZ 85012 - Notice: NVRAM invalid, possibly due to write erase. Press RETURN to get started! - PGP Keys located at pgpkeys.mit.edu or http://nap.net/~chris/keys.html ----------------------------------------------------------------------

3 2