Greylist (серый список) достаточно эффективное средство для борьбы со спамом. Метод основан на том, что когда письмо приходит на почтовый сервер, сервер его не принимает а выдает предупреждение о временной недоступности, а координаты отправителя заносит в специальный список (базу данных). Если почтовый сервер отправителя настроен правильно, то в самое ближайшее время произойдет вторая попытка отправить это-же письмо, которое на этот раз обработается нашим почтовым сервером. Информация о том принять или отклонить письмо берется из базы временных списков. Первый раз отклоняем, если видим что второй раз приходит это же письмо, то принимаем.
По моему опыту 50-70% спамерского ПО обычно работает только на 1 пробу доставки, так что этим методом можно спокойно в 2 раза отсечь нежелательную почту.
Недостатки технологии greylist
- Увеличивается время доставки писем, иногда это время существенно, все зависит от настроек почтовых серверов отправителей
- Если почтовый сервер отправителя настроен неправильно он не будет делать попытки доставить письмо повторно. Увы, такие случаи у меня были, но очень редко.
Как выход из этих недостатков – добавлять домены или адреса надежных отправителей в белый список. Тогда письма будут приходить мгновенно, без всяких проверок базы данных и очередей.
Milter-greylist является наиболее распространенной системой серых списоков, работающей с такими почтовыми MTA как sendmail и postfix.
Установка milter-greylist
В Ubuntu (Debian) выполняется команда
aptitude install milter-greylist
Конфигурационный файл настройки greylist будет лежать в папке /etc/milter-greylist/greylist.conf, а чтобы включить пакет в автозагрузку при старте ОС требуется подредактировать файл /etc/default/milter-greylist
Для тех, кто хочет изучить методы установки для sendmail или postfix лучшим вариантом будет скачать исходники программы с официального сайта пакет и прочитать README.
Настройка конфигурации milter-greylist
Вся настройка milter-greylist сводится к правке одного файла /etc/milter-greylist/greylist.conf. Ниже я привел куски моего файла конфигурации с комментариями
#куда пишем pid и socket файлы
pidfile "/var/run/milter-greylist/milter-greylist.pid"
socket "/var/run/milter-greylist/milter-greylist.sock"
#где храним базу данных
dumpfile "/var/db/milter-greylist/greylist.db"
#от какого пользователя работает milter-greylist
user "smmsp"
# Do not tell spammer how long they have to wait
quiet
#место и формат лог файла milter-greylist
stat ">>/var/log/milter-greylist.log" "%T{%T} %i:%f:%r:%S\n"
# Мои доверенные сети
list "my network" addr { 127.0.0.1/8 192.168.0.0/24 }
#дефолтный пример доверенных ip
list "broken mta" addr { \
12.5.136.141/32 \ # Southwest Airlines (unique sender)
12.5.136.142/32 \ # Southwest Airlines
217.158.50.178/32 \ # AXKit mailing list (unique sender)
}
# Серый список нежелательных ip
list "spammers" rcpt { \
24.216.127.232/32 \
190.50.59.211/32 \
210.211.189.11/32 \
}
# Белый список адресов и доменов. Точки в адресах доменов
#лучше экранировать "\"
list "white users" from { \
info@yrw.ru \
/.*@vmware\.com/ \
/.*@*\.vmware\.com/ \
/.*@*\.su/ \
}
# Выставляем правила белых, серых списков
acl whitelist list "my network"
acl whitelist list "broken mta"
acl whitelist list "white users"
acl blacklist list "spammers"
#задаем дефолтную задержку писем в 5мин, а очистку
#списков в 1 день.
#Если письмо повторно пришло и между письмами было больше
#5 мин, то пропускаем, а если прошел 1 день и ничего не
#пришло повторно, то удаляем из базы списков. Есть вероятность,
#что если удаленный сервер отсылает повтор письма >1 дня, то
# мы его никогда не увидим
acl greylist default delay 5m autowhite 1d
Еще в конфиг можно добавить тех, кому нужен спам 🙂 Например на какой-нибудь ваш почтовый ящик для каких-нибудь экспериментов над спамом. В этом случае никакие письма на указанных пользователей задерживаться не будут..
list "my spam" rcpt { \
spam@mydomain.ru \
}
acl whitelist list "my spam"
Про тонкий тюнинг greylist.conf можно всегда узнать командой man greylist.conf
Настройка МТА (sendmail)
Конфиг настроили, теперь обеспечим связку работы системы milter-greylist с нашим почтовым агентом. У меня везде на серверах стоит sendmail, так что покажу на этой программе.
В свой конфигурационный sendmail.mc заносим строки
INPUT_MAIL_FILTER(`greylist',
`S=local:/var/milter-greylist/milter-greylist.sock')
define(`confMILTER_MACROS_CONNECT', `j, {if_addr}')
define(`confMILTER_MACROS_HELO', `{verify}, {cert_subject}')
define(`confMILTER_MACROS_ENVFROM', `i, {auth_authen}')
define(`confMILTER_MACROS_ENVRCPT', `{greylist}')
Обновляем основной конфиг sendmail.cf и перезапускаем sendmail. На всякий случай наш старый cf файл бэкапим.
#m4 sendmail.mc > sendmail.cf
#/etc/init.d/sendmail restart
Запуск и отладка milter-greylist
А теперь можно и запускать milter-greylist. В лог файле /var/log/milter-greylist.log при нормальной работе greylist должны появиться строки о запрете или пропуске сообщений
22:17:44 95.180.34.96:processioncq5@ram-bytes.com:1535@mydomain.ru:tempfail
22:17:51 90.156.145.94:filin@dhspb.ru:kuzina@mydomain.ru:accept
А в log файле maillog.log появятся строки об отвергнутых письмах
Nov 9 22:21:50 mail sm-mta[7865]: oA9JLoKs007865: \
Milter: to=<user@mydomain.ru>, reject=451 4.7.1 Greylisting in action, please come back later
Если у вас спама очень много, и лог файл milter-greylist буквально пухнет на глазах рекомендую написать скриптик ротации файла базы данных greylist.db и перезапуска программы после ротации. Это не совсем правильно, но эта процедура избавила меня от зависаний первых версий программы при большом потоке спама. Но это надо смотреть по ситуации, вполне возможно, что эти вопросы уже решены в новых версиях.
