Обязаны ли SMTP-серверы обычно копировать ПОЧТУ ОТ из сеанса клиент-сервер?
Обязаны ли SMTP-серверы во время (STMP) обмена данными между серверами (SMTP) обычно копировать MAIL FROM из сеанса клиент-сервер? Я явно проверил, что серверы некоторых почтовых провайдеров действительно демонстрируют такое поведение, но, похоже, это не требование https://datatracker.ietf.org/doc/html/rfc5321 . Кроме того, я не знаю, насколько популярна эта практика (если она не является стандартом).
Обновление, чтобы быть более конкретным: меня в первую очередь интересует случай очень обычного сообщения электронной почты, от человека к человеку, доменов на двух разных серверах.
Серверы обязаны держать обратный путь открытым, самый простой способ сделать это — скопировать исходный адрес MAIL FROM: и повторно использовать его в исходящей SMTP-пересылке, но это не так. единственный способ удовлетворить это требование.
Обычно они это делают, но некоторые серверы предпринимают другие действия, такие как развертывание BATV, SRS или какой-либо другой формы VERP.
Таким образом, можно с уверенностью ожидать, что электронное письмо, адресованное предполагаемому отправителю, достигнет лица, ответственного за создание сообщения, но, возможно, через одного или нескольких посредников, которые восстанавливают предыдущий адрес отправителя SMTP.
RFC 5321, 3.3 сообщает, для чего MAIL FROM::
часть
первого или единственного аргумента содержит исходный почтовый ящик (между скобками "<" и ">"), который может быть используется для сообщения об ошибках (см. Раздел 4.2 для обсуждения ошибки составление отчетов).
Поля отправителя в заголовках формата интернет-сообщений (RFC 5322, 3.6.2) имеют более конкретные цели, чтобы отличить автора (От:) от агента, ответственного за фактическую передачу сообщения (Отправителя):
Например, если бы секретарь отправил сообщение другому человеку, почтовый ящик секретаря появится в поле «
Отправитель:» и почтовый ящик фактического автора появится в поле «От:».
RFC 5321 отправитель конверта имеет чисто техническое назначение. Обычно в сценариях переадресации почты и списка рассылки переписывается MAIL FROM для соответствия домену/серверу пересылки или оператору списка рассылки. Это имеет два преимущества:
- Сообщения об ошибках будут возвращаться оператору списка рассылки, который должен позаботиться об удалении ошибочных адресов из списка.
- Перезапись отправителя конверта не нарушает политику SPF исходного домена (Шевек (2004): Схема перезаписи отправителя ).
С другой стороны, такая практика несколько противоречит RFC 5321, 3.7.5:
3.7.5. Конверты в шлюзе
Аналогично, при пересылке сообщения из другой среды в Интернет, шлюз ДОЛЖЕН установить обратный путь конверта в в соответствии с адресом возврата сообщения об ошибке, если он предоставлен чужая среда. Если внешняя среда не имеет эквивалента концепции, шлюз должен выбрать и использовать наилучшее приближение с адрес отправителя сообщения в качестве крайней меры по умолчанию.
Я не вижу в этом проблемы, поскольку протокол SMTP не обновлялся (за исключением кодов ответа SMTP 521 и 556, RFC 7504) с 2008 г., но методы, включая предотвращение подделки электронной почты эволюционировали с тех пор.
MAIL FROM:, как следует из названия параметра, используется, если серверу необходимо «отправить обратно» электронное письмо, например об ошибке или других проблемах, и не требуется так же, как отправитель оригинального электронного письма.
Многие серверы проверяют это поле и используют его для спама, но требований к этому нет.