Well, in truth, MAIL FROM:<> is not only legal, special note was made under RFC1123 that it MUST be supported. Here is our position on it, from our FAQ: V. 16. LISTSERV uses a null return path (RFC821 MAIL FROM:<>) on its administrative mail, and some of our list owners' and/or subscribers' mail hosts reject this. Can the null return path be changed? No. The MAIL FROM:<> is per standard (RFC 821 [STD 0010] as updated by RFC 1123 [STD 0003]) for any message generated by an automatic "daemon" process that should imperatively not be responded to by another automatic "daemon" process. This is to prevent a loop from starting if the administrative mail should happen to bounce. Unfortunately some ISPs have started blocking mail with MAIL FROM:<> as an anti-spamming measure. About all we can say about this is that a) it's against the standard, and b) savvy spammers have already found ways around it. So as it turns out, this is not really a good way to block spam, and our recommendation to any site that rejects such mail is to follow the standard and accept mail with the null return path. The specific sections of the standards that apply are: Excerpted from RFC821 (STD 0010) Sect 3.6: ------------------------------------------ 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:<> Excerpted from RFC1123 (STD 0003) Sect 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.