Terry Zink's Cyber Security Blog

Discussing Internet security in (mostly) plain English
Translate This Page
Common Tasks
Search Form
  • Advanced search options...
Tag Cloud
Monthly Archives
Archives

The problem of backscatter, part 15: BATV in a nutshell

MSDN Blogs > Terry Zink's Cyber Security Blog > The problem of backscatter, part 15: BATV in a nutshell

The problem of backscatter, part 15: BATV in a nutshell

24 Jul 2008 1:42 PM
  • Comments 4

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.

Leave a Comment
  • Please add 3 and 2 and type the answer here:
  • Post
Comments
  • a-foton » The problem of backscatter, part 15: BATV in a nutshell
    24 Jul 2008 2:04 PM

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

  • Andy Parkes
    24 Jul 2008 6:23 PM

    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

  • Frank
    24 Jul 2008 8:18 PM

    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.

  • Milt AItken
    11 May 2009 9:00 AM

    Another problem is that the displayed from: address differes from the real (BATV) from: address.  Some spamfilters see this as a 'faked-from' address and block it.  Also, specific addresses can't be whitelisted since they change with every serialized message.  So, this effective anti-spam technique actually causes more legit mail to be marked as spam.

Page 1 of 1 (4 items)