Первое и главное, на что нужно смотреть в конфиге по-умолчанию - это для кого и от кого принимается почта. Основные опции, которые **нужно** посмотреть:
- ``mydestination`` -- домен или конкретное имя этого хоста. Ничего лишнего. Если вы используете виртуальные домены - оставьте только localhost.
- ``mynetworks[_style]`` -- ни в коем случае не 0.0.0.0/0, юзеры из этих сетей получают больше прав "по умолчанию", в частности доступ к использованию пересылки почты на внешние адреса.
- ``relay_domains`` -- пересылать почту для этих доменов, по умолчанию - то же самое что и mydestination
- ``virtual_mailbox_domains`` -- то же самое что и mydestination, но для виртуальных доменов. см. ``VIRTUAL_README`` в документации, чтобы понять чем они отличаются от "обычных".
Полный список опций с их описанием можно посмотреть в `postconf(5)`.
Далее, начинаем рубить спамеров ещё "на подлёте":
HELO/EHLO
----------
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
permit
Ограничения:
* ``reject_non_fqdn_helo_hostname`` -- требовать, чтобы в HELO/EHLO было что-то похожее на hostname
* ``reject_unknown_helo_hostname`` -- ...и этот хостнейм должен ресолвится по dns'у в ipv4/v6 адрес
Первое помогает от совсем тупых ботов, второе - частично от vps'ок с ломанным wordpress'ом.
* ``reject_unauth_pipelining`` -- сбрасывать сессию, если клиент пытается отправлять команды не дождавшись ответа на предыдущую команду
* ``reject_unknown_client_hostname`` -- сбрасывать сессию, если не совпадают записи IP -> DNS/PTR или DNS/A -> IP для того хостнейма, что указан в EHLO
см также. ``reject_unknown_reverse_client_hostname``, более слабую альтернативу этой проверки.
* ``reject_multi_recipient_bounce`` -- сбрасывать сессию, если не указан отправитель и указано несколько получателей.
* ``check_reverse_client_hostname_access`` -- позволяет дать отлуп заведомо левым хостам на основе ненастроенной PTR записи
Помогает от биомассы с завирусованным виндузом, дырявых CMS на VPS'ках и просто кулхацкеров на диалапе. Примерное содержимое файлика:
/.*(dynamic|broadband|\.dyn\.|\.ddns|\.vps\.).*/i 421 Dynamic hostname. Fix it and try again.
/.*(\.adsl|\.cdma\.|\.pptp|\.pppoe|\.cable).*/ 421 Dynamic hostname. Fix it and try again.
/.*(\d+[-.]){4}.*/ 421 Dynamic hostname. Fix it and try again.
Исключения:
* ``check_client_access`` -- позволяет вводить исключения для произвольных хостов.
* ``reject_non_fqdn_sender`` -- в `MAIL FROM:` должно быть что-то похожее на email
* ``reject_unknown_sender_domain`` -- проверить через dns, что домен отправителя действительно существует
Также, можете задействовать это:
* ``reject_unverified_sender`` -- сбросить сессию, если обратное письмо отправителю заведомо не будет доставлено
Это достаточно хардкорная опция, и должна применяться ограниченно. Суть такова: наш сервер соединяется с доменом отправителя и пытается отправить ему письмо, сбрасывая отправку в последний момент. Можно легко нарваться на тот же кривонастроенный fail2ban, и почта к этому домену перестанет ходить вовсе. Кроме того, эта опция вносит ощутимую задержку в доставку письма - до 20 секунд.
* ``reject_non_fqdn_recipient`` -- в `RCPT TO:` должно быть что-то похожее на email
* ``reject_unauth_destination`` -- "у нас нет такого юзера"/"это не наш домен"
* ``check_policy_service`` -- проверять SPF, если он есть у домена отправителя
* задержка в конце - добавлена для противодействию перебору адресов
Внешние средства
-----------------
Средства самого постфикса - это хорошо, но явно недостаточно. Я могу выделить 2 категории внешних средств, работающих со входящей почтой.
Первая из них - средства, работающие **до** принятия письма к доставке. (Перечислены только основные и широко используемые)
* fail2ban -- бан особо назойливых ботов, срабатывание настраивается на множественные сбои авторизации, "relay denied" и "no such recipient"
* dnsbl -- проверка по dns'у ip-адресов клиента. Опция достаточно спорная, листы могут просто не успевать обновляться.
* SPF -- сейчас уже "must have". Требует достаточно мало ресурсов, очень эффективна для доменов отправителя с политикой "-all", в крайнем случае "~all" поможет спамфильтру. *Важно:* следует использовать только reject'ы от этой проверки. См [wide-mask vulnerability](https://en.wikipedia.org/wiki/Sender_Policy_Framework#Wide-mask_vulnerability)
* DKIM -- в какой-то мере аналог SPF, но применяется для проверки отправителя/получателя вместо ip-адресов. Тоже - использовать только reject'ы.
* postscreen -- специализированный фаервол для postfix'а, расширяет возможности встроенных проверок
Вторая категория - средства, работающие над фильтрацией нежелательной почты, уже принятой к доставке.
* весь спектр байесовских спам-фильтров (dspam, spamasassin, и что полегче: bogofilter, crm114, и т.д.)
* антивирусы
* DCC, razor и прочие контент-блэклисты.
* обратная связь от юзера со спамфильтром
На последнем пункте стоит остановиться отдельно. Использование такой связи не должно быть сложнее "переслать это письмо"/"переместить в Спам", иначе оно просто не будет использоваться юзерами. Первый вариант, с пересылкой - реализуется на postfix'е отдельным транспортом или условием в procmail'е, второй - через dovecot или что вашем конкретном случае отдаёт юзеру его почту.
Раскладывание почты по INBOX/Spam реализуется на procmail'е или том же dovecot'е (плагин lda), после прогона по всем спамфильтрам/антивирусам.
Отдельно подчёркиваю, что средства второй категории не должны слать ничего наружу, и крайне неохотно - админу почтовой системы. Первый случай может использоваться для спама через bounce, второй - для DOS атаки.
