[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-18 12:14:06

On May 16, 2008, at 9:59 PM, Dave Crocker wrote:


Bounce Address Tag Validation (BATV) lets a message origination site add a signature to the rfc2821.mailfrom address, in order to detect invalid return (bounce) messages at the destination. It has been in development for some time, with a useful amount of deployment experience.

We think it is ready for Proposed Standard and want to ask you, the ietf-smtp mailing list, to do a final review, before we send it in as an independent submission.

Pseudo-Last Call will end on Friday, 31 May.

HTML, PDF and TXT versions are available at the BATV web page, as is a listing of deployment experience:


We also would like to hear about any implementations and deployment
experience, beyond the listings at:


The more implementation experience we can cite, the strong the case that it is stable and useful.

There's code that sends autoresponses to mail received using the original mails 2822 sender (i.e. Reply-to: or From:) as the responses 2821 recipient and an empty 2821 sender.

The reasoning is that the sender of the autoresponse can't really do anything useful with the information that the autoresponse bounced, so it's better for the recipient MTA not to send a bounce message, and also that anything that'll encourage the receiver of an autoresponse not to send any mail at all in response to it is a good thing, and RFC 2821 section 4.5.5[1] encourages that behaviour.

My understanding is that this use of a null envelope sender follows the letter of both 2821 and 2821bis (there's a SHOULD in section 4.5.5, but that's all)..

This behaviour, in combination with BATV, will cause those autoresponses to be reliably discarded. I doubt either end of the connection will care, but I thought I'd mention it.


[1] "Implementors of automated email processors should be careful to make sure that the various kinds of messages with null reverse-path are handled correctly, in particular such systems SHOULD NOT reply to messages with null reverse-path."

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