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:
That's BATV in a nutshell.
PingBack from http://blog.a-foton.ru/2008/07/the-problem-of-backscatter-part-15-batv-in-a-nutshell/
I understand the theory
The anti-spam appliance i'm using has a BATV option but has big "only enable if you know what you're doing" disclaimer
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.
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.