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

Question

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

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

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

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

Мы используем следующие документы для справки: VERP RFC отказов сообщения

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

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

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

Answer 1

Давайте начнем с простого примера. Допустим, у вас есть список адресов электронной почты, который будет рассылать следующий 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. Предполагается, что это сообщение от кого. Это то, что вы видите как «ОТ» в большинстве почтовых клиентов. Если в электронном письме отсутствует заголовок «Ответить», то все ответы пользователей (почтового клиента) должны возвращаться на адрес ОТ.

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

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

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

Answer 2

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

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

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

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

Answer 3

для тех, кто сюда попал, потому что название вопроса:

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

Answer 4

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