Борьба со спамом средствами Postfix

В этой статье постараюсь изложить свой опыт по настройки MTA Postfix для максимальной фильтрации спама и нежелательных писем встроенными средствами и средствами модулей Postfix'а. Настройка Amavis, Spamassassin, Clam и т. п. отдельных средств фильтрации спама выходит за рамки данной статьи и я возможно напишу об этом позже.

Входные данные:

• сервер под управлением ОС Debian 7, 
• Postfix 2.9.x, 
• домен: example.com, 
• внешний IP - 222.222.222.222, 
• внутренняя сеть - 192.168.1.0/24, 192.168.2.0/24. 

Считаю, что постфикс у вас уже настроен в плане авторизации, почтовых ящиков и прочего хозяйства.

Основной файл, где настраивается фильтрация спама, это main.cf

Для начала укажем адреса доверенных сетей с префиксами через "," - для этих сетей большинство проверок работать не будут дабы не использовать лишние ресурсы:

mynetworks = 127.0.0.0/8, 192.168.1.0/24, 192.168.2.0/24

Далее следуют проверки HELO, т. к. многие спаммеры или пропускают команду SMTP HELO или посылают заведомо неверные данные.

smtpd_delay_reject = yes 
smtpd_helo_required = yes 
smtpd_helo_restrictions = permit_mynetworks, 
    permit_sasl_authenticated, 
    check_helo_access hash:/etc/postfix/helo_access, 
    reject_non_fqdn_hostname, 
    reject_invalid_hostname, 
    permit

1 - включаем проверки HELO и заодно совместимость с некоторыми клиентами

2 - сразу отклоняем письма от отправителей без HELO

3 - цепочка фильтрации HELO:

• разрешить доверенным сетям,
• разрешить авторизованным по sasl (если вы используете sasl)
• проверка хеш-таблицы, которая собержит черный/белый список HELO, в который вы вправе добавить заведомо доверенные или нежелательные домены/адреса, например:

smap.com REJECT SPAM!
some_other_spam.com REJECT SPAM!
234.234.234.234 REJECT Some spam IP

trusted_domain.com OK

example.com REJECT Fake!
222.222.222.222 REJECT Fake!

Последние 2 строчки добавлены т. к. со всех наших сетей доступ уже был разрешен с помощью mynetworks и, если спаммер выдает себя за нас, то тут его как раз и отфильтрует.

• далее происходит фильтрация заведомо неправильных доменов вроде “MAILSERVER” или “HOST@192.168!aol.com”
• если с HELO письма всё хорошо, то оно проходит в следующую цепочку фильтрации

Также можно добавить перед permit опцию reject_unknown_hostname, но использование ее спорно - она фильтрует письма от доменов, которые не могут быть отрезольвены с помощью DNS. С одной стороны хорошо, а с другой - многие валидные системы имеют проблемы с DNS и их письма будут тоже отклонены.

Протестировать действие этих правил без риска ложных срабатываний можно, вставив в цепочку (до permit, естественно) опцию warn_if_reject - Postfix не будет фильтровать письма, а только писать в лог.

Далее следует цепочка фильтрации по отправителю письма.

smtpd_sender_restrictions = 
    permit_mynetworks, 
    permit_sasl_authenticated, 
    check_sender_access regexp:/etc/postfix/sender_access, 
    reject_non_fqdn_sender, 
    reject_unknown_sender_domain, 
    permit

• вначале как и раньше - разрешаем "нашим" доступ
• проверяем, как и в предыдущем случае, хеш-таблицу с белым/черным списком и "отфутболиваем" отправителей из неправильных и неизвестных доменов
• пропускаем тех, у кого всё Ок с отправителем

Теперь письмо уже имеет достаточно большой шанс быть легитимным и, кстати, большинство спама уже должно быть отфильтровано. Остались наиболее "тяжелые" проверки. 

Далее следует проверка по получателю письма:

