☰

Обязаны ли SMTP-серверы копировать MAIL FROM из сеанса клиент-сервер?

tag-icon • tag-icon email smtp
Обязаны ли SMTP-серверы копировать MAIL FROM из сеанса клиент-сервер?

Обязаны ли SMTP-серверы во время (STMP) связи сервер-сервер (SMTP) копировать MAIL FROM из сеанса клиент-сервер? Я специально проверил, что серверы некоторых почтовых провайдеров действительно демонстрируют такое поведение, но, похоже, это не является обязательным требованиемhttps://datatracker.ietf.org/doc/html/rfc5321. Кроме того, я не знаю, насколько популярна эта практика (если она не является стандартом).

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

решение1

Серверы обязаны держать обратный путь открытым, самый простой способ сделать это — скопировать исходный MAIL FROM:адрес и повторно использовать его в исходящей SMTP-передаче, но это не единственный способ выполнить это требование.

Обычно они это делают, но некоторые серверы предпринимают другие действия, такие как развертываниеБАТВ,СРСили какая-то другая формаВЕРП.

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

решение2

TheRFC 5321, 3.3рассказывает MAIL FROM:<reverse-path>, для чего предназначено:

Часть <reverse-path>первого или единственного аргумента содержит исходный почтовый ящик (между скобками " <" и " >"), который можно использовать для сообщения об ошибках (см.Раздел 4.2для обсуждения сообщений об ошибках).

Theполя оригинаторав заголовках формата интернет-сообщений (RFC 5322, 3.6.2) имеют более конкретные цели, чтобы отличить автора ( From:) отагент, ответственный за фактическую передачу сообщения( Sender):

Например, если секретарь должен отправить сообщение для другого человека, почтовый ящик секретаря появится в Sender:поле « », а почтовый ящик фактического автора появится в From:поле « ».

RFC 5321отправитель конвертаимеет только техническое назначение. Это типично дляпересылка почтыисписок рассылкисценарии для переписывания MAIL FROMдля соответствия домену/серверу пересылки или оператору списка рассылки. Это имеет два преимущества:

  • Отчеты об ошибках будут возвращены оператору списка рассылки, который должен будет удалить ошибочные адреса из списка.
  • Переписывание отправителя конверта не нарушает политику SPF исходного домена (Шевек (2004):Схема перезаписи отправителя).

С другой стороны, такая практика немного противоречитRFC 5321, 3.7.5:

3.7.5 Конверты в шлюзовании

Аналогично, при пересылке сообщения из другой среды в Интернет шлюз ДОЛЖЕН установить путь возврата конверта в соответствии с адресом возврата сообщения об ошибке, если он предоставлен внешней средой. Если внешняя среда не имеет эквивалентной концепции, шлюз должен выбрать и использовать наилучшее приближение, с адресом отправителя сообщения в качестве последнего варианта по умолчанию.

Я не вижу в этом проблемы, поскольку протокол SMTP не был обновлен (за исключением кодов ответа SMTP 521 и 556,RFC7504) с 2008 года, но с тех пор методы, включая предотвращение подделки электронных писем, претерпели изменения.

решение3

MAIL FROM:<reverse-path>Как следует из названия параметра, он используется, если серверу необходимо «отправить обратно» электронное письмо, например, при возникновении ошибки или других проблем, и не обязательно, чтобы отправитель совпадал с отправителем исходного электронного письма.

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

Связанный контент