Terry Zink's Cyber Security Blog

Discussing Internet security in (mostly) plain English

The problem of backscatter, part 14 - Bounce Address Tag Validation

The problem of backscatter, part 14 - Bounce Address Tag Validation

  • Comments 2

As we approach the end of my series on backscatter, there is still one more piece of technology that holds real promise to combating backscatter - Bounce Address Tag Validation, or BATV.  That sounds a bit like a successor to HDTV... but it's not.

BATV is a more secure mechanism of my part 11 post in this series, Check to see if you sent the message in the first place.  BATV allows you a much more secure mechanism of determining whether or not you sent the message.  I'm not going to go into full technical details about how it works, rather, I will hit on the highlights.

Imagine if you could take a look at a message and determine whether or not you sent it.  You can kind of do that by parsing through Received headers and verifying if they conform to your standard.  But you don't have to do it that way.  Remember that this is the structure of an email, more or less:

Who Specified In
originator (author) Content -
From/Resent-From
Submitter into transfer service Content -
Sender/Resent-Sender
Return address (bounces) Envelope - Mail-From
Content - Return-Path
Sending Relay Envelope - HELO/EHLO
Content - Received header
Receiving Relay Content - Received header

Rather than putting just the sender in the MAIL FROM, BATV says to sign (ie, add an encrypted key) to the MAIL FROM.  The outgoing mail agent adds a signature to the bounce address:

Regular BATV
MAIL FROM mailbox@domain MAIL FROM sig-scheme=mailbox/sig-data@domain
MAIL FROM me@example.org MAIL FROM prvs=me/tag-val@example.org

The advantage here is that the (second) recipient mail server, the one receiving the NDRs and backscatter, does not need to rely on the original recipient mail server to do any verification of the sender.  You can do it all on your end:

  1. You know that on all outgoing mail you send, you sign the MAIL FROM.
  2. You receive an inbound message and it appears to be an NDR.
  3. You extract the RCPT TO, it should have the key value pair.  If you decrypt it and it checks out, accept the message because you did send it originally.  You don't even need to additionally filter it.  If the key value pair does not check out, discard the message because it is spoofed backscatter.

That's the basic idea behind BATV, it allows you to verify whether or not this subclass of messages, NDR bounces, originally came from you.  In my next post, we'll delve down a bit more into what some of the implementation challenges are around this mechanism.

Leave a Comment
  • Please add 2 and 5 and type the answer here:
  • Post
  • PingBack from http://wordnew.acne-reveiw.info/?p=10898

  • An obvious limitation of BATV is that it won't help receivers to reject a forged MAIL FROM me@example.org actually sent by a spammer. It helps me to reject most of the backscatter, the formats that can be identified as bounces and auto-responses.

    But accepted spam claiming to be MAIL FROM prvs=me/tag-val@example.org will still make it to mailboxes of unhappy users. The combination of BATV with an SPF FAIL policy for example.org could be ideal to combat forged MAIL FROM whoever@example.org.

    Pure BATV without SPF FAIL protection offers no incentive for spammers to move on and forge other (unprotected) addresses.

Page 1 of 1 (2 items)