John R Levine wrote:
For BATV to be useful, a domain would have to be able to say that all
messages from that domain must have BATV tags. I can't see anything
in the spec to cover that requirement. Otherwise a spammer will just
send messages without BATV tags, and BATV will achieve nothing other
than upsetting some legitimate mailing lists...
The main goal of BATV is to deal with bounce blowback, that is, DSNs
due to spam sent with forged return addresses. If your domain is
popular among spammers, blowback can be a serious issue. On a bad
day, my abuse.net domain gets 400,000 bounces for mail it didn't send.
The only thing prvs accomplishes is to let you tell whether an
incoming bounce was sent in response to a message you actually sent.
If you know that you sign all your own mail, you can be reasonably
sure that bounces to signed addresses are real, and bounces to
unsigned addresses are fake, give or take the edge cases we've been
discussing.
but then, why not a scheme such as
user+tagstuff(_at_)domain
(replace '+' with any char(s) you prefer). this would make it almost
trivial to implement in MTAs that support address extensions.
and this would go along with Ned comments, since you can then use
user+tag1+tag2+(_dot_)(_dot_)(_dot_)(_at_)domain (again, the '+' signs are just an example).
While I am in, the recommendation in
http://babel.de/batv.html
(cited from the implementations link) to use regular expressions based
canonical breaks recipient validation and will cause backscatter. which
breaks the whole purpose of BATV INMHO.
Also, whatever the scheme is, there is another class of applications to
think of. these are applications that use the sender address as an
element to determine the "reputation" of a transaction (spamassassin AWL
for instance). such apps should be made aware of the various BATV styles.