Welcome to MSDN Blogs Sign in | Join | Help

Terry Zink's Anti-spam Blog

Protecting your mail from the scum of the internet
The problem of backscatter, part 15: BATV in a nutshell

The following is a diagram that I drew that illustrates a summary of how BATV is supposed to work to prevent backscatter.

image

Note the sequence of steps:

  1. Bender sends a message and hands it off through the outbound server.

  2. The outbound server signs his SMTP MAIL FROM.

  3. The recipient email server, mail.planet.express.ca, sees that the person he is delivery to does not exist.

  4. It accepts... and then bounces the message back with a null sender and puts the original, signed MAIL FROM into the RCPT TO.

  5. Upon hitting the inbound mail server, we see that futura.ama.org is one of our outbound customers, the message is a bounce, the encryption of the RCPT TO checks out so we accept the message.

  6. Meanwhile, evil spammer Nudar sends a message to mail.planet.express.info forging Bender's name.

  7. Mail.planet.express.info accepts the message, discovers that it can't deliver it and then bounces it back to Bender.

  8. Upon hitting Bender's inbound email server, it sees that Bender is an outbound customer and the message is an NDR.  However, the RCPT TO is not signed, therefore the message is rejected.

That's BATV in a nutshell.

Posted: Thursday, July 24, 2008 12:42 PM by tzink
Filed under:

Comments

a-foton » The problem of backscatter, part 15: BATV in a nutshell said:

PingBack from http://blog.a-foton.ru/2008/07/the-problem-of-backscatter-part-15-batv-in-a-nutshell/

# July 24, 2008 2:04 PM

Andy Parkes said:

Very cool

I understand the theory

Any downsides?

The anti-spam appliance i'm using has a BATV option but has big "only enable if you know what you're doing" disclaimer

Thanks

andy

# July 24, 2008 6:23 PM

Frank said:

Andy Parkes asked: "Any downsides?". When legit senders (Bender) talk with mailbots (vacation, list subscription, whatever), the mailbots are expected (by RFC 3834 among others) to look at the envelope sender address. They might not behave as they should if the envelope sender address has a BATV localpart. For example, a vacation mailbot could miss that it already told Bender about its master being out of office.

Another drawback is that Bender might use his ordinary envelope sender address elsewhere. But all error reports (bounces) for mails sent via other routes would be deleted, like the bounce for Nudar's spam.

IOW, if senders can do BATV then they can (in theory, this is not required) also publish an SPF FAIL policy. Therefore if they can't publish SPF FAIL (again in theory, because their setup with more than one ISP is too complex, not because they don't like it) then they also can't use BATV.

# July 24, 2008 8:18 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker