Mark London <[log in to unmask]> wrote:
>MAIL FROM:<>
>
>A real address is specified in the message header itself.   I believe that
>more and more people are going to testing for this situation.  Is there a way
>to correct LISTSERV to specify the address in the MAIL FROM: command also?
>Thanks.

Bad!  Here's the message I sometimes send out to domains from which I get
bounces from them not accepting <> as a sender:

--- Begin forwarded message --------
Per the above exchange, your mail host is behaving incorrectly.  As such,
your users are not receiving notices about delivery failures that they need
to know about; they probably think the mail is being delivered when it is
not.  To adhere to internet standards, you must modify your MTAs behaviour.
Please note the following RFC sections (MUST is the strongest language
available in Internet RFCs which must be employed to have a complient
system):

  RFC1123, sections 5.2.9, and 5.3.3 as clarification of RFCs 821 & 822:
      5.2.9  Command Syntax: RFC-821 Section 4.1.2

         The syntax shown in RFC-821 for the MAIL FROM: command omits
         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
         15).  An empty reverse path MUST be supported.

      5.3.3  Reliable Mail Receipt
         [ ... ]
         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; see Section 3.6 of RFC-821.  The
         recipient of this notification SHOULD 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.  If the address is an explicit source route, it
         SHOULD be stripped down to its final hop.

  RFC0821, section 3.6:
   3.6.  RELAYING
         [ ... ]
      If a server-SMTP has accepted the task of relaying the mail and
      later finds that the forward-path is incorrect or that the mail
      cannot be delivered for whatever reason, then it must construct an
      "undeliverable mail" notification message and send it to the
      originator of the undeliverable mail (as indicated by the
      reverse-path).

      This notification message must be from the server-SMTP at this
      host.  Of course, server-SMTPs should not send notification
      messages about problems with notification messages.  One way to
      prevent loops in error reporting is to specify a null reverse-path
      in the MAIL command of a notification message.  When such a
      message is relayed it is permissible to leave the reverse-path
      null.  A MAIL command with a null reverse-path appears as follows:

         MAIL FROM:<>

The act of not complying leaves you at risk of having mail acceptance from
your domain blocked until you do.
--- End forwarded message --------


These RFC's are currently being revised and combined, but that particular
requirement is not changing.  I'll update my nasty-gram when they're final.


-philip

--
Philip Kizer <[log in to unmask]>
Texas A&M CIS Operating Systems Group, Unix