Bounce Address Tag Validation

In computing, Bounce Address Tag Validation (BATV) is the name of a method, defined in an Internet Draft, for determining whether the bounce address specified in an E-mail messageis valid. It is designed to reject backscatter, that is, bounce messages to forged return addresses.

Overview

The basic idea is to send all e-mail with a return address that includes a timestamp and a cryptographic token that can not be forged. Any e-mail that is returned as a bounce without a valid signature can then be rejected. E-mail that is being bounced back should have an empty (null) return address so that bounces are never created for a bounce and therefore you can't get messages bouncing back and forth forever.

BATV replaces an envelope sender like [e-mail] with prvs=tag-value=[e-mail], where prvs, called "Simple Private Signature", is just one of the possible tagging schemes; actually, the only one fully specified in the draft. The BATV draft gives a framework where other possible techniques can fit into. Other types of implementations, such as using public key signatures that can be verified by third parties, are mentioned but left undefined. The overall framework is vague/flexible enough that similar systems such as Sender Rewriting Scheme can fit into this framework.

History

The earliest system that used this idea was the Anti-Bogus Bounce System, proposed on the news.admin.net-abuse.email. [http://groups.google.com/groups?q=abbs+qmail&hl=en&lr=&ie=UTF-8&c2coff=1&safe=off&selm=slrnbtcrap.lis.y7pt9001%40safari.homelinux.net&rnum=1] It was later re-invented as a modification of the Sender Rewriting Scheme and given the name "Signed Envelope Sender" [ [http://web.archive.org/web/20060909034948/ses.codeshare.ca/files/Working_SES_Format_Definition_16.html Microsoft Word - Working_SES_Format_Definition_16.doc ] ] . Several months later, it was again re-invented as BATV.

Problems

The draft anticipates some problems running BATV.
* Few mailing lists managers (e.g. ezmlm) still key on the bounce address, and will not recognize it after BATV mangling.
* Greylisting requires BATV implementations to keep the same tag across retransmissions for a reasonable time. This may also cause each e-mail to be delayed unless the greylisting system ignores the tag.
* Challenge-response spam filtering and systems that sort mail based on the bounce address (e.g. for removing duplicates) may work less smoothly with BATV-tagged addresses.

There are also problems that prevent BATV systems from eliminating all backscatter.
* Some legitimate e-mail gets sent with empty return address that is not a bounce and therefore will not have the special tokens. For example, the Delivery Status Notification extension defined in RFC 3461 requires a null return path when sending email with a "NOTIFY=NEVER" option to a non-conforming server.
* Some e-mail bounces (incorrectly) gets sent not to the return address, but to the e-mail address on the From: header.
* Due to length restrictions on the local-part of the email address, the signature must be kept short and therefore the prvs mechanism provides weak protection against replay attacks.
* Some mail systems that implement Callback verification (incorrectly) use "postmaster" instead of the null return address.

References

ee also

* Sender Policy Framework (SPF)
* Sender Rewriting Scheme (SRS)
* Simple Mail Transfer Protocol (SMTP)
* Variable envelope return path (VERP)

External links

* [http://tools.ietf.org/html/draft-levine-smtp-batv BATV draft]
* [http://mipassoc.org/batv/ BATV web page]

* [http://www.pcworld.com/businesscenter/article/145449/100_email_bouncebacks_youve_been_backscattered.html100 E-mail Bouncebacks? You've Been Backscattered.] mentions BATV as a way to reduce the problem.

* [http://www.ironport.com/company/pp_eweek_07-27-2006.html Ironport announces support for BATV]
* [http://ipcommunications.tmcnet.com/topics/ip-communications/articles/27612-astaro-blocks-backscatter.htm Astaro announces support for BATV]