Pull to refresh

Comments 24

Комплексный подход — самый правильный. Спасибо за статью.

Отдельно задам вопрос: «Эта же информация уходит вместе с почтовым отлупом на ту сторону провода. Вдруг кому пригодится для отладки.» — а если на той стороне спамерский сервер? У спамера тогда будет информация о том, в чём он провалился.
Да, так и есть. Дело в том, даже один false positive стоит сотни спама, если задуматься о вреде для работы организации, использующей почту. Поэтому считаю, что так будет лучше в первую очередь для почтовых админов, которые не ленятся читать отлупы.

А в общем — нет никаких проблем писать информацию о недоставке только в локальный лог почтовика. Для этого можно поменять директиву message на log_message или на logwrite.
Поправьте меня если я неправ НО:
Здесь вы обявляете перемунную:
acl_check_helo:
warn set acl_c_spamscore = 0
[...]
accept

которая держится на протящении всего соединения acl_c (acl_connection) и чуть ниже уже пишете
Очень просто — счетчик обнуляется также и при передаче команды RSET, перезапускающей SMTP-сессию. Если этого не делать, то количество очков осталось бы прежним и к нему бы суммировались новые очки за те же самые проверки, произведенные до команды RSET.

А нельзя ли просто обявить єту переменную не ви виде acl_m (acl_message) и тогда она должна обнулятся при каждом новом письме поступившем на вход
При перезапуске сессии командой RSET переменные сохраняют свои значения, а access-list acl_smtp_connect не отрабатывает вообще (всё ведь происходит в рамках существующей сессии).
Имеется ввиду такой вариант событий:

220 — mail.hornsnhoofs.com
HELO mail.example.org
250 mail.hornsnhoofs.com Hello mail.example.org [192.168.0.1]
MAIL FROM:<user@example.org>
250 OK
RCPT TO:<uer@hornsnhoofs.com>
550-Message rejected. No such user here. Relaying denied.
RSET
250 Reset OK
HELO mail.example.org
250 mail.hornsnhoofs.com Hello mail.example.org [192.168.0.1]
Вот тут переменная обнуляется и счет идет по-новой.
MAIL FROM:<user@example.org>
250 OK
RCPT TO:<user@hornsnhoofs.com>
250 Accepted

В основном — так сделано для отладки работы, как я и указал в статье.

Новая сессия всегда обрабатывается новым процессом МТА (экзим использует fork), поэтому для новой сессии переменная получает исходное значение в любом случае.
Совпало, что Ваша статья про Exim, как раз вышла в свет, когда мне понадобилась =)
Не спец по exim (используется в основном postfix), но постораюсь внедрить советы в статье на одном почтовике как раз с Exim, так как отлуп спамеров по одному критерию реально «не айс».
Автор, подскажите как правильнее отлаживать правила Exim? Просто они у вас впечатляют и если их изменять и дополнять, то проверку работоспособности нужно как-то производить… понятно что всё обкатается на тестовом сервере… но может поделитесь опытом и дадите направление в плане debug правил Exim?
exim -bd -d+all а дальше анализировать вывод
У экзима очень широкие возможности для дебага.
Поскольку статья про ACL экзима, то приведу команду для отладки ACL:

exim -bhc 1.1.1.1 эмулирует входящее соединение с IP 1.1.1.1

В man exim есть краткая информация по отладке разных секций конфига.

Чтобы узнать ещё больше, посмотрите файл spec.txt (идет вместе с экзимом), или перевод официальной документации на русский язык Алексеем Кеда (не знаю, склоняется ли фамилия, поэтому склонять не буду) на его сайте.
огромное спасибо… прочту и на тестовом сервере обкатаю

1099511627776 спасибо тоже
Я и не претендовал на новизну:

Данная методика существует давно, мне встречались разные реализации этой идеи разными специалистами, а эта вариация в более кратком виде была описана мною еще 5 лет назад.
Из своего опыта не могу не заметить:
удобнее для понимания накидывать баллы из расчета что максимальное их количество 100. При чем в эти 100 должны входить и проверки текста письма, а занимать они должны не меньше 50

trusted_zones — странное допущение. В интернете все равны. Не бывает зон более спамных или менее. Более того вы сначала даете +90 за чумазость по домену-отправителю, а потом еще +20, если он использует легитимное HELO. Накиньте сюда еще пару оплошностей если mta использует на strict-RFC нотацию и всё — письмо в спаме.

dynamic_pools — опять же, неужели человек у себя дома не может поставить mta. Мелкий бизнес, человек в коммандировке и т.п вам не клиенты?.. Да, это повод, но здесь накидывается слишком много.

dnsbl.sorbs.net — неужели вы не сталкивались с этими пройдохами? Допустим не так давно у них в списках числилась вся белорусская AS-ка, просто так.
Спасибо за конструктивную критику.

Не совсем согласен по некоторым пунктам:
> trusted_zones — странное допущение. В интернете все равны.
Для компании, которая работает с клиентами, например, по территории МСК и/или области странно получать письма из Мексики, Уругвая или Южной Кореи. А +90 не встречается в конфигурации вообще нигде, посмотрите внимательно.

