> 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?
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.
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.
Just goes to show how risky it is to place too much reliance on your own
personal experience. (I'm a serial offender in this regard as well, but honest,
your honor, I'm trying to break the habit.) The Internet is a very big place
and there are lots of behavioral enclaves out there.
> 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.
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 - a HUGE implementation burden when you consider how much stuff
needs to change - it needs to be able to accomodate more than that.
Mind you, a generic encapsulation without a specific purpose won't deploy
either - there has to be a "hook", something specific that it brings to the
table that will get people to buy in to it. And one defined scheme is is a fine
hook IMO. But when the opportunity presents itself to do something like this it
is nothing short of folly to not make it as flexibile as possible as
long as it remains simple enough.
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.
I'm not thinking of anything specific, and that's sort of the point. This is
like the original MIME debates, where there was a vocal minority that thought
MIME was overstepping its bounds in providing more than the ability to put
accented characters into email content, while we felt that as long as we were
going to pry open the message body format we might as well provide a framework
for solving a much more general set of problems.
Think where we'd be if we had caved to that approach - most likely we'd be
operating some sort of insane X.400-with-Internet-addresses hybrid. Yuck.
> 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.
Double use of a particular BATV scheme may well be a bug. Double use of the
format in general may not be.
> 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.)
The situations are not really comparable. First, it has always been possible to
impose your own semantics on the local parts associated with any domains you
have administrative authority over. This is all the various X.400 mapping
schemes ended up doing - you defined a domain (or overlaid an existing domain)
in such a way that it gets stuff to an X.400 gateway and then marvel at the
wierd and wonderful addresses that come in and out. (We actually defined
similar schemes for FAX and a bunch of the LAN email systems. Used to be there
was lots of demand for gateways to all this stuff.)
Now, I'm well aware that there's some verbiage in a couple of places in the
various X.400-related RFCs that kinda sorta implies that if you saw something
like:
"/admd= /prmd=doof/s=doe/g=john/"@someone-elses-domain
it was OK to drop the domain and treat the local part as an X.400 address. But
while this may have been the veiled intent of some subset of the X.400
supporters (I was never quite sure), there was never any consensus behind it. I
know this because I was there - I specifically raised the issue and was told
quite specifically that this was not the intent and therefore it was nothing to
worry about. Since it was already clear at that point that X.400 was, in the
immortal words of Marshall Rose, "road kill on the information superhighway", I
was mainly interested in gateway issues within an enclave and never bothered to
press the point and get the text clarified to say that you can only interpet
X.400-style local parts when its your domain on the right.
But even if this had been the intent and there had been a consensus behind it,
the reality is X.400 addresses never achieved sufficient regularity for this to
actually work, so anyone who tried it quickly got their fingers burned. (The
magic space in the /admd= clause has a lot to do this but now is not the time
to review this bit of ancient history.) One of the reasons we have a multistep
standards process is so that when consensus arrives at a bogus result it can be
corrected. If there was any internet in moving the X.400 documents along this
would be one of many things that would have to be addressed.
Nor is this comparable to some other proposals that basically tried to impose
structure on local parts in such a way that basically all address handling
would have to be updafed. No, this is somewhere in the middle - the vast
majority of address processing need not change, but some types of address
validity processing need to know enough to remove the tag(s). And I do think
there is sufficient apetite to have some additioanl tools for address
verification to carry this forward.
> 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.
Yes, and we're indeed one of those that doesn't enforce the 64 character limit,
although we do limit the entire address to 256 characters.
> 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.
Yep. Having already been down this path with SRS support, and IMO it's the only
workable approach.
> 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.
Sigh. You're almost certainly correct, but i have to say I like what's there
and wish we could keep it.
Ned