приветствую
продолжаю писать о нововведениях...
итак, начата реализация сабжа.
для включения использования грейлистинга в опциональном режиме
необходимо использовать значение OPTIONAL для переменной confGREYLIST_DBM
btw, для использования режима обучения введено значение LEARN для
переменной confGREYLIST_DBM (ранее для включения режима обучения
необходимо было обнулять значение переменной confGREYLIST_DBM_BLOCKED),
а для режима блокирования только первого письма введено значение
BLOCK_FIRST_ONLY (ранее для включения режима блокирования только первого
письма необходимо было присвоить отрицательное значение переменной
confGREYLIST_DBM_BLOCKED)
но вернемся к сабжу...
количество баллов, которое должно набрать письмо для применения к нему
серых списков, указывается в переменной
confGREYLIST_DBM_BLOCKED_OPTIONAL. значением по умолчанию является 10:
define(`confGREYLIST_DBM_BLOCKED_OPTIONAL', `10')dnl
теперь о критериях, по которым будет приниматься решение о применении
грейлистинга.
для применения грейлистинга на основании количества цифр в домене адреса
отправителя, PTR заиси хоста отправителя и helo необходимо в значении
переменной confCHECK_DIGITS указать GREYLIST:XX, где XX - количество
баллов. пример:
define(`confCHECK_DIGITS', `GREYLIST:7')dnl
для применения грейлистинга на основании отсутствия PTR записи рилея в
реверсной зоне DNS необходимо в значении переменной
confCHECK_RELAY_RESOLVE указать GREYLIST:XX, где XX - количество баллов.
значение GREYLIST:XX можно использовать совместно со значением RCPT.
значение GREYLIST:XX несовместимо со значением MAIL.
пример:
define(`confCHECK_RELAY_RESOLVE', `RCPT GREYLIST:12')dnl
для применения грейлистинга на основании несоответствия записей рилея в
прямой и реверсной зонах DNS необходимо в значении переменной
confCHECK_RELAY_FORGED указать GREYLIST:XX, где XX - количество баллов.
пример:
define(`confCHECK_RELAY_FORGED', `GREYLIST:6')dnl
для применения грейлистинга на основании наличия записи о домене
отправителя в RFC Ignorant Lists необходимо в значении переменной,
соответствующей искомому списку, указать GREYLIST:XX, где XX -
количество баллов.
пример:
define(`confCHECK_RFC_IGNORANT_ABUSE', `GREYLIST:6')dnl
define(`confCHECK_RFC_IGNORANT_POSTMASTER', `GREYLIST:6')dnl
define(`confCHECK_RFC_IGNORANT_DSN', `GREYLIST:6')dnl
define(`confCHECK_RFC_IGNORANT_BOGUSMX', `GREYLIST:10')dnl
следует быть осторожными с RFC Ignorant Lists. дело в том, что если
залистена зона, в которой находится проверяемый домен, то он тоже
считается залистенным.
например, зона kiev.ua залистена в abuse.rfc-ignorant.org и
postmaster.rfc-ignorant.org:
http://www.rfc-ignorant.org/tools/lookup.php?domain=kiev.ua
хотя сейчас в обоих листах домен числится залистенным с 06.10.2005,
буквально несколько дней назад домен числился залистенным только в
abuse.rfc-ignorant.org
самое стремное то, что адреса abuse и postmaster таки существуют в
домене kiev.ua (по крайней мере, 5xx на этапе rcpt to best MX домена
kiev.ua не возвращает)
ну и теперь получается, что и bsd.falbi.kiev.ua, на котором тестируются
изменения в паровозе, тоже считается залистенным, хотя в нем всю жизнь
существовали адреса abuse и postmaster.
но вернемся к сабжу.
в ближайшее время я планирую реализовать опциональный грейлистинг на
основании данных DNSBL'ей, принадлежности A записи рилея отправителя к
списку хостов/сетей, PTR записи рилея к списку доменных зон, на
основании времени дня и дня недели, типа на выходных и ночью грейлистить
всех нафиг ;-)
--
Best wishes Victor Ustugov mailto:victor на corvax.kiev.ua
public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc
ICQ UIN: 77186900, 32418694 nic-handle: CRV2-RIPE, CRV-UANIC