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

6.2. Нежелательная и незапрошенная почта, почтовые атаки

Практичность и предсказуемость почтовой системы Internet требует, чтобы сообщения, которые могут быть доставлены, доставлялись на практике независимо от синтаксических ошибок и других отказов, связанных с сообщениями, а также независимо от содержимого почты. Если почта не может быть доставлена и не может быть отвергнута сервером SMTP в транзакции SMTP, эта почта должна быть возвращена (bounced) с уведомлением о невозможности доставки, как описано выше. В современном мире, когда многие операторы серверов SMTP убедились в том, что количество нежелательной почты большого размера во много раз превышает объем желаемой почты и когда восприятие сообщения может вызвать дополнительный нежелательный трафик, связанный с верификацией адреса, приведенный выше принцип утрачивает практический смысл.

Как сказано в параграфах 7.8 и 7.9, отбрасывание почты без уведомления отправителя на практике стало разрешенным. Однако такое поведение весьма опасно и нарушает сложившиеся за многие годы традиции, а также не соответствует предположениям пользователей о том, что почта доставляется или приходит уведомление о невозможности доставки. Неразумное отбрасывание электронной почты без уведомления отправителей может свести на нет эффективность почтовой системы Internet. Поэтому отбрасывание почтовых сообщений без уведомления следует использовать только в тех случаях, когда есть веские основания считать сообщения мошенническими или неприемлемыми по иным причинам.

Рациональным путем усиления принципа обеспечения доставки, если таковая возможна, является отказ от доставки сообщений, имеющих некорректный адрес возврата. Однако опыт показывает, что пользователей больше устраивает вариант, когда доставляются все сообщения, доставка которых возможна. Надежное определение некорректности адреса возврата может оказаться затруднительным и достаточно долгим процессом, особенно в тех случаях, когда предполагаемая почтовая система не доступна напрямую или не поддерживает полностью функциональность VRFY. Даже при выборе политики отбрасывания почты с некорректными обратными адресами, такую политику следует применять лишь в тех случаях, когда практически не остается сомнений в некорректности обратного адреса.

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

6.3. Детектирование петель

Простой подсчет числа заголовков Received: в принятых сообщениях обеспечивает эффективный, но обычно неоптимальный способ обнаружения петель в почтовой системе. Серверам SMTP, использующим такой способ, следует устанавливать высокий порог отказа (обычно, не менее 100 записей Received). Независимо от используемого механизма сервер должен обеспечивать средства детектирования и предотвращения тривиальных петель.

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