ru.unix

 
 - RU.UNIX ----------------------------------------------------------------------
 From : Alexander Kalmykov                   2:5020/400     20 Feb 2007  20:20:02
 To : All
 Subject : Смягчить RBL, S25R и проч. через greylist под postfix.
 -------------------------------------------------------------------------------- 
 

 Привет.
 
 Посмотрел на 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.
 -- 
 --- ifmail v.2.15dev5.3
  * Origin: without commentaries (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор