Кратко

  • RFC 5383 сообщает, что гостиницы и другие сети иногда перехватывали исходящие соединения к порту 25 независимо от указанного хоста, направляя потенциально чувствительные сообщения неизвестному стороннему серверу без ведома пользователя.
  • Порт 587 выделяет Message Submission в отдельную зону ответственности. Однако нужны разные свидетельства выбранного адресата, TLS-идентичности, полномочий учётной записи, приёма в очередь, ретрансляции и доставки.

Расследование, в котором успех оказался уликой

Обычный сетевой сбой оставляет понятный след: тайм-аут, reset, отказ политики. При перехвате след выглядит лучше. Соединение открыто, баннер правдоподобен, команда проходит. Пользователь видит «отправлено», хотя фактический сервер отличается от настроенного.

В разделе 3 RFC 5383 описан исторический контекст. Почтовые клиенты использовали порт 25 для первичной отправки, провайдеры всё чаще ограничивали такой трафик, а некоторые гостиничные сети перехватывали его без учёта целевого хоста. В результате сообщение могло попасть к неизвестной третьей стороне.

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

После подмены оператор доступа выполняет уже не только перенос пакетов. Он выбирает прикладной сервис, способный увидеть адреса, содержимое и, при слабой защите, учётные данные. Если выбор не раскрыт, управление отделяется от ответственности.

Отдельный вход для отправителя

Почтовая система состоит из разных ролей. User Agent создаёт сообщение. Submission-сервис проверяет клиента, применяет правила и принимает либо отклоняет ответственность. Transfer Agents передают дальше. Система назначения помещает письмо в mailbox. Чтение происходит ещё позже.

RFC 2476 определил Message Submission как отдельный сервис; RFC 4409 его пересмотрел, а RFC 6409 стала действующим преемником. Порт 587 обозначает первичную сдачу письма пользователем, тогда как порт 25 в основном обслуживает передачу между системами. RFC 5383 требовал доступности 587 для Lemonade и рекомендовал его по умолчанию.

Такое разделение делает политику проверяемой. У submission-сервиса появляются собственные методы аутентификации, расширения, лимиты и квитанции. Firewall может разрешать именно эту функцию.

Но номер порта — лишь координационная метка. Он не удостоверяет компанию или процесс. Чужой сервер тоже может слушать 587; реестр IANA не выдаёт ему полномочия действовать от имени выбранного провайдера.

Семь записей вместо одного флага

Клиент выбирает имя. DNS возвращает адрес. TCP достигает наблюдаемого peer. TLS может защитить канал и проверить reference identity. SMTP AUTH устанавливает principal в политике ответившего сервера. Положительный ответ принимает транзакцию. Затем начинаются relay и доставка.

RFC 8314 позднее рекомендовала TLS для доступа и отправки, описала submissions на порту 465 и учла существующий STARTTLS на 587. Это развитие не превращает 587 в гарантию безопасности. Идентичность появляется только при корректной проверке имени и сертификата, а ошибка должна останавливать процесс без скрытого downgrade.

Поэтому журнал хранит отдельно ожидаемый hostname, DNS, фактический peer, порт, режим TLS, цепочку сертификатов, результат проверки, banner, capabilities, механизм аутентификации, principal, SMTP-коды, queue ID и время. Поле «connected=true» стирает именно тот факт, который нужен при подмене.

Явный запрет оставляет путь к восстановлению

Блокировка порта 25 может быть законной мерой против spam и заражённых устройств. RFC 5383 не требует отменить политику безопасности. Он показывает разницу между видимым отказом и незаявленной заменой сервиса.

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

Application firewall, понимающий лишь часть SMTP extensions, может дополнительно нарушить согласование: одна сторона видит возможность, другая — урезанную сессию. Настоящий материал не повторяет общий тезис RFC 2979 о прозрачности firewall и не пересказывает HTTP-туннель RFC 3093. Его предмет — происхождение отвечающей стороны.

Queue ID не равен доставке

Даже правильный и аутентифицированный сервер даёт ограниченную квитанцию. Ответ 2xx или queue ID способен подтвердить приём по текущей политике. Он не доказывает все дальнейшие hops, запись в mailbox, показ или прочтение.

Расследование соединяет ограниченные факты: ожидаемый endpoint, наблюдаемый peer, идентичность канала, аккаунт, envelope, контент, custody очереди, relay-попытки и ответ назначения. После перехвата queue ID может существовать только у подменившей системы. Точный номер не связывает её с исходно выбранным сервисом.

Приёмочные испытания должны идти из корпоративных, мобильных, домашних и гостевых сетей к контролируемому серверу. Они сравнивают настройку с фактическим peer и вызывают неверный сертификат, отсутствие STARTTLS, изменение capabilities, неожиданный banner и явный block. Допустимы доказанная идентичность или объяснимый отказ, но не тихое ослабление проверки ради зелёного статуса.

Источники