Occassionally users or postmasters on other mail systems will complain that PMDF is losing, dropping, forgetting, or otherwise omitting the envelope From: address in messages it sends. You may be presented with a message header fragment like the one shown below
From Thu Jan 13 11:50:23 1994 Received: from vulcan.ajax.com by monster.ajax.com via SMTP (930416.SGI/931108.SGI.ANONFTP) for xxxx id AA21154; Thu, 13 Jan 94 11:50:23 +1100 Date: Thu, 13 Jan 1994 11:49:26 +1000 From: PMDF Mail Server <postmaster@vulcan.ajax.com>Note how in the first line there is a noticeable blank space between the From and date? This header line is often referred to as the colonless From line and it gives the envelope From: address for the message. That blank space indicates that the message had no envelope From: address; that is, it had what is called in the mail business a null return path. Note further that this was an automatically generated mail message as suggested by the RFC 822 From: address of postmaster@vulcan.ajax.com.
The relevant standards require that automatically generated messages such as non-delivery notifications and delivery receipts use a null return path. As mailers are supposed to bounce mail to the envelope From: address,³ this helps to prevent mail loops from occurring.
If someone complains about the missing From: address, ask them to send you a sample offending message. Determine if it was an automatically generated message. If it was, then explain to them that if their mailer or user agent is incapable of handling null return paths then it is incompliant with RFC 821 and 1123. Refer them to Paragraph 8 of Section 3.6 and the second paragraph of the MAIL command description in Section 4.1.1 in RFC 821. Further point out that were you to change your mailer to use a non-null return path for automatically generated notifications, then you would be violating the Internet Host Requirements; specifically, you would be in violation of Section 5.3.3 of RFC 1123.
Now, if for some reason you absolutely must generate non-null return
paths in your notification messages, then you may do so with the
RETURN_ENVELOPE option of the PMDF option file; see Section 7.3.4 . Or
to generate non-null return paths in notification messages only for a
particular channel or channels, you may use the
returnenvelope channel keyword; see Section 2.3.4.63 . Be
warned: Use of either the option or the channel keyword will put you in
violation of the Internet Host Requirements and, more importantly, may
lead to looping mail. Looping mail will not only inconvenience you but
may cause serious problems for some unfortunate site which gets into a
loop with your system. Also, keep in mind that changing PMDF's behavior
so as not to cause problems for a broken mailer which cannot handle
null return paths does not really fix anything: Other mailers over
which you have no control will continue to send the broken mailer
messages with null return paths. The only satisfactory solution in this
situation is to fix the broken mailer.