Установите заголовки писем, чтобы возвращенные письма отправлялись на определенный адрес

Из нашего приложения rails мы отправляем сгенерированные системой электронные письма с адресом отправителя, установленным на [email protected]. В случае отказа они будут отправлены на этот адрес нашим почтовым сервером. Однако я бы хотел, чтобы отклоненные электронные письма не отправлялись обратно на [email protected], а на другой адрес, например [email protected].

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

ура, макс


person Max Williams    schedule 14.03.2011    source источник
comment
(+1) хороший вопрос. Как прошло ?   -  person Scherbius.com    schedule 01.04.2011
comment
en.wikipedia.org/wiki/Variable_envelope_return_path обычно используется с разными адресами отправителя и конверта. ..   -  person Gert van den Berg    schedule 20.01.2017


Ответы (5)


Я только что понял это сам в exim4 после большого чтения о конфигурации exim.

Во-первых, вы хотите, чтобы ваше приложение добавило следующий заголовок:

Return-Path: <[email protected]>

Работает с скобами или без них. Exim в любом случае добавит скобки в конце.

Во-вторых, это было самое сложное. Exim всегда хотел заменить мой Return-Path: адрес пользователем unix, который его послал. Вы можете использовать / etc / email-addresses в Ubuntu, чтобы установить статический адрес электронной почты для пользователя вашего веб-приложения, но это по-прежнему игнорирует заголовок Return-Path. Вот как я изменил свою конфигурацию exim, чтобы уважать Return-Path из веб-приложения:

В основной области конфигурации добавьте:

return_path_remove = false

В соответствующей конфигурации маршрутизатора (например, dnslookup):

dnslookup:
  # ...
  errors_to = ${if def:h_return-path: {${address:$h_return-path:}} fail}
  headers_remove = return-path
  no_more

Теперь exim должен скопировать адрес заголовка Return-Path на уровне конверта и удалить исходный заголовок Return-Path.

Я пробовал множество других конфигурационных директив, и это единственный способ, который у меня действительно сработал.

person ColinM    schedule 12.08.2011
comment
Это не должно работать. Не потому, что вы не выяснили, как установить Return-Path в Exim, а потому, что он будет отменен SMTP-сервером доставки. Из RFC 5321, раздел 4.4: Когда SMTP-сервер доставки выполняет окончательную доставку сообщения, он вставляет строку обратного пути в начало почтовых данных. Это использование обратного пути обязательно; почтовые системы ДОЛЖНЫ его поддерживать. Строка обратного пути сохраняет информацию в ‹reverse-path› из команды MAIL. - person james.garriss; 21.02.2013

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

Если вы пишете электронные письма, подключаясь напрямую к SMTP-серверу, это просто - команда MAIL содержит путь возврата. Если вы отправите

MAIL FROM:<[email protected]>

к серверу SMTP, то отказы будут возвращены на [email protected].

Если вы не создаете SMTP и используете MTA (например, exim / etc), вам необходимо найти переключатель командной строки для вашего MTA. Для sendmail -f [email protected] "устанавливает адрес отправителя", и это заканчивается как Return-Path в окончательной доставленной почте, а [email protected] будет получать отказы (я делаю именно это для автоматически сгенерированных писем). Я не пробовал это на exim, но у него точно такой же вариант, и он должен работать.

person EML    schedule 03.11.2014
comment
спасибо за этот EML. Могу ли я с помощью этого метода настроить адрес возврата failed, отличный от адреса from? - person Max Williams; 04.11.2014
comment
@MW: да, без проблем - это разные вещи. Просто установите From: в своих заголовках так, как вы хотите, чтобы получатель его видел, и установите адрес -f (т. Е. Адрес «конверта» и т. Д.), Как требуется для отказов. Одно предостережение: MTA может заподозрить нарушение безопасности и вставить дополнительный заголовок в полученное электронное письмо (X-Authentication-Warning), чтобы предупредить получателя. Это зависит от вашей точной настройки MTA. В книге sendmail есть целая страница, как этого избежать. Если ваши получатели видят этот заголовок, и вы хотите от него избавиться, вам, вероятно, следует задать другой вопрос. - person EML; 04.11.2014
comment
Обратный путь носит исключительно информационный характер. когда это сообщение получено, оно сообщает получателю, куда мог бы пойти отскок. на самом деле он ничего не делает. как вы говорите -f после /usr/lib/sendmail для отправки отправителю правильный ответ. некоторые реализации /usr/lib/sendmail могут интерпретировать заголовок «обратный путь» как эквивалентный. - person Jasen; 08.08.2016

