[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-17 13:16:59

You're assuming that the only purpose for this scheme is this specific sort of signature. Sorry, if we're going to define a generic encapsulation format for local parts -

Holy Mission Creep, Batman. I certainly don't want do do that and doubt that anyone else involved with BATV does. That would be a quicksand filled swamp of continental proportions. I'm not very interested in SRS, which merely compounds the wrongness that is SPF, but VERP in various forms is used very heavily by all sorts of mailing list and other bulk mail packages, and there's something called SES which is sort of DK with the signature coded into the bounce address.

They address different problems. BATV is to tell who was the sender of a message that caused a bounce. SRS is to tell who was the sender of a message that caused a forward. VERP is to tell who was the recipient of a message that caused a bounce. SES is to tell whether a bounce address matches the message's contents.

BATV has the particular interaction with mailing lists that makes it useful to tell whether a particular BATV address is the same sender as a prior BATV or non-BATV sender, but I don't see that as an issue with any of the others, so I don't see any benefit in creating a common syntax.

Incidentally, BATV and VERP work just fine together as is, viz. this bounce address on a message I just sent myself:


I'm astonished.  What package do you use?

We don't use any sort of external package. Our MTA handles lists natively; it
has done so for longer than most of the list processing packages have been in

Ah, it's old. I think you will discover that you are in dwindling minority if you're keying on the 2821 address. I haven't done a formal survey but it is my strong impression that all of the widely used list management packages these days other than ezmlm use the body address. I guess it's worth doing some research on packages that people actually use. (Preferably with significant grant funding.)

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.

Sigh. You're almost certainly correct, but i have to say I like what's there
and wish we could keep it.

Either it should go or we should implement it. The main blocking item was the lack of a source of public keys, but DKIM may have solved that problem. This may be worth turning into a WG, although I'd like to get BATV out in finite time so I'd rather do BATV now, WG later.

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>