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

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

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-сервер, ретранслирующий сообщение, отклоняется, он отправляет его в ответ на запрос, но когда это происходит после одного прыжка, он отправляет его в обратный путь.

Давайте начнем с простого примера. Допустим, у вас есть список адресов электронной почты, который рассылает следующий контент 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.

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

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

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

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

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

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

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

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

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

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

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