|
|
ru.unix- RU.UNIX ---------------------------------------------------------------------- From : Alexander Kalmykov <avk398@so.yandex .ru> 20 Feb 2007 22:20:02 To : All Subject : Смягчить RBL, S25R и проч. через greylist под postfix. -------------------------------------------------------------------------------- .RFC-X-Complaints-To: gatekeeper@fido7.ru .RFC-NNTP-Posting-Date: Tue, 20 Feb 2007 16:20:02 +0000 (UTC) .RFC-X-BeforeModerator-Path: not-for-mail .RFC-X-BeforeModerator-NNTP-Posting-Host: p11.nlmk.ru .RFC-X-BeforeModerator-X-Trace: ddt.demos.su 1171988352 58349 81.20.194.99 (20 Feb 2007 16:19:12 GMT) .RFC-X-BeforeModerator-X-Complaints-To: gatekeeper@fido7.ru .RFC-X-BeforeModerator-NNTP-Posting-Date: Tue, 20 Feb 2007 16:19:12 +0000 (UTC) .RFC-User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051025 Thunderbird/1.5 Mnenhy/0.7.3.0 .RFC-X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (ddt.demos.su [127.0.0.1]); Tue, 20 Feb 2007 19:19:51 +0300 (MSK) .RFC-X-FTN-REPLYADDR: Alexander Kalmykov <avk398@so.yandex.ru> .RFC-Xref: cclinfo fido7.ru.unix:7738 From: Alexander Kalmykov <avk398@so.yandex.ru> Привет. Посмотрел на http://k2net.hakuba.jp/targrey/index.en.html. Приятно пишут про taRgrey - S25R + tarpitting + greylisting (tarpit + greylist policy server). Жаль, вариации на японском. Tarpit и проверку HELO решил не трогать. Включил greylist для тех, кто попадает под проверку S25R. Как следствие, в разы меньше спама (экономим трафик). То, что остается, уже совсем не проходит через spamassasin - сильно засвечено на RBL'ях и прочих razor'ах. Снижается вероятность ложных срабатываний spamassasin. X-Spam-Level в районе пяти теперь редкость, все больше в десятках. Для нормальных клиентов нет задержек на greylist (за что его и не любят). Хочется бОльшего. Hе только S25R, но и попавших в RBL прогонять через greylist. Для еще большей экономии трафика. Возможно, тогда и метки spamassasin'а станут мало актуальны. Hе хотелось бы дополнительных policy-демонов. Желательно ограничиться имеющимся функционалом reject_rbl_client и reject_rhsbl_* . Hашел следующее http://www.opennet.ru/openforum/vsluhforumID1/54053.html Цитирую. ======================== Вот, что я сделал: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unauth_pipelining, /*RBL ПЕРЕЧИСЛЕHHЫЕ HИЖЕ HАХОДЯТСЯ ИМЕЕHО ЗДЕСЬ, так как не дают ложного срабатывания, а если и дают, то тут виноваты сами админы, так как в этих RBL находятся серверы, работающие с явными техническими нарушениями в конфигурации различных сетевых сервисов*/ reject_rbl_client relays.ordb.org, reject_rbl_client smtp.dnsbl.sorbs.net, reject_rbl_client http.dnsbl.sorbs.net, reject_rbl_client socks.dnsbl.sorbs.net, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client dul.ru, # check_policy_service inet:127.0.0.1:10024, # /* В RBL которые перечислены ниже попадают почтовые серверы из-за пользователей: вирусы на компах пользователей и т.д. То есть в этих RBL частые ложные срабатывания.*/ reject_rhsbl_client blackhole.securitysage.com, reject_rhsbl_sender blackhole.securitysage.com, reject_rbl_client bl.spamcop.net, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org, Как это работает. 1. Проверяются RBL все, что выше check_policy_service, если клиент находится в этих RBL, то не страшно, письмо просто reject-ится с кодом 554. 2. Если через rbl первые прошли, попадаем на проверку check_policy_service, который отвечает или DEFFER_IF_REJECT (то бишь письмо задерживается, если оно попало в RBL ниже), или OK (когда проходит заданное время нахождения в greylist-e, то есть письмо через заданное время принимается, даже если оно находится в RBL ниже (у меня это через 12 часов). ======================== и далее поправка ======================== но в общем я свою проблему решил о том, чтобы писалась ошибка от RBL с описанием в каком RBL находится адрес, а не от greylist-а. Что я сделал: В smtpd_recipient_restrictions всё оставил как было, добавил только maps_rbl_reject_code = 454, и в исходниках greylist-a вместо DEFFER_IF_REJECT сделал ответ DUNNO, то есть разрешить дальнейшую проверку, а дальше как раз список RBL, теми RBL письмо отвергается с кодом 454 и описанием. ======================== Цитаты закончились. Почти то, что надо. Безусловных реджектов по результатам RBL не надо. Всех проблемных через greylist. И пусть rbl ругается как greylist без намека на блэклисты. Итого как это мне видится Грейлисту опцию --greylist-action=DUNNO maps_rbl_reject_code = 451 default_rbl_reply = "Policy restrictions, try later" smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, всякое прочее, check_policy_service inet:127.0.0.1:10024, reject_rbl_client relays.ordb.org, reject_rbl_client smtp.dnsbl.sorbs.net, reject_rbl_client http.dnsbl.sorbs.net, check_client_access regexp:/etc/postfix/permit_client_nots25r /etc/postfix/permit_client_nots25r от SATOH Kiyoshi /\.dip\.t-dialin\.net$/ WARN /\.dyn\.optonline\.net$/ WARN ...(other dynamic IP FQDN pattern(not match S25R pattern)) !/(^unknown$)|(^[^\.]*[0-9][^0-9\.]+[0-9])| (^[^\.]*[0-9]{5})|(^([^\.]+\.)?[0-9][^\.]*\.[^\.]+\..+\.[a-z])| (^[^\.]*[0-9]\.[^\.]*[0-9]-[0-9])| (^[^\.]*[0-9]\.[^\.]*[0-9]\.[^\.]+\..+\.)| (^(dhcp|dialup|ppp|adsl)[^\.]*[0-9])/ OK ...(This regexp is one line) /./ WARN В permit_client_nots25r заменить WARN на 451, OK на DUNNO. Похоже на правду? Hе промахнулся ли? Что подскажете? P.S. Hа практике предполагается, что все эти всякое прочее, check_policy_service inet:127.0.0.1:10024, reject_rbl_client relays.ordb.org, reject_rbl_client smtp.dnsbl.sorbs.net, reject_rbl_client http.dnsbl.sorbs.net, check_client_access regexp:/etc/postfix/permit_client_nots25r будут привинчены через smtpd_restriction_classes, и у smtpd_recipient_restrictions в конце reject. -- --- FIDOGATE 5.1.3ds * Origin: without commentaries (2:5054/1.128) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.unix/3317294664a9f.html, оценка из 5, голосов 10
|