> dynamic_pools — опять же, неужели человек у себя дома не может поставить mta.
Может, конечно, только вот проблема в том, что адрес — dynamic, т.е. каждый раз — новый. С таким адресом сложно принимать входящую почту на МТА. А bind IP еще и в конфигурации МТА надо прописывать.
А еще сессия, как на всю страну показал один нервный ADSL-клиент — имеет разрывы. А еще встречаются блокировки трафика провайдерами. И еще много чего, что не лучшим образом сказывается на работе «домашнего почтовика».
Куда чаще (в действительности — очень сильно чаще) туда встает какой-нибудь зловред. Приходит, встает, и начинает писать письма всем-всем-всем. Такой вот общительный :-)

>dnsbl.sorbs.net — неужели вы не сталкивались с этими пройдохами?
Сталкивался со spamhaus, тоже те ещё отморозки. Потому и надо попасть одновременно в два блэклиста, чтобы получить 550 Deny.
На какой поток писем расчитана данная конфигурация имея ввиду запросы к ldap/SQL, задержки в сессии и callback? Какого размера должен быть ботнет чтобы поставить exim на колени на 16 ядерном проце с 16 гигами оперативы?
Думаю, при такой конфигурации сервера, он легко вытянет тысячи 2-3 одновременных соединений (в общем ~ 2-3 млн соединений в сутки).

Под highload я бы выбрал чуть другую тактику — можно использовать условия с переменной $load_average, которые отключали бы тяжеловесные операции (тот же callout или delay) при высокой нагрузке и завел бы в main-секции конфига примерно такие записи:

smtp_load_reserve = 16.0
smtp_reserve_hosts = +whitelisted_hosts: +accept_hosts

Еще неплохо было бы вынести СУБД на отдельный сервер в случае highload'а.
Думаю и трети не выдержит. Smtp сессии это еще и трафик, и tcp стэк да и форки недешевы нынче. Какие боевые показатели этой конфигурации?
Два сервера с четырьмя (в количестве процов могу ошибиться, это в 2005-2006 году было) Opteron 242 (один сервер под exim, второй под mysql) и 8Гб RAM держали 1500-2000 SMTP-коннектов единовременно, но экзим при этом отслеживал нагрузку, как я указал выше (loadaverage).
При 2000 коннектов и выше начинался перегруз, сервер переходил на работу только по whitelist, а остальным отвечал 451 сразу при подключении.
За несколько минут он разгребал, что у него поднакопилось и опять открывал SMTP-доступ всем.
Нагрузка была 1-1,5 млн коннектов в сутки, ящиков — 7-8 тысяч (хостинг).

У этой конфигурации теоретически запас прочности больше — например, срубаются письма из «левых» географических доменных зон просто по регекспам. В случае хостинга, понятное дело, такую фильтрацию использовать было нельзя.
Дайте ссылку на rfc где сказанно что после RSET надо заново начинать с HELO.
Сбрасываются только sender/recipient
Ваша правда.
Впрочем, с HELO тоже можно начинать, это ошибкой не будет. Поправил acl в статье, чтобы счетчик обнулялся при MAIL FROM. Так правильнее по RFC.
Здесь производится callout (проверка существования ящика отправителя)
Sender Callout считается abusive техникой. Если некий ботнет сгенерирует вам поток писем с подставными адресами другого домена, то ваш MTA завалит колаутами почтовый сервер того домена. Поэтому я проверяю только существование домена отправителя (не существование самого ящика).

Поэтому заворачиваем их в грейлист на 29 минут (интервал выбран с расчетом на второй прогон почтовой очереди MTA-отправителем)
По-умолчанию postfix (и exim в debian'е) делает первую попытку повторной отправки через 15 минут. Публичные почтовые сервисы посылают повторно еще раньше.
>Если некий ботнет сгенерирует вам поток писем с подставными адресами другого домена, то ваш MTA завалит
>колаутами почтовый сервер того домена.
Да, тут тоже есть маленькая хитрость:
Чтобы таких лавин не происходило, ботнеты упаковываются в Blacklist (он, в основном, для этого и нужен). Фактически, каждый из узлов ботнета вряд ли сможет попытаться отправить более одного письма, после чего будет блокирован на неделю.

>По-умолчанию postfix (и exim в debian'е) делает первую попытку повторной отправки через 15 минут.
>Публичные почтовые сервисы посылают повторно еще раньше.
Первый прогон очереди обычно происходит через 15 минут, а через 30 минут наступает второй прогон. Это сделано против пробивания грейлиста спам-ботами (некоторые из них умеют делать повторную отправку через несколько минут и 300-секундные грейлисты таким образом пробиваются).
После того, как лет семь назад перестал заниматься коммерческими сервисами почты (системы от 10K ящиков), удивляюсь — зачем строить такие системы, если есть Google Mail for Domains…
Думаю не все готовы доверять черному ящику корпорации добра которая не несет никакой ответственности но при этом обязана сотрудничать с разными органами
Товарищ автор, если вы ещё в сети, а расскажите как использовать DKIM для обеления, а? :)
А то у меня то ли лыжи не едут, толи ещё чего, но acl_smtp_email работает после всех проверок, хоть и до приёма data.
Поэтому особо отбелить, чтобы и не стать fail-релеем, и не городить окончательную фильтрацию по баллам внутри acl_smtp_dkim — не получится, как мне кажется :(
Only those users with full accounts are able to leave comments. Log in, please.