2. Рекомендации
Сначала мы приведем краткий список рекомендаций, а потом более детально рассмотрим каждую из них. Будут также даны рекомендации по тому, что не следует делать — что-то может казаться совершенно естественным с точки зрения борьбы со спамом (и может даже помочь в ней), но может приводить к вредным последствиям для почтовой системы и отрицательный эффект может оказаться больше положительного.
- 1. Должна обеспечиваться возможность ограничения несанкционированного использования почтовых трансляторов.
- 2. Должна обеспечиваться возможность обеспечения строк "Received:" с достаточно информацией для трассировки пути доставки почты независимо от использования спамерами обманных имен хостов в командах HELO и т.п.
- 3. Должна обеспечиваться возможность доступа к локальным системным журналам для последующей трассировки событий.
- 4. Следует обеспечивать возможность записи в системные журналы информации о всех действиях anti-relay/anti-spam.
- 5. Следует обеспечивать возможность отказа от приема почты для хоста или группы хостов.
- 6a. Недопустимо отвергать "MAIL From: <>".
- 6b. Недопустимо отвергать "MAIL From: <[email protected] >".
- 7a. Следует обеспечивать возможность отвергать почту от конкретного пользователя "MAIL From:" user, <[email protected] >.
- 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>) может быть регистрозависимой, для ее проверки разумно учитывать регистр символов. Однако, поскольку <[email protected] > и <[email protected] > скорей всего указывают на одного пользователя и поскольку в результате сравнения принимается решение об отбрасывании сообщения мы предлагаем при сравнении <local-part> также не учитывать регистр символов.
Интерпретация применения всех этих рекомендаций является достаточно гибкой — в зависимости от того, как вы реализуете фильтрацию спама сегодня, спамеры будут завтра искать обходные пути и качественные реализации MTA должны обеспечивать достаточную гибкость для предотвращения новых уловок и хитростей спамеров.