Hate to be the bearer of bad news, but the vast majority of the lists
operated with our software verify based on the MAIL FROM (bounce)
address.
I'm astonished. What package do you use? I'm on a lot of lists and it's
really the case that other than a few ezmlm lists, they all use the body
From: address.
Additionally, in order for this to work BATV encapsulation must be uniquely
identifiable as such, must be removable,
Right, it does that.
and must allow nesting.
Nope. Remember that BATV depends on a shared secret betweeen signer and
the MX for the domain. It only makes sense to sign if you know the key
for the domain. So if a signed message isn't in one a domain for which
you have the signing key, you have no business signing it, while if it is
in such a domain, you (or one of your friends) have already signed it.
If you're thinking of something like VERP that embeds an arbitrary address
in a bounce address, I suppose you're right, but BATV doesn't introduce
any new problems that VERP doesn't already have.
Another one: A key step in the stripping procedure is that last "repeat",
because a single address may undergo multiple BATV operations.
Again, no. We certainly need to clarify why double BATV signing is a bug.
Another one: Registration requirements.
Right. I'd think it would be easy enough to add a registry for tags and
populate it with prvs=. How upset would people be to see semantics
declared for local parts? (Although I'd think that battle was lost a
decade ago with X.400 addresses.)
Another one: String lengths.
You're right, it's a problem. The hand-wave is to assert that few MTAs
enforce the 64 character limit, but I realize that's not very persuasive
for a standard. On the other hand, since there's no nesting, the damage
is at least predictable. The current spec adds 16 characters to each
address but I've been considering a modified version with 10 characters
that addresses some greylisting problems as well.
Another one: Quoting. Again, you may run into them, but quoted local
parts are used in some corners of the Internet.
Good point. I agree that unquote, batv or unbatv, requote is the only
approach that makes sense.
Oh, and one final note. The document talks a bit about defining a public key
BATV scheme but doesn't actually define anything.
On the theory that standards shouldn't speculate about the future, we
really should take this part out other than say that the syntax is
designed to permit other signing schemes to be added.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.