Какова разница в поведении между обратным путем, ответом и от?

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

FROM: [email protected]
TO: [email protected]
Return-PATH: [email protected]

Проблема, с которой мы сталкиваемся, заключается в том, что некоторые серверы электронной почты мгновенно возвращают сообщение и используют вместо него или обратно путь ([email protected]) на наш сервер bounce mgmt. Мы хотим знать, изменим ли мы в заголовке ответ, чтобы он был таким же, как обратный путь, если мы сможем поймать все отскоки.

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

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

SMTP Log Parsing, чтобы получить Bounces

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

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

ОТВЕТЫ

Ответ 1

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

From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>

This is a very simple body.

Теперь скажем, что вы собираетесь отправить его из списка рассылки, который реализует VERP (или какой-то другой механизм отслеживания отказов, который использует другой путь возврата). Допустим, у него будет обратный путь [email protected] Сеанс SMTP может выглядеть так:

{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<[email protected]>
{S}250 2.1.0 [email protected] OK
{C}RCPT TO:<[email protected]>
{S}250 2.1.5 [email protected] 
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>

This is a very simple body.
.

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

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

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

Return-Path: [email protected]
From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>

This is a very simple body.

Теперь опишите разные "ОТ".

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

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

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

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

  • Заголовок Reply-To добавляется отправителем (или программным обеспечением отправителя). Здесь также должны быть затронуты все ответы человека. В основном, когда пользователь нажимает "ответить", значение Reply-To должно быть значением, используемым как реципиент вновь созданного письма. Значение Reply-To не должно использоваться ни одним сервером. Он предназначен для использования на стороне клиента.

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

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