В postfix есть возможность указать ограничение reject_sender_login_mismatch, при использовании которого производится проверка в таблице smtpd_sender_login_maps соответствия логина и MAIL FROM. Но тут возникает другой момент – для тысяч почтовых ящиков генерировать такую таблицу можно, но это потребует напильника в postfixadmin, который используется для управления аккаунтами клиентов. Немного посоображав, была реализована следующая грубая, но работающая схема с помощью mysql maps: описываем таблицу в main.cf:

[text]smtpd_sender_login_maps         = mysql:/usr/local/etc/postfix/sql/mysql_authentificated_users.cf[/text]

Сам mysql_authentificated_users.cf прост до безобразия:

[text]user = mysql_username
password = mysql_password
hosts = database_host
dbname = database_name
query          = SELECT ‘%s’

[/text]

Не забываем в main.cf указать, чтобы те, кто используют несовпадающий envelope-from, получали reject:

[text]smtpd_sender_restrictions =
reject_authenticated_sender_login_mismatch
permit

[/text]

Вот такая история из цикла “неэлегантно, но практично”

Как показал опыт, на больших объемах почты очень сложно бороться с помощью контестной фильтрации – тот же spamd или любая его реинкарнация укладывает пару-тройку некислых машинок с кучей памяти. Более производительный и перспективный dspam – не панацея, т.к. очень сложно объяснить пользователям, знающим две кнопки “Получить почту” и “Оправить почту”, как пользоваться фильтром. Нужно было решение, которое, с одной стороны, позволит уйти из “гонки вооружений”  (наращивания количества машин) и оставить уровень проходящего спама на нераздражающем уровне (читай – уровне, когда твой Thunderbird сам своими силами пометит спам и тихонечько отложит его в отдельную папку).

Еще не все вылизано до конца, но можно с уверенностью сказать, что наиболее действенным оказались следующие моменты:

• мы не принимаем сообщения от хостов, которые не могут нормально представиться в HELO/EHLO.
• мы не принимаем сообщения с динамических блоков – как по маскам, так и по базе DUL.RU
• и самое действенное – динамический blacklist (он не сильно black – мы выставляем 4xx, так что это скорее “серый” список) для тех хостов, которые пытаются засунуть большое количество писем одновременно.

Как показал опыт, в нашем случае ограничение в 30 одновременных коннектов вполне достаточно. Так вот, если удаленный хост пытается превысить этот порог на протяжении определенного времени – он попадает в “серый” список на несколько часов.Что самое интересное – за пару недель после реализации этой схемы мы не отметили ни одной жалобы. А уровень спама, как говорят, драматически снизился. И спать можно спокойнее – даже если клиент поймает трояна, его рассылка не будет массовой, т.к. он будет в “сером” списке очень быстро.

Доволен. Работает!