Прошло несколько месяцев работы dspam-фильтров в промышленных масштабах. Серьёзных проблем не найдено, но захотелось немного изменить граничные точки для X-Junk-Score заголовка.

Было:

/* Defines the bar score ranges. By default the following ratios are used:
* digital    Bar score
* 0          []
* 1-49       [X]
* 50-70      [XX]
* 71-89      [XXX]
* 90-94      [XXXX]
* 95-99      [XXXXX]
* 100        [XXXXXX]
*/
int BARSCORERANGES[] = {0,49,70,89,94,99,100,      -1};

Стало:

/* Defines the bar score ranges. By default the following ratios are used:
* digital    Bar score
* 0          []
* 1-49       [X]
* 50-70      [XX]
* 71-89      [XXX]
* 90-94      [XXXX]
* 95-98      [XXXXX]
* 99-100     [XXXXXX]
*/
int BARSCORERANGES[] = {0,49,70,89,94,98,100,      -1};

Изменились два последних диапазона. Это позволяет отделить максимальную вероятность 99 в отдельную группу. И применять к ней более суровые фильтры.

Я соответственно изменил, выложенные на сайте cgp- и zmailer- фильтры. Это единственное изменение в новых версиях.

Для написания некого почтового фильтра на Си понадобилась библиотека для работы с MIME-заголовками. Почтовый фильтр должен уметь вытаскивать из письма список имён вложенных в него файлов. Фильтр предполагался многопоточным(multithreaded) и потому библиотека должна была быть дружественна к многопоточному использованию (thread-safety).

Как оказалось — это не простая задача. Большинство найденных библиотек используют «глобальные области» для хранения разобранных MIME-структур. Отведённое место хранения данных всех потоков — едино. И при параллельной работе потоков происходит перемешивание данных. В лучшем случае приложение работает не правильно, в худшем — падает при очищении памяти одного потока из другого.

Исследованию подверглись библиотеки проектов: altermime, libmime, mimedecode, minimime, renattach, ripmime, uudeview. Для моих целей все эти библиотеки не подошли, и тщательных тестов я не проводил, но пару слов хочу сказать о двух из них:

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