Небольшое, но важное обновление хелпера поиска вложений для CGP: включено mu_message_destroy (). До этого оно было выключено по причине утечек памяти, которые вызывало. Но отсутствие mu_message_destroy () приводило к замусориванию /tmp директории. Сегодня в git версии mailutils появились исправления этих утечек и я включил mu_message_destroy (). После обновления findattach-cgp.c надо удалить мусор в /tmp:

 $ rm /tmp/mu*

После месячного тестирования решил опубликовать еще один «хелпер» для 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’у за замечательный продукт!

У себя я выложил слегка модифицированную «под себя» версию:

1. Добавлено отрезание CGP-ных заголовков перед отправкой письма на проверку к ClamAV (рекомендации Николая Варинова из рассылки mx.ru: http://mx.ru/Lists/CGatePro/Message/17475-P.txt).
2. Немного изменена логика работа helper’а. В случае каких-то внутренних проблем он всегда пропускает сообщение. В логи пишется диагностика ошибки.
3. Если 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 писем в сутки.

Читать полностью »