On Fri, 2 Jan 1998 14:58:03 -0500, Liz Conklin <[log in to unmask]> wrote:

>Here is a copy of the letter that I received from the administrator of my ISP
>here in Indy.  Although I am at a not well versed in any of this yet perhaps it
>would explain some of the problems with the Virgin.Net situation.
>
>
>Patrick Rainbolt wrote:
>>        The only thing we did was allow people to send null's (or no
>>userids) as valid user names. This means that the listserve that started
>>working are not setup correctly according to RFC822 protocols or the
>>gateway they are going through is sending out the user name as a null. We
>>will leave this like this for a couple weeks but since it is a security
>>hole it will eventually be plugged. We currently are discussing the
>>posibility of allowing null's as user name but nothing set in stone as of
>>yet.

Hmmmm.  What I quote below is probably not related to the Virgin.Net problem,
but does speak directly to the above.  Feel free to quote this to your own ISP
is you are having similar problems.  (AOL is not safe either...)

In the past few 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 by email and
expect to receive 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 many 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 From:<>.  This is unfortunate and
improper for 2 reasons.  First, it violates important Internet Mail Standards:

         RFC1123 (STD 3)  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 simply
non-compliant with current 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 gone.

We at L-Soft, strongly urge ISP's and others in charge of implementing SMTP mail
gateways to bring themselves back into compliance with all internet standards
and restore their users/customers ability to receive these legitmate, desired,
and necessary email messages.

--
 __________________________________________________________________
 Ben Parker ..... L-Soft international Inc. ..... [log in to unmask]