(I haven't looked at BATV in any detail before.)
Do you have more detail beyond this text in draft-levine-smtp-batv-01.txt
Mailing Lists: BATV will cause problems with some mailing lists
that identify posters by their bounce address. The list will not
The only lists I know of that still key on the bounce address are ones
run by ezmlm which isn't very popular any more.
I subscribe to lots of mailman lists, including this one, and listserv
lists without any undue strangeness.
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. The reason it
is done this way is so rejection can be done during the SMTP dialogue.
Validation based on header From: requires first accepting the message, with all
that implies. (We've put a fair bit of effort into making this sort of up-front
validation extremely quick.)
I for one would be EXTREMELY reluctant to reconfigure the lists I run to use
some other address, because doing so would mean I have little choice but to
review at least some of the messages that are rejected by list policy.
Now, the obvious way to address this so that everyone wins is to BATV-enable
list processing software. I have no objection to this approach, but simply
saying "this may cause problems with list software" in the draft and then
justifying this here by saying in effect "the limited subset of list sofware I
know about doesn't have this problem, oh, except for this one over there that I
don't think is very popular". No, like it or not, there's already quite a lot
of validation of MAIL FROM addresses going on out there (indeed, somewhat
ironically, increasing such validation is actually the goal of BATV), and BATV
imposes additional requirements on such software, which need to be made very
very clear in the document if you want this to successfully deploy.
Additionally, in order for this to work BATV encapsulation must be uniquely
identifiable as such, must be removable, and must allow nesting. The scheme the
draft defines come fairly close to meeting these requirements: Look for two
equals signs with alphanumeric stuff between them, if found remove up through
the second equals sign, repeat. However, I do worry that the "signature' of two
equals signs is not sufficiently unique. At least one obvious conflict is with
SRS encoding.
Another, bigger, concern is that the draft seems seriously deficient in
substantive discussion of the actual handling of BATV addresses. For one thing,
nowhere do I see an explication of the stripping process I just (casually and
somewhat incorrectly) described. Including this sort of information is
essential if you expect implementors to get this stuff right.
Another one: A key step in the stripping procedure is that last "repeat",
because a single address may undergo multiple BATV operations. Maybe I missed
it, but I could not find any discussion of nesting or repeated application of
BATV. This absolutely must be included if there's to be any chance of people
getting it right.
Another one: Registration requirements. This part of the draft is obviously
incomplete so this may not seem like fair game. (And this alone, incidentally,
means this isn't even clsoe to ready for last call for proposed. Come on, do
you really think an IANA Considerations Section that says in its entirety "It
may be desirable to establish a registry of BATV tagging schemes and tag
types." is good enough?) But while the registration details have to be nailed
down I'm actually more concerned about something a little different: Without
specific guidance that pretty much says "if it passes muster syntactically as a
BATV address it needs to be treated as one for validation purposes", you are
going to have people attempting to validate the leading tag with some sort of
registered scheme list.
Another one: String lengths. One of the issues with BATV and similar schemes is
that they necessarily increase the length of local parts. You may not have run
into them, but there are some exceptionally long local parts out there. Some
discussion of how to handle them is definitely needed (even if all it ends up
saying is essentially "punt"), and if it is there I couldn't find it.
Another one: Quoting. Again, you may run into them, but quoted local parts are
used in some corners of the Internet. The draft needs to discuss how BATV
handles quoted local parts. (I suggest dequoting before and requoting after.)
In summary, the idea behind BATV is sound, but this draft needs a lot of work
before it will be ready for last call for proposed. At a minimum it needs to
impose specific requirements on agents that perform address comparison
operations, the registrations requirements need to be nailed down and spelled
out, and a lot more detail as to what constitutes correct handling of BATV
addresses needs to be provided.
Oh, and one final note. The document talks a bit about defining a public key
BATV scheme but doesn't actually define anything. I personally have no problem
with this and even applaud the rather brutal comment that "none of the multiple
existing public key services has yet gained wide adoption", but it strikes me
as exactly the sort of thing that tends to cause bad cases of panty-wadding
among the security mavens. I don't know how to finesse it, but some finesse is
probably in order here.
Ned