John R Levine wrote:
It occurs to me that the majority of BATV's interoperability problems
are due to the time stamp.
Well, changing bounce address anyway.
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.
You're working two different issues here.
First, spam or malware tucked inside a DSN certainly has been used by
the bad guys; I recall seeing a large surge of it about a year ago, and
I know Storm used it as a vector. It's simple social engineering: people
usually read their DSNs. (Ironic that a blowback storm makes a user less
inclined to read them.)
Second, any mechanism that makes your DSN and regular addresses
different is going to reduce backscatter. Bounce addresses are much
harder to harvest. If I append "-plugh" to all my outgoing bounce
addresses right now and checked for that incoming, my backscatter would
drop to zero, and stay there, maybe forever. Of course it can be
trivially replayed, but who's going to care?
But -- if a couple million users started doing the same thing, then the
bad guys would start to get interested.
The BATV signing mechanism has to assume that, at some point, the number
of sites using it is high enough to make attempts to circumvent it
worthwhile. We know BATV is vulnerable to replay, so we'd be remiss if
we didn't define a way to mitigate that. We also know that bounce
addresses do leak; poorly written mailing lists are probably the worst
culprit.
My suggestion: Keep the time stamp, but make the rate/frequency of
incrementing it a matter of local policy. I'd already been assuming I
would only increment it weekly.
<csg>