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.


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,, 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 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 forging Bender's name.
  7. 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.

Comments (5)
  1. Andy Parkes says:

    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



  2. Frank says:

    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.

  3. Milt AItken says:

    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.

  4. Jochen Rauch says:

    Thank you for the very clear and understandable description (and the beautiful example / grafic 🙂 )

Comments are closed.

Skip to main content