Кратко

  • SMTP AUTH поместил обмен SASL перед почтовой транзакцией. Сервер подачи мог разрешать ретрансляцию аутентифицированной и авторизованной идентичности, а не любому узлу с подходящим сетевым адресом.
  • Успех оставался фактом одной границы: идентичность аутентификации, роль авторизации, отправитель конверта, видимый автор, содержание и последующий путь были разными утверждениями.

Старый шлюз видел соединение, а не пользователя

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

Разрешение по исходному IP плохо подходило путешествующему пользователю. Законный абонент терял доступ за пределами сети провайдера, а машина в разрешённом диапазоне не обязательно представляла человека, которому позволено пользоваться конкретным адресом отправителя. POP-before-SMTP заимствовал недавний вход из другого протокола, связывая два сеанса адресом и таймером, но не самой подачей сообщения.

Расширение аутентификации 1999 года, позднее заменённое RFC 4954, перенесло решение внутрь SMTP-сеанса. В ответе EHLO сервер объявлял AUTH и список механизмов SASL. Клиент выбирал механизм и завершал обмен до MAIL FROM. Успех не означал подпись. Он создавал более узкий факт: сервер принял аутентификацию и по локальной политике определил идентичность авторизации.

Этого хватало, чтобы открыть ретрансляцию. Этого не хватало, чтобы назвать автора текста.

SASL оставил две разные идентичности

Идентичность аутентификации принадлежит проверенным учётным данным. Идентичность авторизации — это субъект, от имени которого клиент просит действовать. Даже проверив первую, сервер должен решить, разрешено ли ей принять вторую роль.

Очередь может входить как служебная запись и подавать письма множества пользователей. Помощнику можно делегировать один ящик, но не другой. Украденные данные могут успешно пройти проверку и при этом запросить никогда не выданный объём полномочий. Поэтому имя входа не становится автоматически MAIL FROM, видимым заголовком From или человеческим автором.

Аутентификация отвечает: «кто создал этот сеанс с помощью этого механизма?» Авторизация отвечает: «что этот субъект может делать здесь?» Конверт и содержание задают следующие вопросы. Если журнал сводит всё к одному полю «пользователь», он стирает границу, которую протокол позволил наблюдать.

Подача стала отдельной службой

RFC 6409 отделил подачу новой почты от пользовательского агента к Message Submission Agent от передачи между MTA. На порту 587 MSA принимает сообщение, отклоняет или исправляет некоторые локальные ошибки и затем вводит его в транспортную сеть.

Если в сеансе нет SMTP AUTH или независимой авторизации, например защищённой подсети, MSA по умолчанию должен отклонить MAIL с требованием аутентификации. Это правило не требует, чтобы каждый интернет-релей проверял соседний MTA как конечного пользователя. Строгий допуск ставится там, где провайдер и клиент подачи непосредственно связаны.

Пользователь в поездке больше не обязан находиться в сети доступа провайдера. Он проверяет учётную запись на службе подачи и получает только назначенные ей права ретрансляции. Входящий MTA продолжает принимать почту для собственных доменов, не открывая передачу к произвольным адресатам. IANA регистрирует имя расширения AUTH и названия механизмов SASL, но не решает, может ли запись отправлять за финансовый отдел, список рассылки или домен.

Защита канала меняет доступные механизмы

Механизм аутентификации не всегда сам защищает пароль. RFC 4954 ограничивает объявление раскрывающих пароль механизмов достаточно защищёнными сеансами и допускает, что после STARTTLS новый EHLO покажет другой список. Поддержка AUTH — не постоянный флаг: состояние TLS, сертификат, механизм и реакция клиента на понижение защиты определяют безопасный выбор.

RFC 8314 позднее признал открытый текст устаревшим для подачи и доступа к почте, описав STARTTLS на порту 587 и неявный TLS на 465. Шифрование защищает обмен учётными данными и содержимое этого перехода. Оно по-прежнему не создаёт сквозной подписи авторства.

AUTH=<> сохраняет неизвестность

RFC 4954 также разрешил параметр AUTH= после MAIL FROM, чтобы передавать заявленную идентичность первоначального подателя. Если сервер не может надёжно её определить, он указывает AUTH=<>. Он не должен подменять отсутствие знания собственным именем.

Такое утверждение передаётся дальше только внутри подходящих доверительных отношений. Типы ESMTPA и ESMTPSA, зарегистрированные RFC 3848, также говорят лишь о том, что на принимающем переходе использовалась аутентификация либо аутентификация вместе с TLS. Они не удостоверяют маршрут целиком или автора.

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

Источники