Я обнаружил, что отчет о состоянии доставки имеет тот же идентификатор сообщения, что и исходное письмо.
Вот текст отчета о доставке:
Входящее сообщение DSN:
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
Соответствующее исходящее письмо:
From: info@foo.de
Message-ID: <20120209072202.27101.38867@foo-work.tbz-pariv.lan>
Я не мог найти ничего об этом из Страница в Википедии сообщения о недоставке.
Есть ли спецификация для этого, или это просто способ, которым этот конкретный почтовый сервер обрабатывает это?
Я только что проверил одно из моих отклоненных писем и исходное отправленное письмо.
Исходное сообщение имеет заголовок Message-ID со значением, аналогичным этому:
Message-ID: <XYZ@mydomain>
Отказанное сообщение ссылается на этот идентификатор в двух местах заголовка:
References: <....>, <XYZ@mydomain>
In-Reply-To: <XYZ@mydomain>
Также в прикрепленном файле details.txt я вижу:
X-Original-Message-ID: <XYZ@mydomain>
Идентификатор сообщения в возвращенном сообщении имеет другой идентификатор, в котором указан домен почтового сервера:
Message-ID: <ABC@mailserverdomain>
В заключение, то, что вы испытываете, может быть специфическим для вашей установки. Поскольку идентификатор сообщения используется для идентификации каждой почты, для этого конкретного почтового сервера не имеет смысла заменять неисправную почту своей собственной копией, если она будет повторена когда-нибудь в будущем.
DSN сам по себе является сообщением. Таким образом, его общие заголовки определены в RFC822 4.6.
Это поле содержит уникальный идентификатор (блок адреса локальной части), который относится к ЭТОЙ версии ЭТОГО сообщения.
Уникальность идентификатора сообщения гарантируется хостом, который его генерирует. Этот идентификатор предназначен для машинного чтения и не обязательно имеет значение для людей. Идентификатор сообщения относится только к одному экземпляру конкретного сообщения; каждая последующая редакция сообщения должна получать новые идентификаторы сообщения.
Хорошо включать исходный идентификатор сообщения в заголовок REFERENCES и IN-REPLY-TO (см. Тот же раздел RFC822, и это также рекомендуется RFC3834 3.1.6 который не применяется напрямую к DSN, но может приниматься во внимание, если он не противоречит RFC3461). Также можно использовать общий заголовок расширения X-ORIGINAL-MESSAGE-ID. RFC3464 2.4.
Если система генерации предпочитает не создавать / не создавать уникального сообщения IF для сообщения, она должна опустить этот оптический заголовок и не копировать уникальный идентификатор исходного сообщения.
DSN-идентификатор исходного сообщения может / должен быть включен в третью часть сообщения multipart / report delivery-status по умолчанию / если отправитель не запрашивает иное. Думал, что MUA работают с идентификатором конверта для подключения DSN к сообщению. RFC3464 2 RFC3461 4.3 RFC3462
Идентификатор сообщения - это уникальный идентификатор сообщения. Поэтому его необходимо использовать при сообщении статуса этого сообщения. Это не идентификатор, если он есть, который будет использоваться агентом доставки сообщений для доставки сообщения. Его может использовать ваш почтовый клиент для группировки сообщения с любыми сообщениями о состоянии.
Существуют дополнительные заголовки, которые можно использовать при ответе на сообщения, чтобы позволить собрать беседу по электронной почте в цепочку.