Рейтинг:0

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

флаг br

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

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

Rowan Hawkins avatar
флаг us
Было бы хорошо, поскольку хотя бы один из ответов, кажется, отвечает на ваш вопрос, чтобы вы отметили это как ответ, и он может стать ссылкой для других.
Tom Johnson avatar
флаг br
Есть два ответа, которые (почти) прямо отвечают на мой вопрос, оба одинаково хороши (IMO), можно ли выбрать один из них случайным образом и пометить его как принятый?
Рейтинг:1
флаг jp

The RFC 5321, 3.3 tells what the MAIL FROM:<reverse-path> is for:

The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see Section 4.2 for a discussion of error reporting).

The originator fields in the Internet Message Format headers (RFC 5322, 3.6.2) have more specific purposes to distinguish the author (From:) from the agent responsible for the actual transmission of the message (Sender):

For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field.

The RFC 5321 envelope sender has merely a technical purpose. It is typical in mail forwarding and mailing list scenarios to rewrite the MAIL FROM to match the forwarding domain/server or the mailing list operator. This has two benefits:

  • The error reports will get back to the mailing list operator who should take care of removing erroneous addresses from the list.
  • Rewriting the envelope sender does not break the SPF policy of the original domain (Shevek (2004): The Sender Rewriting Scheme).

On the other hand, such practices are slightly against RFC 5321, 3.7.5:

3.7.5. Envelopes in Gatewaying

Similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path in accordance with an error message return address, if supplied by the foreign environment. If the foreign environment has no equivalent concept, the gateway must select and use a best approximation, with the message originator's address as the default of last resort.

I do not see this as a problem, because the SMTP protocol has not been updated (except for the SMTP 521 and 556 Reply Codes, RFC 7504) since 2008, but the practices including email forgery prevention have evolved since.

Tom Johnson avatar
флаг br
Я знаю об этом, но спасибо за информацию. Но мой вопрос немного другой - SMTP-клиент выдает свою "ПОЧТУ ОТ:..." во время связи MUA-MTA. Серверы обычно копируют это сообщение "MAIL FROM: ..." во время связи между MTA и MTA для этого сообщения? Из того, что я понял до сих пор, исходящий SMTP-сервер в основном свободен (согласно RFC5321) для построения «MAIL FROM: ..." по-своему, его можно взять из «From:», «Sender:» , "MAIL FROM: ..." или даже установить какое-то совершенно нестандартное значение (хотя обычно это не имело бы особого смысла при передаче обычного сообщения).
Tom Johnson avatar
флаг br
Но, возможно, SMTP-серверы ведут себя каким-то особым образом, будучи просто стандартом де-факто, а не официальным стандартом?
Tom Johnson avatar
флаг br
Что ж, на самом деле ваш ответ ответил на мой первоначальный вопрос о случаях пересылки почты и списков рассылки. Но на самом деле меня больше интересует, как это выглядит в случае обычного сообщения, я немного обновил исходное сообщение, чтобы отразить это.
флаг jp
В простом сценарии почта идет напрямую с почтового сервера отправителя на почтовый сервер получателя, и, следовательно, нет места для перезаписи перед сервером следующего перехода. Если принимающая инфраструктура более сложна, она может делать все, что подходит для ее собственных целей. Стандарт никак это не ограничивает.
Tom Johnson avatar
флаг br
Спасибо. Хотя прямая связь между SMTP-сервером и SMTP-сервером встречается редко, обычно перед всем стоит MTA. Хорошо, поэтому я думаю, что можно разумно принять, что когда обычная почта передается и проходит через обычный исходящий SMTP-сервер на обычный входящий SMTP-сервер, можно ожидать, что «Путь возврата» будет взят либо из исходного " ПОЧТА ОТ:», или из заголовка «Отправитель:», или из заголовка «От:», хотя заранее нельзя сказать, какой из этих заголовков использует данный SMTP-сервер, и даже нет никакой гарантии, что какой-либо.
Tom Johnson avatar
флаг br
"впереди всего сидит MTA" - я имел в виду MUA.
флаг jp
Я добавил ссылку на главу в RFC 5321, в которой рекомендуется не изменять отправителя конверта, но поясняется, почему это устарело, хотя это и есть в текущей спецификации протокола.
Tom Johnson avatar
флаг br
Еще немного прочитав RFC 5321, я не уверен, что вы совершенно правы, говоря, что «такая практика немного противоречит RFC 5321, 3.7.5», потому что процитированный вами фрагмент касается почтовых шлюзов, и кажется, что шлюзы и взрыватели списков рассылки обычно считаются двумя разными вещами. Цитирую из того же RFC: «Когда сообщение доставляется или направляется на каждый адрес формы расширенного списка, обратный адрес в конверте («ПОЧТА ОТ:») ДОЛЖЕН быть изменен на адрес физического или иного лица, которое ведет список».
Рейтинг:1
флаг us

Сервера обязаны держать обратный путь открытым, проще всего это сделать скопировать оригинал ПОЧТА ОТ: адрес и повторно использовать его в исходящей передаче SMTP, но это не единственный способ удовлетворить это требование.

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

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

Tom Johnson avatar
флаг br
Спасибо за ваш ответ. «Сервера обязаны держать обратный путь открытым» — это, конечно, имеет смысл, но формальное требование или просто практика? Если это формально, не могли бы вы дать ссылку на спецификацию, говорящую об этом?
флаг us
В SMTP (RFC5321) обсуждается путь повторного обращения и его важность для бесперебойной работы системы электронной почты. моя претензия в основном вытекает из этого.
Рейтинг:0
флаг in

ПОЧТА ОТ: <обратный-путь> как намекает имя параметра, это используется, если серверу необходимо «отправить обратно» электронное письмо, например, об ошибке или других проблемах, и не обязательно, чтобы оно было таким же, как отправитель исходного электронного письма.

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

Tom Johnson avatar
флаг br
Спасибо за ответ, хотя я знаю это, я обновил свой первоначальный вопрос, чтобы лучше отразить то, что я хотел знать. См. также мой комментарий под ответом Эсы Йокинена.
флаг in
Ответ очень большой, они не должны, по крайней мере, не более чем выносить это в шапку или хранить в памяти для передачи на «следующий сервер». Серверы НИКОГДА не переписывают фактическую часть RFC822, если они сделают DKIM, и друзья сломаются.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.