a note to those who would automate their rejection notices
today AOL thoughtfully supplied the following to postmaster@vix.com: Peewee1isme@aol.com 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: <ediva.clapplz@vix.com> 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-0000bF-00; Sun, 30 Nov 2003 05:11:58 +0100 Message-ID: <0d7b01c3b6f8$814916c5$da62d340@ifptblb> From: "Ediva Clapp" <ediva.clapplz@vix.com> so once again we see, as in the case of the anti-virus rejection notices, that my reward for having my domain name forged in spam that didn't come from here, is to get mail from AOL telling me that they rejected it. so, i'll add this pattern to my own "drop silently" filters along with chaff from symantec's products, network associates' products, and so on. of the foundational principles which made the internet possible and which made it different from alternatives such as OSI, very few remain. one of 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: postmaster@[212.202.52.233] would have been a better destination for this. it's standards-compliant, and if the sender isn't an open proxy then they'll be able to get it, and it will not needlessly increase the collateral damage toward the holders of domains that were forged. "don't make me stop this car, kids." ...and to all a good night.
On Sat, Dec 27, 2003 at 07:06:30PM +0000, Paul Vixie wrote:
of the foundational principles which made the internet possible and which made it different from alternatives such as OSI, very few remain. one of 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: postmaster@[212.202.52.233]
would have been a better destination for this. it's standards-compliant, and if the sender isn't an open proxy then they'll be able to get it, and it will not needlessly increase the collateral damage toward the holders of domains that were forged.
Isn't the use of capital letters at the beginning of sentences standards-compliant with English? :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
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
On Saturday, December 27, 2003 5:14 PM [GMT-5=EST], Doug Luce <doug@nanog.con.com> wrote:
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?
Integrate SpamAssassin into your mailer daemon so it rejects in realtime. That way, the server trying to dump the spam on you gets a reject message right away, so that you don't generate a bounce yourself. Its unlikely to generate a bounce if its a proxy, as its not a real SMTP server obviously. I do this with EXIM - it lets the message go through until right after the DATA stage. Rejects as soon as the data stage is done. It also archives the message so I can review later/send to spamcop/whatever. I've been told this technically violates one of the RFCs, but I haven't been able to find anything to support that. The more you can do in realtime, the less likely that you'll generate unnecessary rejection traffic that might flood someone else. -- 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
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.
On Sat, Dec 27, 2003 at 05:29:14PM -0600, Laurence F. Sheldon, Jr. wrote:
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"?
I find that if you set the threshold for SA high (eg: 15+) it works well. I recently started dumping the 300+ spam I get a day into /dev/null if it hits the bayes99-100% range. Helps a lot. I also do a lot of whitelisting by IP and by email address for those people that seem to like to trip my filters.
Gee whiz. We are talking about email, right?
Actually, email is more important than being able to browse the web/internet to be perfectly honest. This was a common theme at my previous ISP. We'd have all sorts of other problems, but the single thing that would generate the most calls was email being down. Our upstream could be down and us having no backup link available but if email worked the call volume would be lower as people could perform some tasks. People take how their e-mail is handled very seriously.
But If I am going to send something that I really do want to be sure gets delivered, I'll use Federal Express.
- jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Sat, 27 Dec 2003, Paul Vixie wrote:
today AOL thoughtfully supplied the following to postmaster@vix.com:
Did they really?
Peewee1isme@aol.com 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: <ediva.clapplz@vix.com> 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-0000bF-00; Sun, 30 Nov 2003 05:11:58 +0100 Message-ID: <0d7b01c3b6f8$814916c5$da62d340@ifptblb> From: "Ediva Clapp" <ediva.clapplz@vix.com>
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: postmaster@[212.202.52.233]
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 *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
participants (7)
-
Brian Bruns -
Doug Luce -
Jared Mauch -
jlewis＠lewis.org -
Laurence F. Sheldon, Jr. -
Paul Vixie -
Richard A Steenbergen