Это модифицированная версия dcc-cgp v1.1.2 и плюс исправленные патчи для накатывания на dcc-1.3.140.

Мои модификации dcc-cgp v1.1.2:

• изменил коды ошибок GREY_XCODE и DCC_XCODE на x.9.9. Это позволяет сообщать отправляющей стороне о причине ошибки в момент работы greylist-инга;
• изменил dcc_mk_su () для работы с новыми версиями dcc;
• изменил GCP_PROTOCOLS – список протоколов, которыми сообщение может попасть в систему и будет обработано этим хелпером. В него добавлены некоторые WEB протоколы, но удалён RPOP;
• немного исправлены информационные сообщения;
• переименована функция strcasestr в _strcasestr.

Я уже больше года использую эти модификации на своей системе и пока доволен.

Если вы хотите пользоваться не модифицированной версией от автора dcc-cgp, то вам надо заменить dcc-cgp/dcc-cgp.c на версию из оригинального дистрибутива и модифицировать одну строку:

-      dcc_mk_su(DCCsu, hp->h_addrtype, hp->h_addr, Port);
+      dcc_mk_su(DCCsu, hp->h_addrtype, hp->h_addr, 0, Port);

Установка модифицированной версии аналогична оригинальной:

• скачать и развернуть архивы dcc и dcc-cgp;
• содержимое dcc-cgp перенести в дерево dcc;
• накатить dcc-CGP.patch и для не FreeBSD систем не забыть накатить dcc-CGP-nonFreeBSD.patch;
• для перехода к не модифицированной версии dcc-cgp заменить dcc-cgp/dcc-cgp.c из оригинального дистрибутива и изменить одну строку как это описано чуть выше;
• собрать, установить и настроить dcc как это описано в его документации;
• скопировать получившийся dcc-cgp/dcc-cgp в рабочую папку CGP и настроить его запуск как CGP хелпера.

Основная идея «белых списков» — уменьшить количество ложных срабатываний остальных антиспам фильтров.

Мне показалось, что наиболее полную базу «белых адресов» имеет ресурс dnswl.org. Этот ресурс, помимо самого факта «чистоты» ip-адреса, хранит так же уровень этой чистоты(Trust Level).

Всего уровней четыре:

1. High – никогда не рассылал спам;
2. Medium – крайне редки случаи спама, быстро реагируют на проблемы;
3. Low – иногда рассылают спам, активно реагируют на проблемы, но менее оперативно;
4. None – легитимный почтовый сервер, но может рассылать спам.

Применение этого белого списка может быть таким:

• не применять технологию «серых списков» для всех ip-адресов с уровнями None-High;
• не применять технологию «черных списков» для всех ip-адресов с уровнями None-High;
• не проверять письма на спам (или проверять в меньшей степени) для ip-адресов с уровнями Medium-High.

Вся остальная почта с адресов, которых нет в DNSWL, пройдёт полную проверку.

Для CGP я написал dnswl-cgp.c фильтр (cgp helper), который делает запрос в DNSWL и добавляет в сообщение заголовок: «X-DNSWL-Status: <Trust Level>».

Читать дальше Белые списки для CGP

Для реализации технологии Greylisting и DCC для CommuniGate (CGP) можно применить «DCC interface for CommuniGate®Pro server» от  Spam-Killer.Simtel.Ru

Под linux cобирается это достаточно просто:

• берём исходный код DCC
• берём исходный код DCC-CGP (он представляет собой несколько патчей для DCC)
• патчим DCC по инструкции от DCC-CGP
• собираем DCC и получаем сам DCC клиент и сервер, и DCC-CGP helper, который подключается в CGP так же как обычный helper

С этого момента в CGP доступны серые списки и контекстный антиспам фильтр на базе DCC. Как настроить сам DCC для работы с серыми списками и реализовывать антиспам защиту, я уже описывал ранее в заметке: DCC (Distributed Checksum Clearinghouse)

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

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

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

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

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

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

Для больших высоконагруженных почтовых систем подходят далеко не все методы борьбы со спамом и вирусами. К сожалению, но гибкий и достаточно универсальный SpamAssassin с ядром на Perl становится узким местом, при большом потоке почты. Приходится или экстенсивным методом наращивать железо или искать другие методы решения задач.

Здесь я хочу рассказать, как организовать проверку на вирусы и некоторые типы борьбы со спамом в промышленных масштабах, с потоком почты более 5'000'000 писем в сутки.

Читать дальше Борьба со СПАМом для высоконагруженных почтовых систем на примере MTA Zmailer

Эта технология антиспама хорошо работает, когда есть общее распределённое хранилище сумм, и много клиентов, которые сообщают в этот сервер суммы своих писем. Спам обычно рассылается большим количеством одинаковых писем. И если несколько почтовых серверов сообщили о том, что какое-то письмо с такой контрольной суммой уже прошло большое количество раз, то наш сервер может попросту отвергнуть его, как массовую рассылку. При подсчёте контрольных сумм используется несколько параметров письма, но основные и чаще всего используемые это: Body, Fuz1 и Fuz2. Body — это контрольная сумма тела письма, а для подсчёта Fuz1 и Fuz2 используется fuzzy механизм, который позволяет игнорировать некоторые аспекты письма, которыми пользуются спамеры для усложнения обнаружения таких рассылок (hashbuster).

(статистика с сайта DCC )

Для общения MTA с DCC-сервером используется DCC-клиент, который получает на вход письмо от почтового сервера, высчитывает контрольные суммы, передаёт их DCC-серверу, получает от него ответ, анализирует ответ и сообщает MTA как поступить с письмом. DCC-клиент чаще всего устанавливается непосредственно на почтовый сервер, а DCC-сервер чаще всего удалённый. Давайте попробуем установить DCC и настроить его для разных типов работы.

Читать дальше DCC (Distributed Checksum Clearinghouse)