The problem here is that the draft does not explain how it deals with
the cut and paste attack.
There is no cut and paste attack. All that BATV does is to let you
test whether an alleged bounce is from someone who is responding to a
message from you. A bounce need not contain any of the text of the
original message, and if the target address was a mail exploder, it's
quite legitimate to get multiple bounces in reply to a single message.
A bad guy could send you a zillion bounces to the same message (or
more likely, a buggy MTA) but I don't see that as a big enough threat
to be worth a large amount of mechanism to avoid. If it is a problem,
a simple band-aid that counts the amount of mail to each BATV address
and rejects mail beyond some per-address limit seems as effective as
anything else and doesn't need any support from standards.
My prototype does put a timestamp in the signature, but I do that
because I've noted that address scraping from the web is a major
source of spam targets, and that's a way to make scraping of old
archives less effective.
In particular, BATV is NOT a way for recipients to verify the
authenticity of arbitary senders. I agree that remotely verifiable
bounce address signatures are an interesting idea, but this isn't it.
I also happen to think that the only reasonable way to do them is to
wait for MASS to do its thing and piggyback on top of whatever key
distribution scheme it uses rather than trying to invent our own.
As Dave C. has noted, BATV is a framework, and I'm sure there'll be
plenty of clever ideas of stuff to put into the framework. But we're
not gonna put it all there just yet.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.