Заголовок Return-Path записывается принимающим сервером, а не отправляющим сервером. И согласно RFC 5321 он совпадает с адресом поставляется в команде MAIL FROM.

Даже если вы сами установите заголовок Return-Path, принимающий сервер его перезапишет.

Дело в том, что адрес в команде MAIL FROM и адрес в заголовке From могут быть разными. Принимающий пользователь не видит MAIL FROM адрес. Они видят только адрес заголовка From.

Итак, если вы хотите игнорировать отказы или хотите, чтобы они перешли на определенный адрес, вы должны использовать этот адрес в команде MAIL FROM.

Но в заголовке From вы можете просто использовать [email protected] - пользователь увидит этот адрес.


Чтобы еще немного упростить, вы отправляете электронное письмо с [email protected] адреса. Принимающий сервер отправит на этот адрес сообщения о недоставке.

Чтобы показать пользователю адрес [email protected] вместо адреса handle_bounce..., установите в заголовке From в необработанном сообщении электронной почты MIME адрес noreply....


Недавно я получил письмо без ответа от Bitbucket. Вот исходное сообщение:

Return-Path: <bounce-1231860_HTML-1209402755-103116181-132689-225@bounce.mailer.atlassian.com>
From: "Atlassian Bitbucket" <[email protected]>
To: <[email protected]>
Subject: Continuous delivery, without the headache.
Date: Wed, 28 Feb 2018 12:40:53 -0600
MIME-Version: 1.0
Reply-To: "Atlassian Bitbucket" <reply-fe3915707665057b741c71-1231860_HTML-1209402755-132689-225@mailer.atlassian.com>

... message body ...

Как видите, Return-Path - это адрес, предназначенный для обработки отказов. Но From адрес - это noreply@... почта. Это означает, что это электронное письмо было действительно отправлено с этого адреса для обработки отказов, а не с адреса noreply.

Вы также можете увидеть заголовок Reply-To, который предназначен для обработки ответов, если пользователь отвечает на электронные письма без ответа. Эти ответы, вероятно, сразу будут отброшены.

person xyres    schedule 02.03.2018
comment
В пакете org.apache.commons.mail.Email есть функция setBounceAddress (). Я тестировал эту функцию, и она не работает; доказательство того, что ваше утверждение верно. Итак, что эта функция должна делать, если мы не можем установить на отправляющем сервере? - person Coisox; 01.05.2020
comment
@Coisox Извините, у меня нет опыта использования Apache Commons Mail. - person xyres; 01.05.2020
comment
Вы определенно можете установить заголовок Return-Path в качестве отправителя. Но да, некоторые получатели могут его переписать (но не всегда), или, в зависимости от того, через кого вы отправляете, он может быть переписан ими. Например, при использовании MailGun для массовой рассылки электронных писем вы должны делать все правильно, чтобы установить Return-Path, который будет сохранен. Я знаю, что это противоречит цитируемому вами RFC, но на практике это правда. - person steev; 11.07.2020
comment
Приемный сервер @steev будет перезаписать путь возврата (те, которые не являются результатом неполной реализации RFC, и я не удивлюсь, если это изменится в будущем без предварительного уведомления). Если он работает с mailgun, я предполагаю, что они в фоновом режиме используют значение обратного пути для команды mail-from, о чем я упоминал в ответе. Извините, на практике это не так. Что это такое, ненадежно. - person xyres; 11.07.2020
comment
@xyres и на деле верно, и, да, ненадежно. YMMV. :) В конце концов, лучше всего было бы установить Mail-from, Return-path и Reply-to и надеяться, что один из них будет работать. Так уж обстоят дела, есть несоответствующие ESP. Вы можете жаловаться и относиться к RFC пуристом или можете адаптироваться к реальности. - person steev; 20.07.2020
comment
@steev Настройка Return-Path может работать, а может и не работать, но MAIL FROM всегда работает. И об этом я сказал в ответе. Вы спорите просто ради спора. Кстати, Mailgun - это служба отправки. Вы не можете делать все правильно, чтобы сохранить заголовок Return-Path, потому что, как вы признали, принимающие MTA могут или не могут перезаписывать его. - person xyres; 11.12.2020

