приветствую.
пишу в оба листа, т. к. ситуация, описанная ниже, касается как exim, так
и SpamAssassin.
вчера закончено тестирование поддержки spamd dlfunc для exim:
http://mta.org.ua/exim-4.68-conf/dlfunc/spamd/spamd.c
сама dlfunc была реализована ранее как отдельный продукт. в данной
версии для паровоза 4.68 только добавлена поддержка разделения спула на
подкаталоги (см. параметр split_spool_directory в документации к exim).
сама поддержка spamd dlfunc реализована в виде файла
features/dlfunc_spamd.m4, подключаемого в виде FEATURE(`dlfunc_spamd'):
http://mta.org.ua/exim-4.68-conf/features/dlfunc_spamd.m4
включить использование spamd dlfunc в site/conf можно, указав значение
DLFUNC_SPAMD в значении confCONTENT_SCANNING. все сопутствующие
параметры настройки работы с spamd такие же, как при использовании
значения SPAMASSASSIN в значении confCONTENT_SCANNING.
сам переход со штатной интеграции exim и spamd на spamd dlfunc
обусловлен необходимостью оценивать с помощью spamd полей заголовков,
добавляемых в acl_smtp_mime и acl_smtp_data.
это невозможно при использовании штатной интеграции exim и spamd, т. к.
в этом случае exiscan отдает на проверку spamd файл из
/var/spool/exim/scan, который создается функцией spool_mbox из exim
(src/spool_mbox.c) при первом же обращении к любой фукнции exiscan.
spamd dlfunc действует несколько по-другому. dlfunc берет все поля
заголовков из связного списка header_list, удаляет из него все
заголовки, перечисленные в связном списке acl_removed_headers, и
добавляет все заголовки, перечисленные в связном списке
acl_added_headers, потом берет тело письма каталога спула
/var/spool/exim/input и все это через сокет передает демона spamd на
проверку.
acl_added_headers - это связный список полей заголовков, добавленных с
помощью параметра message из warn acl или при помощи оператора add_header.
acl_removed_headers - это связный список полей заголовков, удаленных с
помощью оператора remove_header. напоминаю, что данный функционал не
реализован в штатном exim'е, для его использования необходимо наложить патч:
http://mta.org.ua/exim-4.68-conf/patches/exim-4.68-remove_header/patch-src::remove_header.patch
патчу этому около полутора лет, сделан он был еще для exim 4.62 и
зарегистрирован на bugs.exim.org:
Implement remove_header ACL modifier
http://www.exim.org/mail-archives/exim-dev/2007-May/msg00015.htmlhttp://www.exim.org/bugzilla/show_bug.cgi?id=198http://www.exim.org/bugzilla/attachment.cgi?id=74
поводом для оценки SpamAssassin'ом полей заголовков, добавленных в
acl_smtp_mime и acl_smtp_data, стало желание начислять баллы за ошибки
MIME, детектируемые с помощью $mime_anomaly_level в acl_smtp_mime или
$demime_errorlevel в acl_smtp_data (см. параметр confCHECK_MIME_ERRORS в
http://mta.org.ua/exim-4.68-conf/m4/conf.default).
нерешенным остается только вопрос, оставлять ли имя файла
features/dlfunc_spamd.m4 или переименовать его в features/spamd.m4. ну и
по аналогии можно значение DLFUNC_SPAMD для confCONTENT_SCANNING
переименовать в SPAMD. по идее все равно отдельных значения SPAMD и
файла features/spamd.m4 уже не появится. но это все лирика и к
фукнционалу паровоза отношения не имеет.
теперь часть, касающаяся непосредственно SpamAssassin.
на одном из хостов у меня существует сложная схема использования контент
сканеров в exim (сразу предупреждаю, это все реализовано сугубо в
тестовых целях):
сначала письмо передается демону DSPAM с помощью dspam dlfunc:
http://mta.org.ua/exim-4.68-conf/dlfunc/dspam/dspam.chttp://mta.org.ua/exim-4.68-conf/features/dspam.m4
далее письмо передается демону Kaspersky Anti-Spam 3.0.x с помощью kas3
dlfunc:
http://mta.org.ua/exim-4.68-conf/dlfunc/kas3/kas3.chttp://mta.org.ua/exim-4.68-conf/features/kas3.m4
сделано это для того, чтобы Kaspersky Anti-Spam мог с помощью специально
подготовленных правил учитывать оценки DSPAM при формировании своих
оценок, ибо в состав Kaspersky Anti-Spam штатно не входит статистический
фильтр (построенный по алгоритму Bayes или подобному), следовательно при
штатном использовании KAS невозможно обучением смягчить или ужесточить
оценки для писем.
далее письмо передается демону spamd с помощью spamd dlfunc:
http://mta.org.ua/exim-4.68-conf/dlfunc/spamd/spamd.chttp://mta.org.ua/exim-4.68-conf/features/dlfunc_spamd.m4
после отказа от использования штатной интеграции exim с spamd и перехода
на использование spamd dlfunc демону spamd стали доступны все заголовки,
добавляемые демонами dspam и kas. при этом у меня сам spamd обращается к
dspam с помощью специально написанного плагина:
http://mta.org.ua/spamassassin-3.2.5/patches/3.1.7/DSPAM/lib/Mail/SpamAssassin/Plugin/DSPAM.pm
поставляемого в виде патча:
http://mta.org.ua/spamassassin-3.2.5/patches/3.1.7/patch-src::DSPAM-3.1.7.patch
данный плагин позволяет SpamAssassin'у передавать письмо демону dspam,
получать от него содержимое письма с добавленными заголовками dspam,
переименовывать их (заменять X-DSPAM-* на X-Spam-DSPAM-* и
X-Daemon-Classification на X-Spam-Daemon-Classification), корректировать
свои оценки письма исходя из оценок dspam.
проблема заключается в том, что при использовании такой сложной схемы
проверки письма контент сканерами плагин DSPAM.pm не различал заголовки
dspam, добавленные в письмо тем dspam, которому передал письмо exim с
помощью dspam dlfunc, и заголовки dspam, добавленные в письмо тем dspam,
которому передал письмо сам плагин. в итоге в письме вместо двух наборов
заголовков dspam (в виде полей X-DSPAM-* и X-Spam-DSPAM-*) появлялись
два набора полей заголовков dspam, оба с именами полей X-Spam-DSPAM-*.
т. е. плагин переименовывал не только заголовки, только что добавленные
демоном dspam, но и добавленные ранее.
проблема решена самым простым (но не самым качественным) способом -
плагин перед передачей письма демону dspam переименовывает все найденные
заголовки X-DSPAM-* в X-X-DSPAM-*, после получения результата от демона
dspam переименовывает только что добавленные заголовки X-DSPAM-* в
X-Spam-DSPAM-*, а ранее имевшиеся заголовки переименовывает обратно из
X-X-DSPAM-* в X-DSPAM-*.
новый вариант плагина:
http://mta.org.ua/spamassassin-3.2.5/patches/3.2.5/DSPAM/lib/Mail/SpamAssassin/Plugin/DSPAM.pmhttp://mta.org.ua/spamassassin-3.2.5/patches/3.2.5/patch-src::DSPAM-3.2.5.patch
использование нового патча, добавляющего новый плагин для работы с DSPAM
в состав SpamAssassin, добавлено в:
механизм сборки порта SpamAssassin 3.2.5 для FreeBSD:
http://mta.org.ua/spamassassin-3.2.5/ports/p5-Mail-SpamAssassin-3.2.5/
механизм сборки пакета SpamAssassin 3.2.5-1 для RedHat/CentOS/Fedora:
http://mta.org.ua/spamassassin-3.2.5/redhat/spamassassin-3.2.5-1.fc10.corvax/
бинарные пакеты SpamAssassin 3.2.5-1 для RedHat/CentOS/Fedora для
рипозитария http://mta.org.ua/updates/ я не пересобирал, т. к. описанная
выше ситуация скорее носит академический характер и встречаться в
реальной жизни может чрезвычайно редко.
пакеты с данным патчем будут собраны при сборке следующей версии
SpamAssassin.
p. s. при использовании такой схемы нужно в dspam.conf добавить
игнорирование полей заголовков:
IgnoreHeader X-X-Daemon-Classification
IgnoreHeader X-X-DSPAM-Result
IgnoreHeader X-X-DSPAM-Processed
IgnoreHeader X-X-DSPAM-Confidence
IgnoreHeader X-X-DSPAM-Improbability
IgnoreHeader X-X-DSPAM-Probability
IgnoreHeader X-X-DSPAM-Signature
IgnoreHeader X-X-DSPAM-Factors
наряду с добавленными ранее:
IgnoreHeader X-Daemon-Classification
IgnoreHeader X-DSPAM-Result
IgnoreHeader X-DSPAM-Processed
IgnoreHeader X-DSPAM-Confidence
IgnoreHeader X-DSPAM-Improbability
IgnoreHeader X-DSPAM-Probability
IgnoreHeader X-DSPAM-Signature
IgnoreHeader X-DSPAM-Factors
--
Best wishes Victor Ustugov mailto:victor на corvax.kiev.ua
public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc
ICQ: 77186900, 32418694 CRV2-RIPE, CRV-UANIC