> Has anyone else noticed this problem?  Command responses from the server
> are not delivered.  Posts however, are delivered.  I've had an extended
> conversation about the problem with Hotmail's autoresponse programs, with
> no apparent interest from anything breathing.  I thought it might be some
> peculiar filter instituted because of my complaining about spam, but now
> several of my subscribers' Hotmail addresses are doing the same thing.
> They can't get command responses, so can't respond to confirmations.

It sounds like they have begun rejecting mail with blank  MAIL FROM: <>
(blank return-path) lines which Listserv does send in responce to commands.

Here's an old message on the subject:
__________________________

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