Сбор мыслей как правильно фильтровать и обрабатывать спам в организации


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

Основные проблемы фильтрации спама в организации:

  1. Не должно быть недоставленных писем, т.к. это чревато репликами "почта не работает" с различными последствиями как моральными, так и материальными.
  2. Пользователи очень разного уровня, как знаний и дисциплины, так и по реакции и влиянию, от "все понятно, сам разберусь" до "чо это за @#$ня, я тут ни@#$ найти не могу". И соответственно, какие-то организационные правила, как некоторые рекомендуют, не всегда могут решить ситуации.

Обязательно:

  1. Принимать всю почту, что приходит для пользователя. False positive (определение как спам нормальных писем) никто не отменял frown и даже гугл с ним не разберется никак. Бывают письма, на которых у меня все три спам фильтра (SpamProbe, Rspamd, DCC) зашкаливают, а пользователь его все равно считает нужным. (Хотя при просмотре иногда выясняется, что это спам.) Нельзя полностью доверять всяческим black list'ам, соответствию правильности заголовков, DNS записям и т.д. - кривости, проблемы и т.д. бывают у всех и не важно, что криво с той стороны, письмо не доставлено нам.
  2. Добавлять свой маркер спам/не спам к заголовку писем. Это позволит использовать серверный спам фильтр на клиенте, даже если сервер не будет перемещать почту в отдельную папку или клиент подключен к серверу по pop3. Так же это поможет при отладке.

Желательно:

  1. Всю почту определяемую как спам складывать в отдельную папку пользователя. Тогда пользователь сам сможет разгребать свой спам в случае необходимости.
  2. Использовать динамические спам ловушки (spamtrap) для обучение спам фильтров. Т.е. учитываем несуществующие адреса, куда нам пытаются отправить почту и, при превышении какого-то количества попыток, все письма на эти адреса принимаем и передаем спам фильтру на обучение.
  3. Обучать спам фильтры с помощью исходящей почты. Это уменьшит количество false positive. Единственная проблема, что если пользователь поймает вирус, спам фильтры обучатся не тому - может спасти версионность базы обучения.
  4. Обучать спам фильтры с помощью входящей почты от постоянных доверенных абонентов. Т.е. если мы постоянно общаемся с user@example.com, то всю почту от этого пользователя и сервера этого пользователя (оба условия обязательны AND) скармливаем спам фильтру, как белое и пушистое.
  5. Использовать несколько спам фильтров с анализом качества их работы. У меня, пока, не нашлось идеального фильтра, правда использовал только открытые варианты.

Можно:

  1. Устанавливать небольшие (10-20 секунд) таймауты на соединениях для входящей почты. Нормальные сервера сквозь это проходят, а часть спама отваливается. Правда, при этом иногда появляются сообщения, что превышено количества подключений к серверу, но это, скорее всего, мешает только спамерам.
  2. Очищать у пользователей в автоматическом режиме письма из папки спам старше месяца. Обычно, через месяц теряется актуальность писем и если письмо не перенесли во входящую, то оно пользователю скорее всего не нужно. Тут вопрос с отпусками и т.д.
  3. Сделать возможность пользователям самим обучать спам фильтры. Самый лучший способ, подключение по IMAP и перекладывание писем в/из папку SPAM. Тут возможный камень, что пользователи могут всю почту, которая им не нужна, объявить спамом, вместо того, чтобы отписываться от рассылок, уведомлений и т.д.

Нежелательно:

  1. Использовать greylisting. Вроде, идея интересная, но есть несколько проблем. Сервисы типа google, yandex и т.д. имеют немаленький пул серверов/адресов и письмо от них будет очень долго пробиваться через серый список. Почта от новых людей может идти достаточно долго, т.к. время повтора отправки зависит от той стороны и повлиять на это никак нельзя. Т.к. на некоторых серверах greylist используют, со нашей стороны, для ускорения доставки им писем пришлось сделать, чтобы наш почтовый сервер первое время пытался отправить письмо через короткие промежутки времени, в течение 20 минут - через каждые 3 минуты. Дальше реже, т.к. считаем, что серверу действительно плохо и можно особо не дергаться.
  2. Тупо верить в SPF и DKMI. (Мысли по этому поводу нужно будет написать отдельно) У меня возникли проблемы, когда домен обслуживало несколько серверов в цепочке и последний сервер, обслуживаемый не мной не принимал почту, т.к. SPF разрешал получение писем только с конкретных адресов.

Несколько отдельная тема, но интересная, что делать с BackupMX?

Мысли вслух.

Получать всю почту, затем передавать основному, пусть разгребает.

Минусы:

  • Нагрузка на BackUp MX
    • Нагрузка на входящую сеть - получение того, что можно было отбросить.
    • Нагрузка на диск - хранение того, что можно было бы убить.
    • Нагрузка на исходящий канал - передача мусора основному mx серверу.
  • Нагрузка на основной сервер
    • Получение и обработка всего мусора, что при может увеличить время выхода из дауна.
  • Отсутствие гибкости - пользователи не могут отправлять почту через backup mx, т.к. он их не знает.

Плюсы:

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