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.