Message-ID of delivery report is equal to original mail

Question

I discoverd that the delivery status report has the same message-id as the original mail.

Here is the text of the delivery report:

Incoming DSN message:

From: Mail Delivery Subsystem <postmaster@example.com>
To: info@foo.de
Subject: DELAY:     ********************************************** 
Message-ID: <20120209072202.27101.38867@foo-work.tbz-pariv.lan>
...

    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Wed, 23 Mar 2016 14:36:53 +0100
from [x.x.x.x]

   ----- Transcript of session follows -----
user@example.com... Deferred: Connection timed out with gmail.de.
Warning: message still undelivered after 4 hours
Will keep trying until message is 4 days old

Corresponding outgoing original mail:

From: info@foo.de
Message-ID: <20120209072202.27101.38867@foo-work.tbz-pariv.lan>

I could not find anything about this from the Bounce Message Wikipedia page.

Is there a spec for this, or is this just the way this particular mail server handles this?

Answer 1

I just checked one of my bounced emails and the original sent email.

Original message has a Message-ID header with a value similar to this:

Message-ID: <XYZ@mydomain>

Bounced message refers to this ID in two places in the header:

References: <....>, <XYZ@mydomain>
In-Reply-To: <XYZ@mydomain>

Also in the attached details.txt I see:

X-Original-Message-ID: <XYZ@mydomain>

The Message ID in the bounced message has a different ID, with mail server's domain in it:

Message-ID: <ABC@mailserverdomain>

In conclusion, what you are experiencing could be specific to your setup. Since Message ID is there to identify each mail, it does not make sense for this particular mail server to replace failed mail with its own copy if it will be retried sometime in the future.

Answer 2

The DSN is itself a message. So its gerneral headers are defined in RFC822 4.6.

This field contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message.
The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message should each receive new message identifiers.

It's good to include the original message-id in REFERENCES and IN-REPLY-TO header (see same section of RFC822 and it is also recommended by RFC3834 3.1.6 which does not diretcly apply to DSNs but can taken into consideration as well as long as it does not conflict with RFC3461). Also the use of the common extension header X-ORIGINAL-MESSAGE-ID is fine RFC3464 2.4.
If the generating system opt to not wanting/needing to generate a unique message IF for the message it should omit that optinal header and not copy the original messages unique-id.

DSN secific the message-id of original message can/shall be included in the third part of the multipart/report delivery-status message as default / when not otherwise requested by sender. Thought it's whiched that the MUAs work with envelope-id to connect the DSN to the message. RFC3464 2 RFC3461 4.3 RFC3462

Answer 3

The message-id is the unique ID for the message. As such it is necessary to use it when reporting status of that message. This is not the id, if any, that will be used to by Message Delivery Agent to deliver the message. It may be used by your mail reader to group the message with any status messages.

There are additional headers that can be used when replying to messages to enable the email conversation to be gathered into a thread.