Подмена отправителя в SMTP — это уязвимость по дизайну, заложенная в архитектуру протокола SMTP ещё в 1980-е годы. Ниже я подробно объясню, почему это считается уязвимостью, хотя формально оно соответствует стандарту (и я даже укажу сами стандарты).
Почему возможность подмены отправителя — это плохо
1. SMTP спроектирован в эпоху доверия
SMTP был создан в 1982 году (см. RFC 821, позже обновлён в RFC 5321), когда:
- Интернет был закрытым, между академическими учреждениями.
- Все узлы считались «доверенными».
- Авторизация и аутентификация попросту не были нужны.
Результат: в протоколе SMTP нет встроенной аутентификации отправителя — любой клиент может указать любой адрес в MAIL FROM и заголовке From:.
2. Никакой проверки адреса отправителя
Когда клиент говорит:
MAIL FROM:<boss@mlhost.ru>
SMTP-сервер, если не настроены дополнительные фильтры, не обязан проверять, действительно ли клиент имеет право отправлять почту от имени mlhost.ru.
Это всё легально по RFC 5321. Сервер может принять такие данные и просто отправить письмо дальше.
3. Подделка заголовков и содержимого
Внутри письма можно написать:
From: Director <director@ooosysadmin.ru>
Reply-To: hacker@mlhost.ru
И пользователь в почтовом клиенте увидит именно это — он не знает, что письмо пришло от какого-нибудь 123.123.123.123, не относящегося к отправителю.
Пользователь верит тому, что видит.
Это позволяет:
- Вводить людей в заблуждение.
- Проводить фишинг.
- Распространять вредоносный софт.
4. SMTP не требует авторизации
С точки зрения RFC:
- SMTP AUTH — необязательное расширение (RFC 4954).
- Многие сервера принимают почту от внешних источников без аутентификации, чтобы работать как relay (если настроены неправильно).
Это позволяет использовать открытые SMTP-серверы как площадки для рассылки поддельных писем.
5. Влияние на безопасность
Подмена отправителя:
- Подрывает доверие к электронной почте как каналу связи.
- Является основным вектором атак (фишинг, CEO fraud, malware).
- Усложняет расследования (невозможно определить реального отправителя без анализа логов/заголовков).
Статистика (по различным источникам за последние годы):
- 90% успешных атак на корпоративные сети начинается с фишингового письма.
- 70% из них используют подмену From:.
Почему это именно уязвимость, а не «особенность»
- Позволяет выдать себя за другого
- Нет верификации MAIL FROM или From:
- Массово используется в фишинге
- Вводит пользователя в заблуждение
Поэтому подмена считается уязвимостью дизайна (design flaw). В современных системах такие уязвимости закрываются поверх SMTP с помощью SPF, DKIM и DMARC — костыли над дырявой архитектурой.
Возможность подмены отправителя в SMTP — это не баг реализации, а баг самой идеи: SMTP доверяет отправителю, не требуя доказательств, что он является тем, за кого себя выдаёт. Это делает подмену тривиальной и массово используемой в атаках.
Ниже разберу по пунктам, какие RFC позволяют так делать:
Основные RFC, описывающие структуру и поведение email:
📬 SMTP-протокол
- RFC 5321 – Simple Mail Transfer Protocol
Описывает команду MAIL FROM:<address> и RCPT TO:<address> — это envelope-отправитель и получатель.
Никакой проверки подлинности MAIL FROM: сервер не обязан выполнять — любой клиент может указать любой адрес.
Это и создаёт возможность для подмены.
✉️ Формат email-сообщения
- RFC 5322 – Internet Message Format
Описывает заголовки сообщений: From:, Reply-To:, Sender:, To:, и т.д.
Эти заголовки — часть содержимого письма, и также могут быть любыми, если нет дополнительных проверок.
Возможна ситуация, когда MAIL FROM: (SMTP envelope) ≠ From: (заголовок письма), и это нормально по стандарту.
🛡️ RFC по защите от подмены отправителя:
Поскольку сама возможность подмены заложена в архитектуру, позже были разработаны механизмы проверки подлинности:
✅ SPF (Sender Policy Framework)
- RFC 7208
Проверяет, имеет ли IP-адрес отправителя право отправлять письма от имени указанного домена (MAIL FROM:).
Используется для борьбы с подменой на уровне SMTP envelope.
🔒 DKIM (DomainKeys Identified Mail)
- RFC 6376
Позволяет отправителю подписывать определённые заголовки (включая From:) криптографически.
При получении можно проверить, что содержимое не было подменено.
🛡️ DMARC (Domain-based Message Authentication, Reporting, and Conformance)
- RFC 7489
Объединяет SPF и DKIM.
Заставляет получателя проверять соответствие между From: и авторизованными записями SPF/DKIM.
Может указывать: пропустить, пометить, или отклонить письмо при несоответствии.