Tue, 4 May 1999 14:11:45 -0600
|
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.
|
|
|