Thanks you very much, you have answered many questions for  me.  I will definitely
forward the contents of this note to my ISP.

Liz Conklin

Ben Parker wrote:

> 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]