On Tue, 4 May 1999 15:38:36 -0400, Mark London <[log in to unmask]> wrote:

>This is because it sends a blank address in the
>MAIL FROM: command in the SMTP protocol.  I.e.:
>
>MAIL FROM:<>

I would point you to the FAQ but it is not available at the moment.  So here is
our take on that:

On Wed, 10 Dec 1997 12:01:01 -0700, [log in to unmask] (Ben Parker) wrote:

>In the past 2-3 weeks L-Soft international Inc., makers of LISTSERV(R) Mailing
>List Management software have experienced an abnormally large number of user
>support complaints regarding inability of the users to control or manage their
>mailing lists.  List Owners/Managers send command msgs to LISTSERV and expect a
>command acknowledgement msg in return.  These command acknowledgement msgs are
>*required* by RFC821 to have a null or empty <return-path> precisely to avoid
>creating a mail loop (see below).
>
>      RFC821 (STD 10) Sect 3.6 reads in part:
>
>     "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:<>
>
>It seems that may ISP's (and other mail gateways), in a well-meaning but
>misguided effort to reduce spam/UCE mail, have mistakenly implemented a
>filtering mechanism to reject mail with blank MAIL FROM:<>.  This is unfortunate and
>improper for 2 reasons.  First, it violates important Internet Mail Standards:
>
>         RFC1123 Sect 5.2.9  reads:
>
>        "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.
>
>This means that mail agents which intend to comply with the standards MUST
>accept and correctly process mail with a null From:<> address.  Mail agents
>which do not, or which have been configured to reject such mail are
>non-compliant with internet standards.
>
>Second, it is unfortunate but many spammers have already abandoned this method
>of spamming, and moved on to other methods, just as they have responded to
>reverse DNS verification of origin address/domain, and the elimination of SMTP
>source route addressing and mail relaying by most sites.  So this is largely a
>case of closing the barn door after the horse has already escaped.
>
>We at L-Soft, strongly urge ISP's and others in charge of implementing SMTP mail
>gateways to bring themselves back into compliance with internet standards and
>restore their users/customers ability to receive these legitmate, desired, and
>necessary email messages.