> My speculation is that their messages did receive LISTSERV
 > but they never got the command confirmation becuase
 > their ISPs are blocking mail with null return paths.  (See
 > http://www.lsoft.com/manuals/lsv-faq.stm#5.16 for more information
 > on this problem.)  This is just an educated guess, though, and you
 > may have information that rules this out.

In the for-what-it's-worth department, we've had several problems
with sites who do this.  It violates at least six RFCs, list follows.
I'm beginning to be willing to help with an education campaign aimed
at stamping out this ill-conceived idea.

Dennis Boone
H-Net

RFC2505 (spam prevention), section 2, recommendation 6a:

        MUST NOT refuse "MAIL From: <>".

RFC821 (SMTP), section 3.7:

        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:<>

RFC2476 (message submission), section 3.2:

        Note that a null return path, that is, MAIL FROM:<>, is
        permitted and MUST be accepted. (MUAs need to generate null
        return-path messages for a variety of reasons, including
        disposition notifications.)

RFC1904 (DSN), section 2:

        The envelope sender address of the DSN SHOULD be chosen to
        ensure that no delivery status reports will be issued in
        response to the DSN itself, and MUST be chosen so that DSNs
        will not generate mail loops.  Whenever an SMTP transaction
        is used to send a DSN, the MAIL FROM command MUST use a NULL
        return address, i.e. "MAIL FROM:<>".

RFC1891 (DSN), section 7.1:

        The DSN sender address (in the SMTP MAIL command) MUST be a
        null reverse-path ("<>"), as required by section 5.3.3 of [9].
        The DSN recipient address (in the RCPT command) is copied from
        the MAIL command which accompanied the message for which the
        DSN is being issued.  When transmitting a DSN via SMTP, the RET
        parameter MUST NOT be used.  The NOTIFY parameter MAY be used,
        but its value MUST be NEVER.  The ENVID parameter (with a newly
        generated envelope-id) and/or ORCPT parameter MAY be used.

RFC1123 (requirements for internet hosts), section 5.2.9:

        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.