smtpd_recipient_restrictions =
    reject_unauth_pipelining,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain, 
    permit_mynetworks, 
    permit_sasl_authenticated, 
    reject_unauth_destination, 
    check_recipient_access regexp:/etc/postfix/recipient_access,
    check_policy_service inet:127.0.0.1:10023, 
    check_policy_service unix:private/policy-spf, 
    permit

• многие спаммеры посылают письма как можно быстрее сериями команд, не дожидаясь ответа - для фильтрации такого спама первая проверка
• далее мы фильтруем неправильные и неизвестные домены
• разрешаем "нашим"
• опция reject_unauth_destination возможно самая важная - без нее наш сервер станет т.н. open relay
• далее следует проверка по хешу блеклиста получателей - полезно добавлять туда даже локальных пользователей, если на их аккаунты сыпятся т. н. баунсы. Пример записи:

something@example.com REJECT This is not real account.

• далее идет проверка через внешний сервис т.н. грейлистинга - в данном случае - Postgrey.
• а также проверка Sender Policy Framework (SPF) - он них ниже.
• ну и, конечно же, пропуск далее валидных писем

Теперь последняя цепочка проверок:

smtpd_client_restrictions = 
     permit_mynetworks, 
     reject_rbl_client bl.spamcop.net, 
     reject_rbl_client cbl.abuseat.org, 
     permit

Здесь мы проверяем адреса отправителя в помощью сервисов черных списков. Дескредитированные IP-адреса, от которых идет спам, заносятся в эти списки. Перед использованием в своем конфиге нужно проверить, работают ли сервисы - иначе будет большая задержка приходящих писем.

Для использования Spamassassin и Amavis необходимо так же добавить строчку:

content_filter = amavis:[127.0.0.1]:10024

Но настройка этих демонов - это тема для отдельной статьи.

Теперь поподробнее о SPF и Greylisting

SPF позволяет владельцу домена указать в TXT-записи, соответствующей имени домена, специальным образом сформированную строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.

Агенты передачи почты, получающие почтовые сообщения, могут запрашивать SPF-информацию с помощью простого DNS-запроса, верифицируя таким образом сервер отправителя.

Пример SPF-данных в TXT-записи DNS:

example.org. IN TXT "v=spf1 +a +mx -all"

v= определяет используемую версию SPF. Далее следует перечисление механизмов верификации: в данном случае «a» разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org; «mx» разрешает прием писем, если отправляющий узел указан в одной из MX-записей для example.org. Строка завершается «-all» — указанием того, что сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать. Также может использоваться «~all» - в этом случае письмо, не прошедшее верификацию, не должно быть отклонено, но может быть изучено более тщательно (SoftFail).

Этой записи вполне может и не быть, но всё же.

Greylisting — способ автоматической блокировки спама, основанный на том, что «поведение» программного обеспечения, предназначенного для рассылки спама, отличается от поведения обычных серверов электронной почты. Еслипочтовый сервер получателя отказывается принять письмо и сообщает о «временной ошибке», сервер отправителя обязан позже повторить попытку. Спамерское программное обеспечение в таких случаях, обычно, не пытается этого делать.

Установить это хозяйство достаточно просто:

aptitude install postfix-policyd-spf-python postgrey

Затем необходимо добавить в main.cf постфикса, как написано выше:

check_policy_service inet:127.0.0.1:10023, check_policy_service unix:private/policy-spf,

в цепочку smtpd_recipient_restrictions (НО после reject_unauth_destination). Также необходимо добавить в этот файл (лучше в конец) опцию:

policy-spf_time_limit = 3600s

Еще в master.cf необходимо добавить следующее: 

policy-spf  unix  -       n       n       -       -       spawn

     user=nobody argv=/usr/bin/policyd-spf

Перезапускаем службы и смотрим в логи, как работает наша обновка.

Создать SPF-запись для своего домена можно с помощью мастера здесь:
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/default.aspx

Полезные ссылки:

http://www.postfix.org/postconf.5.html
http://www.freesoftwaremagazine.com/articles/focus_spam_postfix
https://help.ubuntu.com/community/Postfix/SPF