Don Marti

Sun 30 Aug 2009 08:36:07 AM PDT

Spam from a spam filter

Just got this from somebody's spam filter:

A message from <dmarti@zgp.org>
to: .........@........

was considered unsolicited bulk e-mail (UBE).

Our internal reference code for your message is 52025-06-2/iuTig+4zlYYG

The message carried your return address, so it was either a genuine mail
from you, or a sender address was faked and your e-mail address abused
by third party, in which case we apologize for undesired notification.

We do try to minimize backscatter for more prominent cases of UBE and
for infected mail, but for less obvious cases some balance between
losing genuine mail and sending undesired backscatter is sought,
and there can be some collateral damage on either side.

"Try to minimize backscatter"? Not very hard. Do a host -t TXT zgp.org—this domain has an SPF record. If you're running a spam filter, you can check the other end of the SMTP connection against it as soon as the other server says MAIL FROM. Then drop the connection right there if it's an obvious forgery, without even accepting the data or bothering your filters.

Yes, I'm saving your incoming SMTP server precious energy. You're welcome. Save your main spam filtering resources for mail that either passes SPF or comes in from a domain that still doesn't have it. Spammers can always register domains and get SPF, so SPF isn't the Silver Bullet for Spam, but it does help keep spam filters from spamming, if you use it. Don't spam the victims of address forgery.

comment 1
Or use batv? I haven't had a single piece of spam backscatter for 18 months or so now.
Comment by Anonymous — Sun 30 Aug 2009 03:10:43 PM PDT
SPAM processing should be inline

Anti-spam measures should be performed during the SMTP protocol. Then if a message is regarded as spam it can be rejected in the SMTP protocol - this means that in the case of a connection from a spam-bot there will be no back-scatter and in the case of legitimate mail that matches a spam pattern the sender will receive a bounce.

The only back-scatter that you get from a SMTP protocol rejection is when spam has been sent through an ISP's relay.

The BATV concept sounds interesting, but there are some known problems with it. I've been considering setting up a manual implementation of a similar idea, but instead of having a tag for each message having a new tag every few months. I expect that the amount of time taken for a tag such as russell-f00f1234@coker.com.au to be known enough by spammers to cause me problems will be more than a few months. Therefore I won't have problems with greylisting etc.

But I haven't been getting enough back-scatter recently to force me to go ahead with this.

Comment by etbe — Sun 30 Aug 2009 03:39:47 PM PDT
Two rounds of spam processing
There's a case for doing spam processing twice: once at SMTP time, so that senders of false positives get a bounce from their own mail server, then again at IMAP time, so that the spam filtering system can take advantage of spam data that came in after the SMTP transaction completed (for example, if the same server sent mail to a spamtrap address on the system after successfully getting the spam through.) When you filter after the SMTP connection has closed, though, all you can do is put the mail in the user's spam box. You can't reliably generate a bounce or safely discard the mail.
Comment by dmarti — Mon 31 Aug 2009 06:51:26 AM PDT