RFC: 2505
Оригинал: Anti-Spam Recommendations for SMTP MTAs
Категория: Лучший современный опыт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 2505, Страница 3 из 23

1.2. Рамки документа

В данном документе не содержится окончательного решения проблемы спама.

Однако при реализации предложенных здесь методов и правил (особенно правил Non-Relay) на достаточном числе MTA в сети Internet деятельность спамеров значительно усложнится. Если правовых методов предотвращения спама окажется недостаточно, спам можно блокировать техническими мерами с использованием описанных ниже правил (поскольку правила Non-Relay сейчас можно использовать открыто, можно создать различные фильтры против спама). Очевидно, что наилучшие результаты могут быть достигнуты при использовании правовых и технических мер предотвращения спама.

Такой подход существенно снизит остроту проблемы спама и позволит сообществу Internet разработать и реализовать эффективное и долговременное решение этой проблемы.

Однако следует понимать, что одних правил Non-Relay недостаточно для предотвращения спама. Даже если настанет день, когда

99% SMTP MTA будут использовать такие правила, спамеры продолжат использовать оставшийся 1%. В крайнем случае, они смогут напрямую соединяться с хостом каждого адресата — это приведет к лишь к некоторому повышению затрат на рассылку спама.

Реализация IPv6 представляется достаточно скорым событием, но бороться со спамом приходится уже сейчас, поэтому в данном документе рассматривается только IPv4.

1.3. Терминология

В данном документе использование глаголов долженствования соответствует RFC2119 [4]:

Должно (MUST) — Это слово используется для обозначения обязательных к исполнению требований. Следует (SHOULD) — Этот термин означает рекомендацию и используется в тех случаях, когда те или иные обстоятельства позволяют отказаться от выполнения указанных требований. Все случаи отказа от выполнения таких требований должны быть основаны на взвешенном решении. Возможно (MAY) — Это слово используется для обозначения необязательных требований. Одни производители могут использовать такие опции, а другие — отказываться от их реализации по собственному усмотрению.

Страница 3 из 23

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