| Previous | Contents | Index | 
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 2002 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 2002 11:49:26 +1000 From: PMDF Mail Server <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,3 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 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.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, 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.
      3 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 |