PMDF System Manager's Guide


Previous Contents Index

33.4.10 From: Address Missing in Notifications from PMDF

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 can be presented with a message header fragment like the one shown below


From   Thu Jul 11 11:50:23 2012 
Received: from vulcan.ajax.com by monster.ajax,com via SMTP 
  (930416.SGI/931108.SGI.ANONFTP) for xxxx id AA21154; 
  Thu, 11 Jul 02 11:50:23 +1100 
Date: Thu, 11 Jul 2012 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. 4

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 can 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 can use the returnenvelope channel keyword; see Section 2.3.4.64. Be warned: Use of either the option or the channel keyword will put you in violation of the Internet Host Requirements and, more importantly, can lead to looping mail. Looping mail will not only inconvenience you but can 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.

Note

4 Some mailers will preferentially send notifications to the address specified with the non-standard Errors-to: or Warnings-to: header lines. By default, PMDF itself sends notifications to the envelope From: address, unless configured otherwise via the USE_ERRORS_TO and USE_WARNINGS_TO PMDF options.


Previous Next Contents Index