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