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.