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

StackOverflow https://stackoverflow.com/questions/1235534

Вопрос

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

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

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

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

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

Синтаксический анализ журнала 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.

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

<Ол>
  • Обратный путь (иногда называемый обратным путем, отправителем конверта или конвертом - все эти термины могут использоваться взаимозаменяемо) - это значение, используемое в сеансе 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 не должно использоваться никаким сервером. Он предназначен только для использования на стороне клиента.

      3. Однако, как вы можете сказать, не все почтовые серверы подчиняются стандартам или рекомендациям 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 в качестве конечного почтового сервера компании.

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top