[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-18 02:38:48
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.

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. 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.

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

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.

Another, bigger, concern is that the draft seems seriously deficient in
substantive discussion of the actual handling of BATV addresses. For one 
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.

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


   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | hjp(_at_)hjp(_dot_)at         | That's not engineering, that's art.
__/   | |    -- David Kastrup in comp.text.tex

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>