On 2008-05-17 07:37:47 -0700, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
(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.
I did that too for some time. But while only a few users complained,
they did so very vehemently, so I changed it again.
Many lists. 20+ years of operation. I have yet to receive a single complaint
about MAIL FROM validation. (There have been other complaints, of course.)
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.)
That's not quite true. You can verify the From header and then return a
550 response after the "." terminating DATA.
Only if there are no other recipients. There frequently are on list messages
when some list participants are on the same machine as the list.
Now, of course you can always do the trick of 4yz'ing the second and subsequent
recipients. I've been down this road already trying to solve a different
problems - and it ended up generating quite a few complaints. (And note that
there are other situations where this is unavoidable - for us they tend to
arise when the directory server falls over.) It seems a lot of systems out
there don't handle this all that well. Amazing to me that people will put up
with such brokenness, but there you go.
Another issue is that if you do this sort thing you absolutely must distinguish
between submission and relay somehow, and lots of places are unable to make
such distinctions. It's one thing to force a automatic relay to retry the
second and subsequent recipients of a message, quite another to force some
random user to resubmit the message over and over in order to get it through.
Of course many of these effects can be mitigated for legitimate posters by
allowing messages with a "legal" address in either the MAIL FROM or header
From:. Since in most cases these will be the same you'll grant access to most
legitimate messages at RCPT TO time. Only when fallback to checking a From:
address is needed does the single recipient requirement need to be enforced.
But now you're talking about fairly complex and, to those not familiar with all
of the ins and outs of SMTP, nonobvious bit of behavior. If you think it's hard
to code, try being on the other end of a conversation with a clueless sysadmin
who's trying to figure out what the hell their MTA is doing when all this is
going on.
But regardless of how you choose to resolve these issues, the bottom line is
that it is a mistake to assume that your own experiences with things like list
operation will necessarily be shared by others. The amount of variation out
there is really quite astonishing.
So you don't have to accept
the message, but you have to receive it completely before you can reject
it. I've written plugins for qpsmtpd which implement this for majordomo
and mailman mailing-lists.
For my part, I cannot justify spending time on a solution none of our users
have asked for and which has side effects we already know people really don't
like.
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.
Speaking of validation, there is one interoperability issue the draft
doesn't mention: Mail address verification by SMTP callout. For
verification of envelope senders this works fine, but there are other
applications where a mail address needs to be verified:
For example, on some of our websites we have forms where the user needs
to enter their email address. To reduce the number of bounces and also
to catch typos when the user can still correct them, we immediately
connect to the MX and send a MAIL FROM:<>/RCPT TO:$email. I realize that
using the empty address in the envelope from isn't quite correct (I
should use the same address that is later used in the confirmation
mail), but I doubt we are the only ones who do it this way.
Probably not. And this is definitely an issue for BATV.
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.
I agree partially. I recently implemented a BATV plugin for qpsmtpd and
I noticed that a few details are missing or at least rather vague. OTOH,
maybe they don't need to be specified. The only scheme currently defined
is prvs, which can only be validated by the original sender. Since that
one is presumably using the same software to generate and verify the
signature, incompatibilities between implementations don't matter. For
schemes which are intended to be verified on another site, more specific
rules can be included in the specification of that scheme.
But like it or not, we've observed pretty strong correlations between
specifications that lack detailed instructions and examples and an increase in
implementation botches.
Of course every specification the IETF has ever published could likely be
improved in some way or other. But that's no excuse for failing to pick really
low hanging fruit.
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.
I don't think that nesting BATV makes much sense. Can you provide an
example?
You're completely missing my point. This needs to be cast as a general local
part structuring mechanism, not as something useful for this one use case.
Imposing structure on local parts that's visible outside of an administative
domain - a place this proposal obviously intends to go - is a very big deal and
needs to be done with sufficient generality that other stuff with different
goals can come along and reuse it. As such, the correct question to ask is,
"Can you justify preventing nesting for all possible future schemes people
might think up?" Nesting should be out of scope if and only if that question
can be answered in the affirmative, and I am extremely skeptical you can do
that.
Ned