Find Attachments хелпер для CGP: обновление
$ rm /tmp/mu*
Find Attachments хелпер для CGP
После месячного тестирования решил опубликовать еще один «хелпер» для CGP: findattach-cgp.c
Использовать этот «хелпер» можно для запрещение прохождения через почтовую систему определённых типов файлов. Например так, как описано на сайте РГУ.
Работа фильтра сводится к поиску вложений в проходящих через него сообщениях. Фильтр добавляет в сообщение заголовок с расширением вложенных файлов. Например для *.exe вложений будет добавлен заголовок: «X-AttachExt: exe». Добавляется только один заголовок для каждого типа файлов.
По функционалу фильтр похож на фильтр от компании Niversoft. Он написан на C, потому имеет высокую скорость работы.
Как известно для прикручивания антивируса ClamAV к CGP есть два открытых helper’а: clamav-cgp и cgpav.
Есть еще один платный от "Niversoft", но его мы рассматривать не будем.
Как выяснилось, работают они не одинаково. При рассылке большого потока одинаковых сообщений, заметили, что письма уходят медленно — в среднем 1 в секунду. Анализ SMTP диалога отправки сообщений показал, что тормозит проверка антивирусом. При отключенном антивирусе трафик вырос до 30 писем в секунду.
Исследования показали, что сам антивирус не потребляет особо много ресурсов. Тогда возникла мысль про тормоза «прокладки» между CGP и ClamAV. В это время у нас работал cgpav, решили попробовать clamav-cgp. И о чудо, с новым helper`ом трафик вырос до 15 писем в секунду. Спасибо Andy Igoshin’у за замечательный продукт!
У себя я выложил слегка модифицированную «под себя» версию:
- Добавлено отрезание CGP-ных заголовков перед отправкой письма на проверку к ClamAV (рекомендации Николая Варинова из рассылки mx.ru: http://mx.ru/Lists/CGatePro/Message/17475-P.txt).
- Немного изменена логика работа helper’а. В случае каких-то внутренних проблем он всегда пропускает сообщение. В логи пишется диагностика ошибки.
- Если ClamAV сообщает, что письмо инфицировано, то вместо молчаливого удаления сообщения, генерируется ответ с причиной: в сообщении <YYYYY> найден <XXXXX> вирус.
Комментарии к изменениям: Читать полностью »
Фильтрация и принятие решения о приёме или об отказе принять почтовое сообщение может происходить синхронно и асинхронно. В синхронном режиме процесс проверки происходит во время SMTP-диалога с отправляющей стороной. Асинхронная работа заключается в том, что письмо принимается в любом случае, SMTP-диалог завершается успешно, а далее происходит принятие решения о доставке или отказе в доставке сообщения в ящик пользователя.
В каждом этом методе есть плюсы и минусы. Синхронный режим заставляет отправляющую сторону оставаться подключенной к нашему серверу в течении всего периода принятия решения, что тратит наши ресурсы (память, открытые сокеты). Асинхронный режим позволяет быстро завершить SMTP-диалог, освободить ресурсы, а уже потом заняться анализом сообщения.
Минусом асинхронного режима является ситуация, когда мы принимаем решение — отказать в доставке. В таком случае сообщение об ошибке доставки (bounce message) уходит на адрес отправителя. Распространенный ход при отправке спама — это подделка адреса отправителя. В результате этого, мы отправляем ошибку о доставке на поддельный адрес, который ничего не знает про исходное сообщение. А при большом потоке таких писем на наш сервер, мы можем попросту «завалить» чей-то ящик своими ошибками о доставке.
В настоящее время серверные ресурсы достаточно не дороги, потому синхронный режим выглядит более успешным. Мы не принимаем тех сообщений, что нам не нравится. Спам остаётся у спамера. Мы не копим очереди с bounce message у себя на сервере и не заваливаем ими не виновные сервера и ящики. Все довольны!
В синхронном режиме можно выделить два этапа принятия решения: ранний этап (early rejection) и поздний (rejection). Разница между ними в том, что ранний этап происходит до начала передачи основного тела сообщения (DATA), а поздний этап происходит, когда всё письмо уже принято и отправляющая сторона ждёт от нас завершающего ответа. Отклонение сообщения на раннем этапе позволяет сэкономить трафик и ресурсы нашего сервера. Мы не приняли еще само сообщение, но у нас уже есть ip-адрес передающей стороны, email-адрес отправителя и email-адреса получателей. Если по этим данным уже можно принять решение об отказе в приёме сообщения — надо это делать на ранней стадии.
Давайте на примере суточной статистика одного почтового сервера рассмотрим эффективность разных типов борьбы с нежелательными сообщениями на разных стадиях.
MTA ZMailer(zmailer.org) у нас не популярен. Порывшись в русском сегменте сети, я нашёл более-менее подробный рассказ про ZMailer только в статье Игоря Ченцова: «Борьба со СПАМ-ом на примере почтового сервера zmailer».
Для больших высоконагруженных почтовых систем подходят далеко не все методы борьбы со спамом и вирусами. К сожалению, но гибкий и достаточно универсальный SpamAssassin с ядром на Perl становится узким местом, при большом потоке почты. Приходится или экстенсивным методом наращивать железо или искать другие методы решения задач.
Здесь я хочу рассказать, как организовать проверку на вирусы и некоторые типы борьбы со спамом в промышленных масштабах, с потоком почты более 5'000'000 писем в сутки.
