RFC: 5321
Оригинал: Simple Mail Transfer Protocol
Предыдущие версии: RFC 772, RFC 780, RFC 788, RFC 821, RFC 974, RFC 1425, RFC 1651, RFC 1869, RFC 2821
Категория: Проект стандарта
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 5321, Страница 64 из 75

7. Вопросы безопасности

7.1. Безопасность почты и обманки

Природа почты SMTP не обеспечивает безопасности, поскольку любой пользователь может напрямую взаимодействовать с принимающим или транслирующим сервером SMTP, создавать сообщения и обманывать простодушных получателей, полагающих, что это почта от кого-то другого. Создание таких сообщений, обманный характер которых не обнаруживается, — задача более сложная, но вполне посильная для людей с нужными знаниями и соответствующей мотивацией. Следовательно, по мере повышения уровня знаний в сфере почты Internet человек начинает понимать, что почта SMTP не может быть заверена на транспортном уровне, равно как не обеспечивается и проверка целостности почты. Реальная безопасность почты обеспечивается только сквозными методами, включающими контроля тела сообщения, использования цифровых подписей (см. RFC 1847 [43] и, например, PGP в RFC 4880 [44] или S/MIME в RFC 3851 [45]).

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

Попытки затруднить пользователям подстановку в поле обратного пути в конверте и заголовке From корректного чужого адрес взамен адреса реального отправителя заведомо ошибочны — это затрудняет работу легитимных приложений, в которых почта передается одним пользователем по просьбе другого или отклики на ошибки (доставку) должны передаваться по специальному адресу (системы, которые обеспечивают пользователю удобные способы замены этих полей для каждого сообщения отдельно, должны будут пытаться создать основные и постоянные адреса почтовых ящиков для пользователей в соответствии с полями Sender в генерируемых сообщениях).

Эта спецификация не рассматривает вопросы аутентификации, связанные в протоколом SMTP, но полезная функциональность не может ущемляться в надежде на несущественную защиту против фальсифицированной почты.

Страница 64 из 75

2007 - 2022 © Русские переводы RFC, IETF, ISOC.