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:
<prvs=001659e973=testlist-owner+m1=jrlevine2=yahoo(_dot_)com(_at_)lists(_dot_)gurus(_dot_)com>
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
existance.
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.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.