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