On 2008-05-17 07:37:47 -0700, [EMAIL PROTECTED] 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
> 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.
> 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.
> 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?
hp
--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | [EMAIL PROTECTED] | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
signature.asc
Description: Digital signature
