[exim-dev] [Bug 2568] Error messages (DSN) are inconsistent …

Top Page
Delete this message
Reply to this message
Author: admin
Date:  
To: exim-dev
Subject: [exim-dev] [Bug 2568] Error messages (DSN) are inconsistent and misleading
https://bugs.exim.org/show_bug.cgi?id=2568

Heiko Schlichting <heiko@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Exim 4.95+                  |Exim 4.94


--- Comment #2 from Heiko Schlichting <heiko@???> ---
I insist that it is a bug.

Commit message for 436bda2 also worries about "leaked information of the
results of local forwarding", but this information is already in the text/plain
part and there is no "leak" at all.

And it is not "mailbox address of the recipient ... as it was when the
Reporting MTA accepted the message for delivery." anyway, because there was
only one recipient but there are multiple lines with all the same addresse per
recipient after local processing (in my example there are two lines but there
could be much more for long lists of recipients). And RFC 3464 says: "The
Final-Recipient address may differ from the address originally provided by the
sender". If Exim wants to show the unmodified address it should provide
"Original-Recipient" (RFC 3464, 2.3.1) in addition(!). For "Original-Recipient"
it would be correct to use the parent address but only once in my example.

And this causes real problems if MTAs (like Exchange) only show the
message/delivery-status part an strips the other text. While this is not a good
idea at all (and not Exims fault), Exim should generate helpful and consistent
DSNs with the same addresses in both parts. A for the sender (and the
postmaster) it is important which address really fails, and this is NOT the
parent address at all.

Think of a large list of recipients and lists in lists. My example was very
basic and stripped to the absolute minimum. In more realistic situations it is
impossible to determine the failed addresses from the message/delivery-status
part. This is not the idea of a DSN or RFC 3464.

--
You are receiving this mail because:
You are on the CC list for the bug.