Re: a note to those who would automate their rejection notices
pv of the foundational principles which made the internet pv possible and which made it different from alternatives such as pv OSI, very few remain. Would SPF http://spf.pobox.com/ be a bit less destructive than many other proposals to counter trivial forgery. No. Nor will Yahoo's recently announced technology make any real difference. Preventing forgery is a way of protecting domain names as service marks and also ensuring that your own or your customers' non-spam output isn't snared in a bunch of false-positive trappery. But it won't stop or even slow the rate at which spam is sent or is received. Spammers still lie, but they are no longer as dumb as fence posts, and they can register throw-away domains whose crypto-authenticity is completely valid, even in the presence of wide scale wormspoor-proxy usage. It could be that I'm just especially irritable this year, or it could be that the reinvention frequency of bad ideas really is growing at the same rate as the internet's population. I no longer think that E-mail as we know it will survive. But I would be less irritable about it if the people who keep proposing to save it would (a) do their homework, (b) assume that spammers are going to try to adapt, and (c) think about the side effects of the tools they deploy. This is information warfare. Warfare. You aren't fighting the terrain or the elements or some mindless bacteria. You're fighting other humans, and they are armed, committed, dangerous, and adaptive. In that light, I look at things like Bayesian filters or Vipul's Razor and I wonder, why is the D in Vern's DCC (see www.rhyolite.com/dcc) so difficult to predict a need for? (Y'all already know my views on relay-probing without spam-in-hand, but the tie-in here is how can you fight spam if your principles aren't different from the people you're fighting? where exactly do you think it will end?) Anyway, I hope folks will stop sending automated rejection notices to domains who were not involved, other than by forgery, in the transmission of a virus or spam. In other words, there's relevant operational content in this thread, and when fighting spam it would be reasonable to avoid hurting uninvolved third parties. AOL, please listen.
Re: a note to those who would automate their rejection notices
On Saturday, December 27, 2003 3:23 PM [GMT-5=EST], Paul Vixie [EMAIL PROTECTED] wrote: Anyway, I hope folks will stop sending automated rejection notices to domains who were not involved, other than by forgery, in the transmission of a virus or spam. In other words, there's relevant operational content in this thread, and when fighting spam it would be reasonable to avoid hurting uninvolved third parties. AOL, please listen. Cox in particular was doing this until recently (we got their attention rather quickly after blacklisting their main mail servers). We were being joe jobbed badly, and cox's mail servers were generating massive amounts of bounces per minute, and out of all the bounces, cox was generating the most (at least 3/4 of them) The result was that each one of their mail servers (more then a dozen) was sending one bounce per connection, and launching anywhere between 5-12 connections at a time, then reconnecting right away after sending the single bounce and disconnecting. We quickly ran out of connection slots on both the primary and secondary mail spoolers, leaving us unable to get incoming mail until we firewalled out cox's mail servers. One would think, if your going to run a cluster of mail servers to handle your mail, that you would rate limit your bounces so that people (like myself) who can't afford to have a dozen or more heavy duty mail servers don't end up getting DoS'd by your mail server's ability to pump out millions of messages per hour. Someone said on one of the newsgroups, Well, maybe they setup their system correctly, and don't see a need to change something that works. The problem is, theres a difference between properly configuring a mail server and responsibly configuring a mail server. When you responsibly configure a mail server, you take into account OTHER people's systems and how THEY will be able to deal with your server. Part of the issue comes with when you accept a mail, then bounce afterwards, instead of just bouncing after RCPT TO: or DATA. When you delay the bounce, you will generate a bounce to the From: address, even if it is forged. When you outright reject the message, you pretty much reduce the risk of that happening by far, as the sending server will see that the message was rejected, and hopefully move on. Now, this works with open proxies, but not with open relays. Do spammers use open relays much anymore? No, not really. Why leave a trail back to yourself when you can hide completely? AOL has _not_ done this to us though, we've seen maybe one or two bounces from AOL's servers, but nothing even remotely close to what Cox is doing. Just my thoughts, flame away :) -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org The AHBL - http://www.ahbl.org
Re: a note to those who would automate their rejection notices
This reminds me: I'm scared to death of false positives. So much so that every email that triggers a positive from Spamassassin (i.e. several thousand spams a day) gets a response. It tries to be as polite as possible, both by being good-natured in tone and by both a Precedence: bulk header and an application-specific X-header to break loops. It's worked well enough for me to plan an implementation for an email system I run (servicing about 70k users). There are no real anti-DDOS provisions in it that would prevent someone from sending several million messages with a forged SMTP envelope to flood someone's mailbox quasi-anonymously. I haven't ever heard of this sort of system being used. Other than the obvious problems (like above, and the fact that it generates a LOT of mail that's going nowhere). Does anyone know of a precedent? Or wants to pick apart the idea in terms of community effect? Thanks, Doug
Re: a note to those who would automate their rejection notices
Doug Luce wrote: I'm scared to death of false positives. That is in and of itself scary. What on earth is there about computers and networks (assumptions: Not connected to weapons, weapon delivery systems or vehicles, or high-energy sources) that would account for somebody being scared to death? Gee whiz. We are talking about email, right? No if we are talking about seriously annoyed I guess that is OK as long as it does not increase the abusive traffic I have to deal with. But If I am going to send something that I really do want to be sure gets delivered, I'll use Federal Express.
Re: a note to those who would automate their rejection notices
On Sat, 27 Dec 2003, Paul Vixie wrote: today AOL thoughtfully supplied the following to [EMAIL PROTECTED]: Did they really? [EMAIL PROTECTED] SMTP error from remote mailer after initial connection: host mailin-02.mx.aol.com [64.12.137.89]: 554-(RLY:B1) The information presently available to AOL indicates this 554-server is generating high volumes of member complaints from AOL's 554-member base. Based on AOL's Unsolicited Bulk E-mail policy at 554-http://www.aol.com/info/bulkemail.html AOL may not accept further 554-e-mail transactions from this server or domain. For more information, 554 please visit http://postmaster.info.aol.com. this was in response to what the e-mail community refers to as a trivial forgery, whose salient headers were: Return-path: [EMAIL PROTECTED] Received: from port-212-202-52-233.reverse.qsc.de ([212.202.52.233] helo=1-online-poker-video.com) by mx01.qsc.de with esmtp (Exim 3.35 #1) id 1AQIw9-bF-00; Sun, 30 Nov 2003 05:11:58 +0100 Message-ID: [EMAIL PROTECTED] From: Ediva Clapp [EMAIL PROTECTED] You didn't include much of the bounce, but from what you did include, I'm guessing this is similar to lots of spam bounces I've gotten. port-212-202-52-233.reverse.qsc.de originated the message (most likely via a trojan spam proxy/emitter thats infected it) and sent the spam through a local mail server, mx01.qsc.de. mx01.qsc.de is actually the system blacklisted by AOL. When it failed to deliver this spam to AOL, it tried returning it to the sender, which likely landed the message in a catch-all email box at vix.com. Assuming that's what happened, this isn't AOL's fault at all. them was must scale indefinitely. a simple application of this principle toward anti-virus and anti-spam automated rejection notices is to ignore the envelope and ignore the header and just focus on the peer IP address: To: [EMAIL PROTECTED] That too will bounce. I haven't checked, but I'd bet port-212-202-52-233.reverse.qsc.de (212.202.52.233) is an end-user running some flavor of Windows and does not run an SMTPd. don't make me stop this car, kids. ...and to all a good night. When did this become SPAM-L? This sort of thing's been talked about on several of the other spam lists for a few weeks since some spamware app started using local MX's as relays, likely to circumvent DNSBLs and outbound 25/tcp blocking. We're all going to have to come up with patches or hacks to rate-limit outgoing email by originating IP, or things are really going to get ugly as ISPs start blacklisting each other's mail servers to stop this sort of relayed spam. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
