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