Re: [exim] Which behaviour is expected/standard from a retur…

Top Pagina
Delete this message
Reply to this message
Auteur: Tony Marques
Datum:  
Aan: exim-users
Nieuwe Onderwerpen: Re: [exim] Which behaviour is expected/standard from a return-pathvalue?
Onderwerp: Re: [exim] Which behaviour is expected/standard from a return-path value?
If by "i send out emails through exim with a forced return-path to
root", you mean you insert a "Return-path:" header yourself, then that
is not RFC compliant and it proper that Exchange or any other MTA or
wannabe MTA to ignore such headers. The "return path" as opposed to
"return-path" as in "Return-Path: header" is different.

You should be discussing the MAIL FROM: in the SMTP envelope and it's
value as that is where Exchange should (and usually does) bounce
messages...

...except if Exchange redirects the message to another SMTP recipient
as then it does seem to use the From: header when forwarding, rightly
ignoring a pre-existing Return-Path: header but stupidly ignoring the
original MAIL FROM: in the SMTP envelope which it may have already
discarded without storing the value in a new Return-Path: header which
it should remove again before forwarding.


The "return path" should be exclusively derived from the SMTP
protocol's MAIL FROM: command while travelling in SMTP space and it
would be upto Exchange or whatever ultimate recipient to create the
"Return-Path: header" when the "final delivery" is made and it is
deposited in a mailbox per RFC822 4.3.1 or otherwise leaves SMTP
space.  RFC2821 is more explicit on Return-Path: headers and says
stuff like:
    A message-originating SMTP system SHOULD NOT send a message
    that already contains a Return-path header.



So Return-Path: headers should never be found in messages MTA's
receive or deliver.  It is also wrong for Return-Path: formats to be
appear like...
    Return-Path: "John Smith" <some@???>
as they logically should be derived from the MAIL FROM: in the SMTP
protocol envelope.



If it was up to me I would bounce all messages with Return-Path:
headers as non-RFC compliant, but that isn't pratical and not RFC
complaint either (since no inspection is supposed to be made, haha).