Re: Bounces, was Re: [Asrg] Sender pays vs Forgeries

On Fri, 21 Mar 2003 13:12:38 CST, David Walker said:

> Can you point to something in the RFC that indicates there is a valid use for
 
> null senders other than bounce/error messages?
RFC2821, section 6.1 says:

   If there is a delivery failure after acceptance of a message, the
   receiver-SMTP MUST formulate and mail a notification message.  This
   notification MUST be sent using a null ("<>") reverse path in the
   envelope.  The recipient of this notification MUST be the address
   from the envelope return path (or the Return-Path: line).  However,
   if this address is null ("<>"), the receiver-SMTP MUST NOT send a
   notification.  Obviously, nothing in this section can or should
   prohibit local decisions (i.e., as part of the same system
   environment as the receiver-SMTP) to log or otherwise transmit
   information about null address events locally if that is desired.  If
   the address is an explicit source route, it MUST be stripped down to
   its final hop.

So it specifically codifies that <> is to be used if you don't want a
notification.

Nowhere does 2821 actually *RESERVE* <> for bounces.

RFC1891, section 10.4:

10.4 Relay to Bombs.AF.MIL

   The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which
   does not support the SMTP extension.  Because the sender specified
   NOTIFY=NEVER for recipient Fred(_at_)Bombs(_dot_)AF(_dot_)MIL, the SMTP at 
Pure-
   Heart.ORG chooses to send the message for that recipient in a
   separate transaction with a reverse-path of <>.

So here we have an example where <> is specifically used to get the
behavior of 1891 'notify=never' with a remote MTA that doesn't support it,
even when sending a non-bounce mail.

pgpToqVFTb8Wo.pgp
Description: PGP signature