Пример передачи электронной почты

Пример передачи электронной почты

Стандарты RFC буквально заставляют нас принимать незашифрованные соединения на порту 25. Чтобы понять почему, мы должны понять, как работает электронная почта. Но электронная почта — довольно сложная тема, и я создал этот пример вместе с таблицей, чтобы попытаться все понять.

Может кто-нибудь прочитать и сказать, ошибаюсь ли я в какой-либо части объяснения? Потому что я не совсем уверен, правильно ли я понимаю тему.


ПРИМЕР

Когда пользователь (отправитель) отправляет электронное письмо через"почтовый агент пользователя" (MUA), это электронное письмо немедленно передается"агент отправки почты"(MSA), который находится или не находится на отдельной машине. MSA предварительно обрабатывает электронную почту и передает ее"агент почтового перевода"(MTA) на той же машине. Затем MTA (отправитель) использует DNS и определяет, на какой MTA (получатель) должно быть отправлено электронное письмо. Эта часть транспортировки выполняется только через порт 25. Когда MTA (получатель) получает электронное письмо, он передает его MSA на той же машине, а затем пользователь (получатель) может прочитать электронное письмо с помощью MUA.

Связь между MUA и MSA и MSA и MTA может использовать защищенные порты, но соединение между MTA и MTA не может. Таблица ниже показывает, какие протоколы используются или могут использоваться, и какие порты могут использоваться для каждого шага приведенного выше примера. Мы также используем ✘ и ✔ там, где есть выбор, чтобы указать, что должна использовать современная установка.

# отправитель получатель протоколы, которые мы можем использовать порты соответствующих протоколов
1 МУА МСА (✘) SMTP
(✔) SMTP
(✘) 25
(✔)587
2 МСА МТА (✘) SMTP
(✔) SMTP
(✘) 25
(✔)587
3 МТА МТА (✔) SMTP (✔)25
4 МТА МСА (✔) SMTP (✔)25
5 МСА МУА (✘) POP3
(✘) POP3S
(✘) IMAP
(✔) IMAPS
(✘) 110
(✘) 995
(✘) 143
(✔)993

решение1

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

Порты не указывают на шифрование, а используются для разных целей:

  • Порт 25используется для SMTP (RFC5321)ретранслятор сообщениймежду MTA:s.
  • Порт 587используется дляотправка сообщения(RFC6409) от MUA до MSA.
  • Оба они могут быть зашифрованы с помощью STARTTLS(RFC3207).
  • Кроме того, есть SMTPS, который оборачивает SMTP (от MUA до MSA) внутри TLS на порту 465. Это было зарегистрировано в 1997 году, но отменено в 1998 году, когда STARTTLSбыло стандартизировано. Однако это было отменено 20 лет спустя в 2018 году, какRFC 8314теперь считает открытый текст устаревшим и возвращает неявный TLS для отправки по протоколам POP, IMAP и SMTP.

Большая часть электронной почты сегодня шифруется при передаче (между MTA), говоритОтчет о прозрачности Google.

Связь между MTA должна по-прежнему одобрять незашифрованные соединения для обратной совместимости, и поэтому злоумышленнику легко понизить уровень соединения, удалив ответ, 250-STARTTLSуказывающий на поддержку расширения. Однако, если отправитель поддерживаетоппортунистический ДЭН(RFC7672) и у получателя есть TLSAзапись, указывающая, что ему не нужны попытки незашифрованной доставки (как исключение из обратной совместимости), такие атаки потерпят неудачу.

Следующая иллюстрация (CC BY-SA 3.0отAle2006-из-enв ВикипедииАгент отправки сообщений) показывает различные роли сервера, а синие стрелки могут быть реализованы различными вариациями SMTP. Также обратите внимание, что один и тот же сервер может иметь несколько ролей при доставке сообщения.

Модель передачи SMTP

Чтобы улучшить вашу таблицу:

# отправитель получатель используемые протоколы и порты
1 МУА МСА (✘) отправка 587с STARTTLS
(✔) SMTPS 465с неявным TLS
2 МСА МТА Внутренняя доставка (один и тот же сервер с двумя ролями)
3... МТА МТА (возможноМХ) (✘✘) незашифрованный SMTP 25
(✘) SMTP 25с STARTTLS
(✔) SMTP 25, STARTTLSпринудительно с DANE
Н-1 МХ МДА➔МС Внутренняя доставка (один и тот же сервер с несколькими ролями)
Н РС МУА (✘) IMAP 143с STARTTLS
(✔) IMAPS 993с неявным TLS

Последние два шага нельзя рассматривать как отправителя и получателя, так какСообщение Пользовательский АгентMUA подключается кМагазин сообщенийMS и вытягивает сообщение вместо push. Окончательный MX MTA доставляет почту в MS с помощью функциональности, называемойАгент доставки сообщений(MDA).Агент отправки сообщений(MSA) относится только к отправке почты. Более подробную информацию об этих определениях можно найти наАрхитектура интернет-почты RFC5598.

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