LISTSERV uses a null return path (RFC821 MAIL FROM:<>) on its administrative mail, and some of our list owners' and/or subscribers' mail hosts reject this. Can the null return path be changed?


No. The MAIL FROM:<> is per standard for any message generated by an automatic "daemon" process that should imperatively not be responded to by another automatic "daemon" process. This is to prevent a loop from starting if the administrative mail should happen to bounce.


Unfortunately some ISPs have started blocking mail with MAIL FROM:<> as an anti-spamming measure. About all we can say about this is that a) it's against the standard, and b) savvy spammers have already found ways around it. So as it turns out, this is not really a good way to block spam, and our recommendation to any site that rejects such mail is to follow the standard and accept mail with the null return path.


Very little has changed in the standards in this regard since RFC821, regardless of the positions taken by certain large ISPs.  The specific sections of the current standards that apply are:


Excerpted from RFC5321 Sect 3.6.3:


Of course, SMTP servers MUST NOT send notification messages about problems transporting 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 transmitted, the reverse-path MUST be set to null (see Section 4.5.5 for additional discussion).  A MAIL command with a null reverse-path appears as follows:


MAIL FROM:<>


Excerpted from RFC5321 Sect 4.5.5:


Implementers of automated email processors should be careful to make sure that the various kinds of messages with a null reverse-path are handled correctly.  In particular, such systems SHOULD NOT reply to messages with a null reverse-path, and they SHOULD NOT add a non-null reverse-path, or change a null reverse-path to a non-null one, to such messages when forwarding.