RFC822 на Return-Path::
Это поле добавляется конечной транспортной системой, которая доставляет сообщение получателю. Поле предназначено для содержания окончательной информации об адресе и маршруте к отправителю сообщения.
Так почему же в некоторых электронных письмах их два? (В моем примере обычно один в конце и один в начале, исходя из чего я предполагаю, что клиент добавил его туда.) только один автор?
Это плохая привычка некоторых клиентов?
Return-Path обычно добавляется вверху при получении электронного письма. В частности, это могло произойти во время передачи SMTP команды «MAIL FROM». Он может не совпадать с адресом электронной почты в заголовках From :, Reply-To: или Sender :. Если внизу есть второй обратный путь, он, скорее всего, будет подозрительным, возможно, добавленным после того, как доставка уже завершена.
… И вспомогательные документы, хотя и в некоторой степени несовершенны, все же пытаются объяснить, что RFC 822 либо допускал для того, что мир решил не делать, либо прямо ошибся.
Разве не один составитель?
В Return-Path: и Delivered-To: заголовки не обозначают создатель и получатель. Они содержат конверт сообщения после того, как сообщение покинуло среду SMTP и, таким образом, больше не разбивается на конверт и содержание - как это происходит, когда агент локальной доставки записывает конверт сообщения и содержимое сообщения в файл почтового ящика в точке локальной доставки.
Это плохая привычка некоторых клиентов?
Это плохая привычка MUA или MTA, которые отправили сообщение, или какого-либо промежуточного шлюза из среды SMTP. Самый верхний поля трассировки почти наверняка будет добавлен вашим местным агентом по доставке. Те, что ниже, были добавлены чем-то еще. Ваш LDA может удалить существующие заголовки конвертов при добавлении собственных. Но это не обязательно и явно не требуется.
Это либо дурные привычки клиентов, либо спам.
Вы можете определить, является ли это последним, проверив содержимое и остальные заголовки.
Return-Path - один из немногих заголовков, которые MTA будет проверять, и который MTA ДОЛЖЕН удалить и заменить своим собственным.
Некоторые учетные записи электронной почты могут иметь возможность отправлять электронную почту «От имени…», которая будет использовать другой сервер для маршрутизации электронных писем. Тогда это будет включать несколько электронных писем в ответ. В противном случае другой пример может быть, если приложение php отправляет электронные письма через сервер - вы можете указать обратный адрес или адреса (иногда вы даже можете подделать ответный адрес).
Очевидно, что лучшей привычкой было бы, чтобы ваша клиентура публиковала только один ответный адрес для определения местоположения транзакций электронной почты и других задач отладки (если требуется).
" Once the transmission channel is established and initial handshaking
completed, the SMTP client normally initiates a mail transaction.
Such a transaction consists of a series of commands to specify the
originator and destination of the mail and transmission of the
message content (including any headers or other structure) itself.
When the same message is sent to multiple recipients, this protocol
encourages the transmission of only one copy of the data for all
recipients at the same destination (or intermediate relay) host."
Источник: http://www.ietf.org/rfc/rfc2821.txt
Также: Стандарт для текстовых интернет-сообщений ARPA
C.3.2. FROM
The "From" field must contain machine-usable addresses (addr-
spec). Multiple addresses may be specified, but named-lists
(groups) may not.
Источник: http://ietfreport.isoc.org/idref/rfc822/