Какая разница в поведении между return-path, reply-to и from?

162

В нашем почтовом приложении мы отправляем электронные письма со следующим заголовком:

FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com

Проблема, с которой мы сталкиваемся, заключается в том, что некоторые почтовые серверы немедленно возвращают сообщение и используют вместо него обратный путь от (marketing@customer.com) к нашему серверу bounce mgmt. Мы хотим знать, изменим ли мы в заголовке значение response-to, чтобы оно совпадало с путем возврата, если мы сможем перехватить все возвраты.

Любые другие идеи приветствуются?

В качестве ссылок мы используем следующие документы: VERP RFC Bounce Messages

Разбор протокола SMTP для получения отказов

РЕДАКТИРОВАТЬ 1: Еще несколько битов информации, чтобы увидеть, сможем ли мы получить это решение.

Мы хотим знать, в какой момент почтовый сервер, передающий сообщение, выберет использование ответа на запрос вместо пути возврата. Мы заметили, что, когда первый SMTP-сервер, ретранслирующий сообщение, отклоняется, он отправляет его в ответ на запрос, но когда это происходит после одного прыжка, он отправляет его в обратный путь.

Geo
источник
1
Как насчет указания полей Отправитель: и Приоритет:? Я хотел бы узнать больше о том, как они влияют на разные почтовые серверы, когда речь идет о скачках и автоматических ответах вне офиса. Кто - нибудь?
PapaFreud

Ответы:

257

Давайте начнем с простого примера. Допустим, у вас есть список адресов электронной почты, который рассылает следующий контент RFC2822 .

From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

Теперь предположим, что вы собираетесь отправить его из списка рассылки, который реализует VERP (или какой-то другой механизм отслеживания отказов, который использует другой путь возврата). Допустим, у него будет обратный путь coolstuff-you=yourcompany.com@mymailinglist.com. Сеанс SMTP может выглядеть так:

