Как заголовок Return-Path может отличаться от фактического получателя возврата электронной почты?

Недавно я перенес отправку транзакционной электронной почты на Mailgun.

Пока это работает хорошо, однако мне интересно узнать о заголовке пути возврата.

Рассмотрим это электронное письмо (я удалил ненужный заголовок и заменил адрес электронной почты/домен в целях конфиденциальности)

Delivered-To: [email protected]
Received: by 10.76.154.104 with SMTP id vn8csp478308oab;
        Wed, 4 Sep 2013 05:04:44 -0700 (PDT)
X-Received: by 10.50.22.105 with SMTP id c9mr1537992igf.36.1378296283817;
        Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Return-Path: <[email protected]>
Received: from so254-63.mailgun.net (so254-63.mailgun.net. [198.61.254.63])
        by mx.google.com with ESMTP id k5si1620852igx.55.1969.12.31.16.00.00;
        Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Received-SPF: ...stripped...
Authentication-Results: ...stripped...
DKIM-Signature: ...stripped...
DomainKey-Signature: ...stripped...
Received: by luna.mailgun.net with HTTP; Wed, 04 Sep 2013 12:04:42 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: ...stripped...
From: my-website <[email protected]>
To: [email protected]
Message-Id: <[email protected]>
X-Mailgun-Sid: WyI5YmI1OSIsICJqb2Vob3BmK2VlZ2VpN2lkMm9pbW9vYm9vZmFpQGdtYWlsLmNvbSIsICJjMmIzNyJd
Date: Wed, 04 Sep 2013 12:04:43 +0000
Sender: [email protected]
Content-Transfer-Encoding: base64

...email body...

Это необработанное электронное письмо, отображаемое из реальной почты в почтовом ящике Gmail. Как видите, заголовок Return-Path содержит адрес электронной почты, оканчивающийся на @my-website.com.

Но я настроил записи DNS только для исходящей электронной почты (spf, domainkey и т. д.). Не для входящей электронной почты. Это означает, что мои записи MX по-прежнему указывают на почтовые серверы где-то еще (в моем случае это приложения Google).

Как же тогда возможно, что письмо с отказом приходит на серверы mailgun?

Я ожидал увидеть адрес электронной почты, оканчивающийся на @some-mailgun-server.com, в заголовке Return-Path!

Раньше я использовал Amazon SES, и там у них был заголовок Return-Path, оканчивающийся на amazonses.com.

Я обратился в службу поддержки mailgun и получил такой ответ:

Ник: ваши настройки верны, Mailgun по-прежнему будет автоматически обрабатывать отказы, даже если ваши записи mx указывают в другом месте.

Они просто заверили меня, что все в порядке, но не дали мне никаких объяснений (что нормально, поскольку их работа состоит не в том, чтобы научить меня тому, чего я не знаю, а в том, чтобы предоставить надежный почтовый сервис...)

Так что я надеюсь, что кто-то может объяснить это мне.

Надеюсь суть понятна, если нет, спрашивайте, я постараюсь прояснить свой вопрос.

РЕДАКТИРОВАТЬ:

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

Чтобы проверить эту теорию и поскольку адрес электронной почты Return-Path имеет форму [email protected], а Google доставляет всю электронную почту, независимо от того, что идет после символа +, пользователю перед ним, я пошел дальше и создал учетную запись [email protected] на приложения гугл.

Я также пытался отправить электронное письмо на [email protected].

Оно дошло до моего почтового ящика.

Теперь я ожидал получить возврат трафика в свой почтовый ящик. Поэтому я отправил электронное письмо на несуществующий адрес горячей почты. Я не получил электронное письмо в папке «Входящие» приложений Google, и mailgun успешно отследил отказ.

Итак... Похоже, что это действительно работает. Я просто не понимаю, почему.

Еще одна теория, которая у меня есть, заключается в том, что почтовый сервер, на который доставляется отказное электронное письмо, никогда не разрешается с использованием его записей MX. Скорее всегда выбирается сервер доставки, в данном случае luna.mailgun.net. Домен, оканчивающийся на адрес Return-Path, — это просто имя почтового ящика на сервере, но домен не имеет ничего общего с сервером, на который фактически доставляется почта.

Тогда также имеет смысл сделать это так, поскольку это может улучшить доставляемость, если домены адресов From и Return-Path совпадают.

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

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

Я надеюсь, что кто-то может просветить меня.


person The Surrican    schedule 04.09.2013    source источник
comment
По поводу закрытия голосования по этому вопросу по причине: This question does not appear to be about programming within the scope defined in the help center. -- пожалуйста, уточните. ИМХО, этот вопрос касается правильной реализации протокола, как это определено в RFC 2821, 3834 и 4409. Как больше программирования можно получить без актуального исходного кода?   -  person The Surrican    schedule 05.09.2013
comment
Я предполагаю, что отказной сервер неправильно использует адрес from. У вас есть необработанные заголовки возвращенного электронного письма?   -  person Pekka    schedule 05.09.2013
comment
Привет, @pekka, наконец-то я узнал, что стоит за всем этим. Ваше предположение верно, однако оказывается, что все выглядит иначе. Я напишу ответ на этот вопрос прямо сейчас.   -  person The Surrican    schedule 05.09.2013


Ответы (1)


Оказывается, есть разные виды отскоков.

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

Вот почему они отправляются на серверы мейлганов и также попадают туда.

Однако существуют также так называемые «отложенные отказы», ​​которые отправляются на сервер, объявленный почтовым сервером, с использованием записей MX в домене.

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

Однако эти отскоки очень и очень редки. Вот почему мэйлган их не обрабатывает. Причина, по которой они используют домен клиентов в адресе обратного пути, заключается в том, что они могут назначить его правильной учетной записи. Они просто так кодируют...

На самом деле, когда я настраивал свой почтовый ящик для отказов в почте приложений Google, я получил один такой отложенный отказ.

Именно это электронное письмо сделало возможной правильную отладку, которая привела к пониманию этой проблемы.

Итак, подведем итог:

Да, адрес неверный. Это не проблема для большинства возвратов, поскольку сервер не использует записи MX для их отправки, а отправляет их непосредственно на сервер, который инициировал соединение.

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

Эти электронные письма не распознаются должным образом как отказы на серверах mailgun.

person The Surrican    schedule 05.09.2013