It occurs to me that the majority of BATV's interoperability problems are
due to the time stamp. Let's assume for the moment that we simplify a
BATV signature to something like this:
prv=DHHHH=local(_at_)host
The D is still a version number, and the HHH is a hash, but there's no
timestamp. Now, unless you change your key, which seems pretty rare in
practice, a given plain address always turns into the same BATV address.
Now if you have a mailing list manager that recognizes senders by bounce
address, it works fine, because each sender always has the same bounce
address. (The bounce address won't match the From: address, but it is my
impression that software that keys on bounce address is unlikely to be
picky about From: addresses.) There will be a one-time issue when a
sending site starts using BATV, but that's a whole lot less pain than when
your bounce address changes every day.
Greylisters that remember each envelope to decide what mail not to delay,
check. Annoying C/R schemes that challenge each new bounce address,
check. Vacation programs that limit traffic by responding only once to
each bounce adddress, check.
What you lose is the ability to reject bounces to mail sent a long time
ago. But how important is that? Having been the recipient of a rather
large amount of blowback, I've never seen any evidence that it was
targeted at me, or at least not targeted at me in order to get me to read
it. Trading off replay protection to get lists to work seems like a big
win to me.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.