>>>>> "mk" == Mikel King <mikel.king@xxx> writes: mk> http://www.eweek.com/article2/0,1895,2175935,00.asp -----8<----- It has become common for spammers to forge originating e-mail addresses and to then send large spam runs against different servers. When this happens, DynDNS sometimes receives these messages, which cannot be delivered, or worse, get bounced back to the original forged sender, who now gets the spam in his or her inbox (aka, spam blow back)... We simply feel that this is not the right thing to do. -----8<----- IMHO, they're completely right that what they're doing is wrong, and they need to stop doing it. Postfix calls it ``backscatter spam'' and includes some advice on how the victims of MTA's like DynDNS's former configuration can stop the spam _after_ it's been backscattered: http://cvsweb.netbsd.org/bsdweb.cgi/src/gnu/dist/postfix/README_FILES/BACKSCATTER_README?rev=1.1.1.4&content-type=text/x-cvsweb-markup The right way is to stop the backscattering. However there is absolutely no reason to stop generating bounces entirely! What they need to do is change their spam-checking so that it rejects spam instead of bouncing it: http://www.dontbouncespam.org/#BVR (apparently Qmail's bloody-minded absolutist disregard for the ``rough consensus and working code'' model is causing a sizeable chunk of the backscatter problem. It has to be patched to not backscatter. Can you even distribute pre-patched binaries with that man's weird licenses?) I guess what's going on in the article is, these mail ``forwarding'' services are doomed or at least less good than running your own MTA, because to stop backscatter, any MTA exposed to spammers needs to have a local list of all the valid users in the domains for which it is MX. In my opinion, you should do all your spam checks, both list-of-recipient checks and even lengthy checks like spamassassin, while the remote MTA is still connected, and send a 5xx error if you think the mail is spam. This stops backscatter, but preserves the old-Internet rule that mail should either be delivered or bounced. However, I admit that's not what my own site does right now. AFAIK with current implementations, bouncing with 5xx means you can't have ``spam folders'' because the spam isn't accepted. Someone could write one that bends the rules a little bit, and tells the sending MTA 5xx, but still secretly delivers a copy of the message to a local spam folder. Personally I don't like spam traps for things that ``might'' be spam. As a legitimate sender, I'd much rather have my mail bounced with 5xx than stuffed into a spam trap. The consensus on the Interweb seems to be, you should either reject or silently discard spam. meaning, it's okay to break the rule of the old Internet: now mail can be delivered, bounced, or silently discarded. I hate this, because it allows shifty people to say ``oh I didn't get your email. It must have gotten stuck in my spam filter.'' I'd hate to think the way I run my MTA is letting people give flakey-brained AOLexcuses like that. And it is really unnecessary. You can have the best of the new and the old world if you will run your spamassassin milter or amavis or whatever before your MTA sends its '250 queued as ...' message. But every web page I read says definitely do the silent-discarding instead of contributing to backscatter.
Attachment:
pgpho8ooR4COZ.pgp
Description: PGP signature