> Hi, this from my own new [and only] local ISP..
>
> I sent her all the documentation from
> http://www.lsoft.com/manuals/lsv-faq.stm#5.16
>
> and that didn't seem to do it.
>
> I told her I was forwarding her question to the list and will forward the
> answer on to her.. THANKS for any help anyone can give!
>
>   .. CK
>
> ------- Forwarded message follows -------
> From:                   "Jackie Bates" <[log in to unmask]>
> Copies to:              <[log in to unmask]>
> Subject:                Re: (Fwd) test if NULL not working on listserv
> Date sent:              Sat, 17 Jun 2000 11:48:14 -0500
>
> The blocking of NULL return addresses stops thousands of junk mail
> per month.  We don't block NULL addresses after I checked, so I don't
> know what the problem is.  What valid reason do they offer not to add
> the return address?  It seems that would help a lot of sites block
> SPAM and they would be for that?  I also checked the vix blackhole
> list to see if they are on it, but I didn't see their ip address
> listed.
>
> Jackie Bates


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 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 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
legitimate, desired, and necessary email messages.

--
John Lyon
L-Soft international, Inc.
http://www.lsoft.com