Доброго времени.Задался вопросом фильтрации спама. Сейчас на сервере стоит amavisd-new, завязанный с postfix. Но тут вот интересные подробности возникают. Существует ограничение на количество запущенных процессов, а значит возможности одновременного приема писем. При заданных max_requests в 20, у меня скушано три гигабайта оперативки (вместе с постфиксом и прочими).
Далее еще интересный момент - при пиковой загрузке - как правило днем, или иногда вечером amavisd процессы видимо завершаются аварийно и в папке /var/amavisd/tmp, куда он складывает письма на фильтрацию повисают не убитые каталоги - по нескольку штук на минуту.
Помимо прочего - разрастается спамассассиновская байесовская и автовайт лист база до 30-40 метров, и замедляется поток писем - начинает расти active очередь в постфиксе.
Какие есть способы оптимизировать фильтрацию? Возможно есть красивый вариант заставить постфикс складывать входящую почту в очередь на фильтрацию, а другой процесс заставить вытаскивать ее оттуда и фильтровать?
Кто как решает проблему борьбы со спамом?
->firewall->greylist->postfix(pcre,ehlo,*_restrict_*)->amavis-new->local mailer.
" Возможно есть красивый вариант заставить постфикс складывать входящую почту в очередь на фильтрацию, а другой процесс заставить вытаскивать ее оттуда и фильтровать?"
MTA-> local MTA(217.0.0.1 only)
>->firewall->greylist->postfix(pcre,ehlo,*_restrict_*)->amavis-new->local mailer.
>" Возможно есть красивый вариант заставить постфикс складывать входящую почту в очередь
>на фильтрацию, а другой процесс заставить вытаскивать ее оттуда и фильтровать?"
>
>MTA-> local MTA(217.0.0.1 only)А скажите смысл этого: "postfix(pcre,ehlo,*_restrict_*)->amavis-new->local mailer."
если есть серые списки?
да более того можно так же сконфигурировать и белый список...
>>->firewall->greylist->postfix(pcre,ehlo,*_restrict_*)->amavis-new->local mailer.
>>" Возможно есть красивый вариант заставить постфикс складывать входящую почту в очередь
>>на фильтрацию, а другой процесс заставить вытаскивать ее оттуда и фильтровать?"
>>
>>MTA-> local MTA(217.0.0.1 only)
>
>А скажите смысл этого: "postfix(pcre,ehlo,*_restrict_*)->amavis-new->local mailer."
>если есть серые списки?
>да более того можно так же сконфигурировать и белый список...Стоп. Белые/серые списки, на мой взгляд, это уже надстройка. ИМХО, когда валится туча спама, с разных хостов, на примерно тысячу ящиков - не буду ж я все это дело руками грей/вайт листить? Я так понимаю должно быть что-то типа спам-ассассина или сам ассассин. А вот ему уже говорить - мол это не трогай (вайт), а вот это тож пока зажми (грей).
И я не совсем понял нарисованную схему - а где отложенная фильтрация то? amavis же принимает почту так сказать прямо по smtp снаружи и рулит уже ее дальше. Примерно так у меня сейчас и есть - хост принимает, а в transports сказано - мол почта на домен tratata.net smtp:10.0.0.1, например.
>[оверквотинг удален]
>буду ж я все это дело руками грей/вайт листить? Я так
>понимаю должно быть что-то типа спам-ассассина или сам ассассин. А вот
>ему уже говорить - мол это не трогай (вайт), а вот
>это тож пока зажми (грей).
>
>И я не совсем понял нарисованную схему - а где отложенная фильтрация
>то? amavis же принимает почту так сказать прямо по smtp снаружи
>и рулит уже ее дальше. Примерно так у меня сейчас и
>есть - хост принимает, а в transports сказано - мол почта
>на домен tratata.net smtp:10.0.0.1, например.spamassasin хорошее решение, но он достаточно ресурсоемкий.
Идеальным решением наверное было бы разделить задачи -
установить "впереди" машину, на которой работает smtp, выполняются основные фильтрации sfp,rcpt,hello и тд, далее все почта пересылается на другую машину/или группу машин, где уже выполняются остальные задачи фильтрации (антивирус,антиспам, фильтры)...
а вообще сервй лист должен существенно помочь
Прикрутил postgrey. Будем посмотреть как оно себя вести будет. Пока очень много почты грейлистит, указывая reason=new.За примерно час работы:
# grep "action=grey" /var/log/maillog | wc -l
2727
# grep "action=pass" /var/log/maillog | wc -l
342
>Прикрутил postgrey. Будем посмотреть как оно себя вести будет. Пока очень много
>почты грейлистит, указывая reason=new.
>
>За примерно час работы:
># grep "action=grey" /var/log/maillog | wc -l
>2727
># grep "action=pass" /var/log/maillog | wc -l
>342расскажите, каким образом у Вас релизоны "серые списки" ?
>>Прикрутил postgrey. Будем посмотреть как оно себя вести будет. Пока очень много
>>почты грейлистит, указывая reason=new.
>>
>>За примерно час работы:
>># grep "action=grey" /var/log/maillog | wc -l
>>2727
>># grep "action=pass" /var/log/maillog | wc -l
>>342
>
>расскажите, каким образом у Вас релизоны "серые списки" ?это же не списки запрещенного чего-то в прямом понимании. Технология простая: приходит коннект к серверу и тот отвечает что-нить типа: я тут счас занят очень, почту принять не могу, приходи через 30 минут. И помещает IP в серый список. Далее когда клиент приходит, сервер сверяется со списком, если прошло указанное время, почта принимается, если нет, настойчиво повторяют просьбу прийти попозже. Если в итоге сеанс состоялся, IP помечается как благонадежный, например на сутки-двое и при приходе запроса с него в четении этого времени "благонадежности" принимается к обслуживанию без постановки в лист ожидания. КАк-то примерно так.
Смысл в том что спамеры работают на скорость и количество, а не на качество. Поэтому второй раз после отлупа редко возвращаются. Сейчас, по крайней мере.
>>Прикрутил postgrey. Будем посмотреть как оно себя вести будет. Пока очень много
>>почты грейлистит, указывая reason=new.
>>
>>За примерно час работы:
>># grep "action=grey" /var/log/maillog | wc -l
>>2727
>># grep "action=pass" /var/log/maillog | wc -l
>>342
>
>расскажите, каким образом у Вас релизоны "серые списки" ?Реализованы так - скачал postgrey, запустил его вот так:
/usr/libexec/postfix/postgrey -d --inet=127.0.0.1:9998 –delay=55
В main.cf:
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
reject_rbl_client list.dsbl.org,
reject_rbl_client dynablock.wirehub.net,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client sbl-xbl.spamhaus.org,
check_policy_service inet:127.0.0.1:9998Правильно? :)
>[оверквотинг удален]
> permit_sasl_authenticated,
> permit_mynetworks,
> reject_unauth_destination,
> reject_rbl_client list.dsbl.org,
> reject_rbl_client dynablock.wirehub.net,
> reject_rbl_client dnsbl.njabl.org,
> reject_rbl_client sbl-xbl.spamhaus.org,
> check_policy_service inet:127.0.0.1:9998
>
>Правильно? :)Я именно интересовался реализация, про принцип работы я в курсе, но всеравно спасибо.
Как я понимаю postgrey идет отдельно к Вашему MTA ?
У меня реализация полностью средствами MTA exim.
>Я именно интересовался реализация, про принцип работы я в курсе, но всеравно
>спасибо.
>Как я понимаю postgrey идет отдельно к Вашему MTA ?
>У меня реализация полностью средствами MTA exim.Нашел я его гуглем. Вроде бы как он для postfix, но в комплекте есть ридми для привязки к exim. Брал тут:
http://postgrey.schweikert.ch/
>[оверквотинг удален]
>
>Помимо прочего - разрастается спамассассиновская байесовская и автовайт лист база до 30-40
>метров, и замедляется поток писем - начинает расти active очередь в
>постфиксе.
>
>Какие есть способы оптимизировать фильтрацию? Возможно есть красивый вариант заставить постфикс складывать
>входящую почту в очередь на фильтрацию, а другой процесс заставить вытаскивать
>ее оттуда и фильтровать?
>
>Кто как решает проблему борьбы со спамом?грейслистинг... очень помогает