Эффективность решений по борьбе с нежелательными сообщениями

Фильтрация и принятие решения о приёме или об отказе принять почтовое сообщение может происходить синхронно и асинхронно.  В синхронном режиме процесс проверки происходит во время SMTP-диалога с отправляющей стороной. Асинхронная работа заключается в том, что письмо принимается в любом случае, SMTP-диалог завершается успешно, а далее происходит принятие решения о доставке или отказе в доставке сообщения в ящик пользователя.

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

Минусом асинхронного режима является ситуация, когда мы принимаем решение — отказать в доставке. В таком случае сообщение об ошибке доставки (bounce message) уходит на адрес отправителя. Распространенный ход при отправке спама — это подделка адреса отправителя. В результате этого, мы отправляем ошибку о доставке на поддельный адрес, который ничего не знает про исходное сообщение. А при большом потоке таких писем на наш сервер, мы можем попросту «завалить» чей-то ящик своими ошибками о доставке.

В настоящее время серверные ресурсы достаточно не дороги,  потому синхронный режим выглядит более успешным. Мы не принимаем тех сообщений, что нам не нравится. Спам остаётся у спамера. Мы не копим очереди с bounce message у себя на сервере и не заваливаем ими не виновные сервера и ящики. Все довольны!

В синхронном режиме можно выделить два этапа принятия решения: ранний этап (early rejection) и поздний (rejection). Разница между ними в том, что ранний этап происходит до начала передачи основного тела сообщения (DATA), а поздний этап происходит, когда всё письмо уже принято и отправляющая сторона ждёт от нас завершающего ответа. Отклонение сообщения на раннем этапе позволяет сэкономить трафик и ресурсы нашего сервера. Мы не приняли еще само сообщение, но у нас уже есть ip-адрес передающей стороны, email-адрес отправителя и email-адреса получателей. Если по этим данным уже можно принять решение об отказе в приёме сообщения — надо это делать на ранней стадии.

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

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

0. Предварительная фильтрация:

• заблокировано через greylisting:  4`090`760 (50%)

1. Оставшиеся 50% сообщений прошли на первую стадию фильтрации. Ранний этап (early rejection) в применении к оставшимся 50%:

• заблокировано через DNSBL: 3`330`854  (81%)
• не существующие ящики: 411`470  (10%)
• локальный чёрный-список: 154`578 (3,8%)
• заблокировано через SPF: 93`518 (2,3%)
• ошибки в адресе отправителя (host name is unknown+DNS server failure+RFC822 blocks): 32`379 (0,8%)
• ошибки SMTP протокола и не авторизованные попытки:  8`636 (0,2%)

На первом этапе (early rejection) мы отвергли 98% сообщений от 50%, прошедших нулевой этап. Или 99% от всего потока сообщений. Это достаточно хорошо, но при больших потоках сообщений оставшийся 1% писем — это тоже достаточно большое число.

2. Переходим ко второму этапу, куда прошёл только 1% сообщений. Анализируем содержимое сообщений:

• свободный контекстный антиспам фильтр DCC: 16`890 (20%)
• коммерческий контекстный антиспам фильтр — отвергнут явный спам: 1`618 (2%)
• коммерческий контекстный антиспам фильтр — помечены похоже на спам сообщения: 6`483 (8%)
• антивирус: 5 (<0,1%)

Получается, что из оставшегося 1% сообщений мы отфильтровали еще 30%. То есть каждое третье письмо.

Выводы:

1. Greylisting на начальном этапе достаточно эффективен. Он уменьшает трафик на 50%;
2. Ранний этап (early rejection) позволяет на начальной стадии и с минимальными усилиями отклонить до 99% не желательных сообщений;
3. Проверка контекста — «тяжёлая» операция. Нужно принять сообщение и провести проверку его содержимого. Это сильно использует ресурсы сервера: сеть, процессор, память. Потому чем больше вы отклоните сообщений на первом этапе, тем лучше вам будет жить на втором.
4. Проверка контекста сообщений позволяет избавиться еще от 30% спама;
5. Оставшиеся сообщения, по отзывам клиентов, содержат еще примерно 10% спама.

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

Системы обучения на ложных срабатываниях антиспама и на неверно определенном спаме помогут  свести спам к минимуму.

По теме:

• Борьба со СПАМом для высоконагруженных почтовых систем на примере MTA Zmailer (4)
• Greylisting для CGP (2)
• dcc-cgp helper (4)
• DCC (Distributed Checksum Clearinghouse) (0)
• Белые списки для CGP (0)