Есть ли заголовок "без ответа"?

Question

Я часто вижу автоматические электронные письма с постфиксом:

Amazon:

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

Twitter:

Пожалуйста, не отвечайте на это сообщение; оно было отправлено с неконтролируемого адреса электронной почты. Это сообщение является служебной электронной почтой, связанной с вашим использованием Twitter.

Google Checkout:

Нужна помощь? Посетите справочный центр Google Checkout. Пожалуйста, не отвечайте на это сообщение.

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

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

Answer 1

Есть ли такой заголовок?

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

Если нет, обсуждалось ли это когда-либо группами, которые контролируют форматы электронной почты?

Наверное. У людей было много времени, чтобы предлагать всевозможные вещи с помощью электронной почты, но я чувствую, что это никогда не будет реализовано; ну... нет, если нет принципиального сдвига в представлениях о том, для чего предназначена электронная почта. Я уверен, что Google был бы намного счастливее, если бы у вас даже не было кнопки "Ответить", когда они писали вам по электронной почте, поэтому, если кто-то настаивает на этом, это будут люди, которые уже отправляют donotreply@...

Электронная почта предназначена для отправки с реальных почтовых ящиков. RFC 2822 и RFC 5322 говорят:

Во всех случаях поле "От:" НЕ ДОЛЖНО содержать почтовый ящик, который не принадлежит автору (ям) сообщения.

Для меня это четкое указание на то, что электронная почта предназначена для разговора, а не для трансляции.

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

Поля отправителя также предоставляют информацию, необходимую при ответе на сообщение. Когда присутствует поле "Reply-To:", оно указывает адрес (а), на который автор сообщения предлагает отправлять ответы. При отсутствии поля "Reply-To:" ответы ДОЛЖНЫ по умолчанию отправляться на почтовые ящики, указанные в поле "From:", если автором ответа не указано иное.

Answer 2

RFC 6854 обновляет RFC 5322, чтобы разрешить использование конструкции группы вFromполе также (среди прочего). Группа может быть пустой, и это, вероятно, единственный способ, которым вы когда-либо видели используемый синтаксис группы:undisclosed-recipients:;.

В разделе 1 RFC явным образом перечисляется "отсутствие ответа" среди мотивов для разрешения групповой конструкции вFrom поле:

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

Это дает следующий пример: From: Automated System:;

Однако в конце того же раздела RFC также говорит:

Этот документ не рекомендует в настоящее время использовать групповой синтаксис в этих полях.

В разделе 3 RFC уточняется, что синтаксис группы вFromполе предназначено только для ограниченного использования.

Лично я считаю, что этот метод не следует использовать - если мы не уверены, что все соответствующие клиенты отображают исходный домен каким-либо другим способом (восстановленным из Return-Pathили новый заголовок). В противном случае это сводит на нет все попытки аутентификации домена (SPF, DKIM и DMARC). Мне кажется, что введение дополнительного поля заголовка, которое заставляет клиентов просто скрывать кнопку ответа, является гораздо лучшим подходом.

RFC комментирует этот аспект в разделе 5:

Некоторые протоколы пытаются проверить адрес отправителя путем сопоставления адреса "От:" с конкретным проверенным доменом (об одном из таких протоколов см. В документе Author Domain Signing Practices (ADSP) [RFC5617]). Такие протоколы не будут применяться к сообщениям, в которых отсутствует реальный адрес электронной почты (настоящий или поддельный) в поле "От:". Локальная политика будет определять, как обрабатываются такие сообщения, поэтому отправители должны знать, что использование групп в поле "От:" может отрицательно повлиять на возможность доставки сообщения.

Какая неудачная возможность...

Answer 3

Нет, нет no-reply заголовок.

Тем не менее, вы можете добавить пустой reply-to заголовок:

reply-to: <>

Действует в соответствии с RFC 5322, раздел 3.6.2. К сожалению, RFC никогда не указывает, что такое пустой reply-to поле означает. Я думаю, что большинство почтовых клиентов просто игнорируют это.

Answer 4

Кажется, что Thunderbird показывает встроенное предупреждающее сообщение, если Fromадрес. формы . (Сообщение, с которым я это заметил, также имело Toс и мой адрес электронной почты в Ccтолько поле. Я не проверял, важно ли это.)

Насколько я знаю, форма [e-mail]не был определен ни в одном RFC.

Обновление: похоже, что это поведение было реализовано в этой ошибке: https://bugzilla.mozilla.org/show_bug.cgi?id=1342809 , и фактическая реализация представляет собой регулярное выражение.

      /^(.*[._-])?(do[._-]?not|no)[._-]?reply([._-].*)?@/

Если это соответствует, отображается запрос подтверждения:

Ответ не поддерживается

Адрес для ответа ({ $email }) не является отслеживаемым адресом. Сообщения на этот адрес, скорее всего, никто не прочитает.

[Все равно ответить] [Отмена]

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

      [e-mail]
[e-mail]
[e-mail]
[e-mail]

К сожалению, не совпадает

      [e-mail]

поэтому вы должны использовать что-то вроде

      [e-mail]

если вы хотите закодировать дополнительную информацию в части тега.