[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-17 11:24:13

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.

John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

<Prev in Thread] Current Thread [Next in Thread>