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

2. Рекомендации

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

  • 1. Должна обеспечиваться возможность ограничения несанкционированного использования почтовых трансляторов.
  • 2. Должна обеспечиваться возможность обеспечения строк "Received:" с достаточно информацией для трассировки пути доставки почты независимо от использования спамерами обманных имен хостов в командах HELO и т. п.
  • 3. Должна обеспечиваться возможность доступа к локальным системным журналам для последующей трассировки событий.
  • 4. Следует обеспечивать возможность записи в системные журналы информации о всех действиях anti-relay/anti-spam.
  • 5. Следует обеспечивать возможность отказа от приема почты для хоста или группы хостов.
  • 6a. Недопустимо отвергать "MAIL From: <>".
  • 6b. Недопустимо отвергать "MAIL From: <user@my.local.dom.ain>".
  • 7a. Следует обеспечивать возможность отвергать почту от конкретного пользователя "MAIL From:" user, <foo@domain.example>.
  • 7b. Следует обеспечивать возможность отвергать почту из домена в целом "MAIL From:" domain <.*@domain.example>.
  • 8. Следует обеспечивать возможность отвергать почту для ограничения скорости приема почты ("Контроль скорости").
  • 9. Следует обеспечивать возможность проверки домена "MAIL From:" domain (с использованием DNS или иных способов).
  • 10. Следует обеспечивать возможность проверки <local-part> для исходящей почты.
  • 11. Следует обеспечивать возможность контроля для команд SMTP VRFY и EXPN.
  • 12. Следует обеспечивать возможность контроля для команды SMTP ETRN.
  • 13. Должна обеспечиваться возможность настройки параметров для возврата разных значений Return Code по различным правилам (например, 451 Temp Fail, а не 550 Fatal Error).

Приведенное ниже обсуждение рекомендаций зачастую заканчивается необходимостью проверки соответствия для имен хостов/доменов и адресов/подсетей IP. Рекомендуется обеспечивать возможность представления данных/шаблонов для проверки соответствия извне по отношению к MTA (например, правила проверки соответствия включаются в MTA, но данные, с которыми проводится сравнение могут храниться в отдельном файле). Рекомендуется также обеспечивать возможность включения в данные для проверки соответствия (внешний файл) регулярных выражений для обеспечения максимальной гибкости.

Естественно, что при проверке соответствия имен доменов и/или хостов недопустимо принимать во внимание регистр символов. Поскольку локальная часть адреса (<local-part>) может быть регистрозависимой, для ее проверки разумно учитывать регистр символов. Однако, поскольку <sPAmMeR@domain.example> и <spammer@domain.example> скорей всего указывают на одного пользователя и поскольку в результате сравнения принимается решение об отбрасывании сообщения мы предлагаем при сравнении <local-part> также не учитывать регистр символов.

Интерпретация применения всех этих рекомендаций является достаточно гибкой — в зависимости от того, как вы реализуете фильтрацию спама сегодня, спамеры будут завтра искать обходные пути и качественные реализации MTA должны обеспечивать достаточную гибкость для предотвращения новых уловок и хитростей спамеров.

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