Curiouser and curiouser!
Кстати, уже пару лет как посещяет мысль написать пару статей, на предмет построения почтовой системы postfix+dovecot+sqlite и отдельного стоящего почтового прокси (mx) на основе postfix для фильтрации спама. Благо в обоих случаях есть опыт внедрения и в принципе, довольно результативного в плане работы антиспама. Таки судя по всему напишу.
Stay tuned! (c) 
В последнем снапшоте 20100618 добавили поддержку sqlite. Но добавили так, что на CentOS не собирается со следующей ошибкой:
“dict_sqlite.c:71:2: error: #error “Your SQLite version is too old”
dict_sqlite.c: In function ‘dict_sqlite_lookup’:
dict_sqlite.c:203: warning: implicit declaration of function ’sqlite3_prepare_v2′
make: *** [dict_sqlite.o] Error 1
make: *** [update] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.38770 (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.38770 (%build)
”
Старые грабли, пару лет назад я на них уже наступал
Отправил письмо на postfix-devel, посмотрил, что разработчики скажут. Но скорее всего правильно будет на этапе компиляции проверять версию sqlite и использовать всякие ifdef’ы.
Иногда требуется что-то в почтовой системе отдебажить прямо на рабочем сервере. Логи у postfix при дебаге откровенно говоря адские по размеру. Если включить дебаг обычным способом (master.cf smtpd -v), то при выской нагрузке почтовый сервер либо сразу уйдет в торпор, либо система будет медленно задыхаться под тяжестью логов.
Кроме использования debug_peer_list (который включает дебаг только для smtpd) можно еще запустить отдельного демона smtpd на нестандартном порту или другом ip и только для него включить дебаг. Помимо клевого баннера для него можно использовать по-моему вобще всю отдельную цепочку сервисов через указание в опциях *_service_name. Я проверял только для cleanup.
/etc/postfix/master.cf:
0.0.0.0:2025 inet n - n - 10 smtpd -v
-o smtpd_banner=$debug_banner
-o cleanup_service_name=debug_cleanup
debug_cleanup unix n - n - 0 cleanup -v
/etc/postfix/main.cf:
debug_banner = $myhostname ESMTP ready. Welcome to Debug Hell.
Permalink Comments off
list “whitedomains” domain { google.com gmail.com yandex.ru ya.ru mail.ru bk.ru inbox.ru rambler.ru yahoo.com hotmail.com mx.aol.com nic.ru ripn.net relcom.spb.ru messagelabs.com livejournal.com vkontakte.ru odnoklassniki.ru }
…
racl whitelist list “whitedomains”
…
racl greylist from /.*@(gmail\.com|yandex\.ru|ya\.ru|narod\.ru|mail\.ru|bk\.ru|inbox\.ru|rambler\.ru|hotmail\.com|yahoo\.com|aol\.com)/ delay 1h autowhite 6h
…
Первый список немного избыточен, но не суть. Думаю, что это вполне можно раcширить. Может только еще поиграться с delay и autowhite.
Permalink Comments off
Типа немножко рекламы. Далеко не новость, что с bind все не очень хорошо во многих аспектах. Но, честно говоря, он является де-факто стандартом среди dns серверов и даже, цитируя opennet, он является “reference implementation, т. е. если где то стандарт можно толковать по разному, то делать надо так как это сделано в bind.”
Поэтому, пока я не столкнулся с тем, что он просто дропает часть запросов на очень нагруженном почтовом фронтенде с postfix и отьедает много памяти и проца, у меня и мысли не было искать ему замену. Готов согласиться с тем, что вероятнее всего среди авторитарных dns серверов ему сейчас замены нет, но для использования dns только в роли рекурсора все не так фатально. В статье по ссылке на opennet рассказывалось об различных альтернативах, но все они по разным причинам мне не походили. Как обычно меня не хватает на детальный разбор полетов, в смысле обзор, поэтому обойдусь практически без цифр Лучше всего показал себя в моих условиях unbound, который в качестве рекурсора решил все проблемы, которые были у меня с bind. Память лимитируется и ему хватило 256Mb, ну и запросы он пока не дропает. Процессор не поедает.
root@mx1 ~]# top -b | grep unbound
743 unbound 1 4 0 256M 237M kqread 0 20.6H 0.49% unbound
[root@mx1 ~]# ps aux | grep unbound | head -1
unbound 743 0.1 11.7 262028 242532 ?? RsJ 26Jul09 1233:48.63 /usr/local/sbin/unbound
[root@mx1 ~]# unbound-control stats
thread0.num.queries=623538557
thread0.num.cachehits=499713882
thread0.num.cachemiss=123824675
thread0.num.recursivereplies=123824635
thread0.requestlist.avg=20.4801
thread0.requestlist.max=240
thread0.requestlist.overwritten=0
thread0.requestlist.exceeded=0
thread0.requestlist.current.all=20
thread0.requestlist.current.user=15
thread0.recursion.time.avg=2.000007
thread0.recursion.time.median=0.0278163
total.num.queries=623538557
total.num.cachehits=499713882
total.num.cachemiss=123824675
total.num.recursivereplies=123824635
total.requestlist.avg=20.4801
total.requestlist.max=240
total.requestlist.overwritten=0
total.requestlist.exceeded=0
total.requestlist.current.all=20
total.requestlist.current.user=15
total.recursion.time.avg=2.000007
total.recursion.time.median=0.0278163
time.now=1254227226.907645
time.up=5600244.498232
time.elapsed=1947.175681
Любопытно будет посмотреть его статы, когда вся хостинговая почта будет переключена на использование этого фронтенда. Собственно говоря, связка postfix+unbound+milter-greylist показала себя уже очень хорошо и я могу ее рекомендовать в качестве реального антиспамого щита, но так как почти весь спам отшибается, совсем не видно, как работать система будет при большом потоке нормальных писем, которые нужно будет сохранять и передавать бэкендам. Тут как раз я имею шанс узнать, что такое нехватка дискового io с большой очередью . Ну все-таки задача приема писем безболезненно распараллеливается на несколько машин, поэтому не думаю, что тут будут какие-то глобальные проблемы. Так или иначе, об этом я тоже напишу по-позже.
P.S. И да, еще пара голословных утверждений: С точки зрения производительности gps(greylist policy service) - отстой. А milter-greylist рулит.
Permalink Comments off
6 стариков CGP, уставшие бороться со спамом. Молодой (2.6) воин postfix, в качестве фронтенда перед ними:
Total Connects In: 5911229 from 596296 hosts
Total Rejected Mail: 5674330
Total Greylisted Mail: 19537
Total Received Mail: 17760
Total Received Mail from Whitelisted: 6605
Смотрите в следующих сериях: Еще больше убитого спама. Еще больше спасенных калек CGP 4.1x и, конечно же, как всегда ничего неподозревающие и неблагодарные пользователи.
Оказывается на момент написания предыдущего поста, dspam в исполнении “Sensory Networks” был практически ни жив, ни мертв. Зато его успели форкнуть и оформить проект dspam-community с мыслью во что-то другое потом переименовать. Об этом я поленился написать, но не поленились написать на опеннете. А 12 января ”Sensory Networks” объявила о том, что не может больше поддерживать проект и передала все права на имя, текущую кодовую базу из cvs проекту dspam-community. В сравнительно ближайшем будущем они предполагают выпустить весию 3.8.1. Ждемс, так как версия из cvs оказалась таки глючной.
Оказывается проект вполне себе живой и в него неплохо “контрибутят” патчи. На несколько листов аж чейджлог. Но для для широкой общественности это не доходит, так как остается в недрах cvs и в мейллистах. Думаю, надо попробовать обновиться до 3.8.1cvs версии. Учитывая различные баги 3.8.0 вряд ли она окажется более бажной.
Кол-во reject’ов по блок-листам на одном из серверов:
bash-2.03# wc -l /tmp/blocked
6704432 /tmp/blocked
И уники:
bash-2.03# cat /tmp/blocked | sort | uniq | wc -l
227667
Раньше роль страшного пугала для пользователей и хостеров из борцов со спамом представлял sorbs, со своей неадекватной политикой включения и выключения хостов в свои списки. В последние пару лет его уверенно потеснил spamhaus. Помимо широко известного скандала с Мажордомо, когда один неадекватный регистратор Godaddy рубанул кучу доменов клиентов Мажоржомо по жалобе spamhaus, они гадят и в более маленьком масштабе:
http://www.spamhaus.org/sbl/sbl.lasso?query=SBL65965
Вот и пара наших серверов попала “заодно” вместе с подсеткой /24 за то, что в этой подсети располагался dns сервер комапнии nameself.com, которая поддерживает (only by dns) домен (2 штука), которые рекламировались спамом. Впрочем, /24 не предел. Многие пользователи colocation у компаниии RTCOMM помнят еще блок по /16 от того же spamhaus…