Ошибка Errors-To устарела, поэтому почтовые серверы обычно игнорируют этот заголовок - большинство серверов возвращают завещание «отправителю конверта».

Это адрес электронной почты, который ваш почтовый клиент отправляет как часть подключения к сервер SMTP (не обязательно адрес «От», хотя обычно это тот же самый).

Я не очень хорошо знаю Rails, но нашел this - хотя, насколько я могу судить, Return-Path сбрасывается MTA, чтобы соответствовать информации MAIL FROM от клиента, поэтому кажется, что вы не можете его установить.

Я думаю, единственное, что вы можете сделать, это установить адрес возврата на своем сервере.

person HorusKol    schedule 27.04.2011
comment
Спасибо, Хорускол - действительно ли почтовые провайдеры учтут этот адрес возврата? Я подумал, что они обычно все игнорируют и всегда отправляют отказы на адрес отправителя. - person Max Williams; 28.04.2011
comment
@MaxWilliams - да, ты, наверное, сейчас я думаю об этом больше - person HorusKol; 28.04.2011

Вот решение:

В заголовке письма вы можете указать:

From: "From Name" <[email protected]>
Reply-To: [email protected]

Errors-To: <[email protected]>
Return-Path: <[email protected]>
person Scherbius.com    schedule 29.03.2011
comment
Ах, я раньше не видел заголовок Errors-To. Я уже пробовал Reply-To и Return-Path, но безрезультатно. Я попробую ... - person Max Williams; 30.03.2011
comment
Это тоже не сработало, Дмитрий (извините за медленный ответ) - я вижу заголовок Errors-To в исходном письме, но он все равно возвращается на адрес отправителя. - person Max Williams; 04.04.2011
comment
это означает, что вы делаете что-то не так. Пожалуйста, проверьте заголовки исходящих писем. Return-Path, Errors-To: а также envelope-from и X-Env-Sender: должны иметь один и тот же адрес электронной почты (на который вы хотите перенаправлять возвращенные электронные письма). Последние 2 элемента автоматически добавляются сервером. Имеет значение чувствительность к регистру (строки в заголовке должны быть точно такими же, как в моем примере кода). С наилучшими пожеланиями. - person Scherbius.com; 04.04.2011
comment
Что xe делает неправильно, так это следуя вашему ошибочному совету установить заголовок Errors-To:. Это нестандартный заголовок, используемый для почты UUCP, который устарел и не имеет никаких функций вне UUCP. Только три программы Интернет-МТС из множества используемых в мире когда-либо распознавали это. Во-первых, его функциональность была отключена в стандартной комплектации с версии V8.8, выпущенной в середине 1990-х годов. Во втором случае функциональность была полностью удалена семь лет назад. В-третьих, он никогда не использовался в той части МТС, которая отбрасывает сообщения. - person JdeBP; 24.06.2011
comment
to JdeBP: Я не уверен, что вы вообще понимаете, о чем говорите. Просто скопируйте какую-нибудь статью. Мой ответ основан на практическом опыте. Мой работодатель использует этот способ маршрутизации отказов последние 2 года. Незаслуженный отрицательный голос. - person Scherbius.com; 29.11.2011
comment
Errors-To является нестандартным, и системам не рекомендуется его использовать. Тем не менее, есть некоторые, кто все еще это делает. Но поскольку его поддерживает очень мало систем, его нельзя считать надежным за пределами вашей организации. Это не лучший выбор. - person james.garriss; 21.02.2013