Re: BATV pseudo-Last Call

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

> Folks,
>
> 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:
>   <http://mipassoc.org/batv/>
>
> We also would like to hear about any implementations and deployment
> experience, beyond the listings at:
>
>   <http://mipassoc.org/batv/deploy/>.
>
> 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.
Cheers,
  Steve

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