Previous | Next | 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 |