{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com@mymailinglist.com>
{S}250 2.1.0 me@mycompany.com....Sender OK
{C}RCPT TO:<you@yourcompany.com>
{S}250 2.1.5 you@yourcompany.com 
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.
.

{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel

Где {C} и {S} представляют команды клиента и сервера соответственно.

Почта получателя будет выглядеть так:

Return-Path: coolstuff-you=yourcompany.com@mymailinglist.com
From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

Теперь давайте опишем различные «ОТ».

  1. Обратный путь (иногда называемый обратным путем, отправителем конверта или конвертом - все эти термины могут использоваться взаимозаменяемо) является значением, используемым в сеансе SMTP в MAIL FROMкоманде. Как видите, это не обязательно должно быть то же значение, что и в заголовках сообщений. Только почтовый сервер получателя должен добавлять заголовок Return-Path в начало письма. Это записывает фактического отправителя Return-Path во время сеанса SMTP. Если заголовок Return-Path уже существует в сообщении, этот заголовок удаляется и заменяется почтовым сервером получателя.

Все отскоки, которые происходят во время сеанса SMTP, должны возвращаться к адресу Return-Path. Некоторые серверы могут принимать всю электронную почту, а затем ставить ее в очередь локально, пока у нее не появится свободная нить для доставки ее в почтовый ящик получателя. Если получатель не существует, он должен вернуть его обратно к записанному значению Return-Path.

Обратите внимание, что не все почтовые серверы подчиняются этому правилу; Некоторые почтовые серверы возвращают его обратно на адрес FROM.

  1. Адрес FROM - это значение, найденное в заголовке FROM. Предполагается, что это сообщение от кого. Это то, что вы видите как «ОТ» в большинстве почтовых клиентов. Если электронное письмо не имеет заголовка Reply-To, то все ответы человека (почтового клиента) должны возвращаться на адрес FROM.

  2. Заголовок Reply-To добавляется отправителем (или программным обеспечением отправителя). Это где все человеческие ответы должны быть рассмотрены тоже. По сути, когда пользователь нажимает «ответить», значение Reply-To должно быть значением, используемым в качестве получателя вновь составленного электронного письма. Значение Reply-To не должно использоваться никаким сервером. Он предназначен только для клиентского использования (MUA).

Однако, как вы можете сказать, не все почтовые серверы подчиняются стандартам или рекомендациям RFC.

Надеюсь, это должно помочь прояснить ситуацию. Однако, если я что-то пропустил, дайте мне знать, и я постараюсь ответить.

Дэйв Ванта
источник
Это очень полезно. Спасибо за ваше время. Один вопрос. Может ли случиться так, что некоторые отклики идут к ответу вместо пути возврата?
Geo
5
Ну, технически вы можете (но не должны) добавлять заголовок пути возврата, однако, если заголовок пути возврата существует, он должен быть перезаписан получающим сервером smtp. Если ничего не существует, его следует добавить в верхнюю часть заголовков.
Дэйв Ванта
7
Мне немного непонятно, как return-pathэто используется. Если return-pathпредполагается, что это обратный адрес, почему почтовый сервер получателя заполняет это поле вместо отправителя? Как сервер получателя мог бы знать, что туда поместить? Разве это не кажется задом наперед?
великий волк
6
Почтовый сервер получателя вставляет заголовок Return-Path в сообщение, копируя значение, предоставленное почтовым сервером отправителя в команде SMTP «MAIL FROM». Представьте себе служащего в почтовом отделении, открывающего почту - они смотрят на обратный адрес на конверте и пишут его в верхней части письма (и выбрасывают конверт).
Джон Хэсколл
5
И как Sender:заголовок вписывается во все это?
Саймон Ист
150

Еще один способ думать о Return-PathпротивReply-To - это сравнить его с обычной почтой.

Когда вы отправляете конверт по почте, вы указываете обратный адрес . Если получатель не существует или отказывается от вашей почты, почтмейстер возвращает конверт обратно на обратный адрес. Для электронной почты, то обратный адрес являетсяReturn-Path .

Внутри конверта может быть письмо, а внутри письма он может указать получателю: «Отправить корреспонденцию на примерный адрес». ». Для электронной почты, то пример адрес являетсяReply-To .

По сути, адрес возврата почтового отправления сопоставим с Return-Pathзаголовком SMTP, а Reply-Toзаголовок SMTP аналогичен инструкциям ответа, содержащимся в письме.

Джесси Хобарт
источник
14
Это хорошая аналогия.
Лукаш Коржибски
2
@Jesse Hobart +1 за хорошее объяснение, я был более смущен, спасибо за то, что мне было легче понять меня.
Абхишек
26
Я хотел бы отметить, что основная концепция, не отраженная в этой аналогии, заключается в том, что Return-Pathзаголовок добавляется получающим почтовым сервером, а не отправителем . Так что это выглядит примерно так: вы можете написать любой адрес внутри конверта, но чтобы доставить его, вы должны взять его с собой на почту и показать свои водительские права (или другое удостоверение личности), и они поместят этот адрес в конверт. перед отправкой. Другими словами, Return-Pathзаголовок так же надежен, как и проверки, выполняемые принимающим SMTP-сервером, где другие могут быть легко подделаны.
cdhowie
5

для тех кто попал сюда из-за заголовка вопроса:

Я использую Reply-To:адрес с веб-формами. когда кто-то заполняет форму, веб-страница автоматически отправляет электронное письмо владельцу страницы. адрес From:автоматического почтового отправителя, поэтому владелец знает, что он из веб-формы. но Reply-To:адрес является тем, который заполняется в форме пользователем, поэтому владелец может просто нажать «Ответить», чтобы связаться с ним.

Robotik
источник
1

Мне пришлось добавить заголовок Return-Path в электронные письма, отправленные экземпляром Redmine. Я согласен с greatwolf, только отправитель может определить правильный (не по умолчанию) Return-Path. Дело в следующем: электронные письма отправляются с адресом электронной почты по умолчанию: admin@yourcompany.com. Но мы хотим, чтобы реальный пользователь, инициирующий действие, получал отказные электронные письма, потому что он будет единственным, кто знает, как исправить неправильные электронные письма получателей. (а не администраторы приложений, у которых есть другие кошки, чтобы взбить :-)). Мы используем это, и это прекрасно работает с exim на сервере приложений и zimbra в качестве конечного почтового сервера компании.

Улыбка
источник