Comments 24
Комплексный подход — самый правильный. Спасибо за статью.
Отдельно задам вопрос: «Эта же информация уходит вместе с почтовым отлупом на ту сторону провода. Вдруг кому пригодится для отладки.» — а если на той стороне спамерский сервер? У спамера тогда будет информация о том, в чём он провалился.
Отдельно задам вопрос: «Эта же информация уходит вместе с почтовым отлупом на ту сторону провода. Вдруг кому пригодится для отладки.» — а если на той стороне спамерский сервер? У спамера тогда будет информация о том, в чём он провалился.
Да, так и есть. Дело в том, даже один false positive стоит сотни спама, если задуматься о вреде для работы организации, использующей почту. Поэтому считаю, что так будет лучше в первую очередь для почтовых админов, которые не ленятся читать отлупы.
А в общем — нет никаких проблем писать информацию о недоставке только в локальный лог почтовика. Для этого можно поменять директиву message на log_message или на logwrite.
А в общем — нет никаких проблем писать информацию о недоставке только в локальный лог почтовика. Для этого можно поменять директиву message на log_message или на logwrite.
Поправьте меня если я неправ НО:
Здесь вы обявляете перемунную:
которая держится на протящении всего соединения acl_c (acl_connection) и чуть ниже уже пишете
Очень просто — счетчик обнуляется также и при передаче команды RSET, перезапускающей SMTP-сессию. Если этого не делать, то количество очков осталось бы прежним и к нему бы суммировались новые очки за те же самые проверки, произведенные до команды RSET.
А нельзя ли просто обявить єту переменную не ви виде acl_m (acl_message) и тогда она должна обнулятся при каждом новом письме поступившем на вход
Здесь вы обявляете перемунную:
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), поэтому для новой сессии переменная получает исходное значение в любом случае.
Имеется ввиду такой вариант событий:
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 (используется в основном 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 (идет вместе с экзимом), или перевод официальной документации на русский язык Алексеем Кеда (не знаю, склоняется ли фамилия, поэтому склонять не буду) на его сайте.
Поскольку статья про ACL экзима, то приведу команду для отладки ACL:
exim -bhc 1.1.1.1 эмулирует входящее соединение с IP 1.1.1.1
В man exim есть краткая информация по отладке разных секций конфига.
Чтобы узнать ещё больше, посмотрите файл spec.txt (идет вместе с экзимом), или перевод официальной документации на русский язык Алексеем Кеда (не знаю, склоняется ли фамилия, поэтому склонять не буду) на его сайте.
А что в этом нового, извините?
Из своего опыта не могу не заметить:
удобнее для понимания накидывать баллы из расчета что максимальное их количество 100. При чем в эти 100 должны входить и проверки текста письма, а занимать они должны не меньше 50
trusted_zones — странное допущение. В интернете все равны. Не бывает зон более спамных или менее. Более того вы сначала даете +90 за чумазость по домену-отправителю, а потом еще +20, если он использует легитимное HELO. Накиньте сюда еще пару оплошностей если mta использует на strict-RFC нотацию и всё — письмо в спаме.
dynamic_pools — опять же, неужели человек у себя дома не может поставить mta. Мелкий бизнес, человек в коммандировке и т.п вам не клиенты?.. Да, это повод, но здесь накидывается слишком много.
dnsbl.sorbs.net — неужели вы не сталкивались с этими пройдохами? Допустим не так давно у них в списках числилась вся белорусская AS-ка, просто так.
удобнее для понимания накидывать баллы из расчета что максимальное их количество 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.
Не совсем согласен по некоторым пунктам:
> 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'а.
Под 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 тысяч (хостинг).
У этой конфигурации теоретически запас прочности больше — например, срубаются письма из «левых» географических доменных зон просто по регекспам. В случае хостинга, понятное дело, такую фильтрацию использовать было нельзя.
При 2000 коннектов и выше начинался перегруз, сервер переходил на работу только по whitelist, а остальным отвечал 451 сразу при подключении.
За несколько минут он разгребал, что у него поднакопилось и опять открывал SMTP-доступ всем.
Нагрузка была 1-1,5 млн коннектов в сутки, ящиков — 7-8 тысяч (хостинг).
У этой конфигурации теоретически запас прочности больше — например, срубаются письма из «левых» географических доменных зон просто по регекспам. В случае хостинга, понятное дело, такую фильтрацию использовать было нельзя.
Дайте ссылку на rfc где сказанно что после RSET надо заново начинать с HELO.
Сбрасываются только sender/recipient
Сбрасываются только sender/recipient
Здесь производится callout (проверка существования ящика отправителя)Sender Callout считается abusive техникой. Если некий ботнет сгенерирует вам поток писем с подставными адресами другого домена, то ваш MTA завалит колаутами почтовый сервер того домена. Поэтому я проверяю только существование домена отправителя (не существование самого ящика).
Поэтому заворачиваем их в грейлист на 29 минут (интервал выбран с расчетом на второй прогон почтовой очереди MTA-отправителем)По-умолчанию postfix (и exim в debian'е) делает первую попытку повторной отправки через 15 минут. Публичные почтовые сервисы посылают повторно еще раньше.
>Если некий ботнет сгенерирует вам поток писем с подставными адресами другого домена, то ваш MTA завалит
>колаутами почтовый сервер того домена.
Да, тут тоже есть маленькая хитрость:
Чтобы таких лавин не происходило, ботнеты упаковываются в Blacklist (он, в основном, для этого и нужен). Фактически, каждый из узлов ботнета вряд ли сможет попытаться отправить более одного письма, после чего будет блокирован на неделю.
>По-умолчанию postfix (и exim в debian'е) делает первую попытку повторной отправки через 15 минут.
>Публичные почтовые сервисы посылают повторно еще раньше.
Первый прогон очереди обычно происходит через 15 минут, а через 30 минут наступает второй прогон. Это сделано против пробивания грейлиста спам-ботами (некоторые из них умеют делать повторную отправку через несколько минут и 300-секундные грейлисты таким образом пробиваются).
>колаутами почтовый сервер того домена.
Да, тут тоже есть маленькая хитрость:
Чтобы таких лавин не происходило, ботнеты упаковываются в Blacklist (он, в основном, для этого и нужен). Фактически, каждый из узлов ботнета вряд ли сможет попытаться отправить более одного письма, после чего будет блокирован на неделю.
>По-умолчанию postfix (и exim в debian'е) делает первую попытку повторной отправки через 15 минут.
>Публичные почтовые сервисы посылают повторно еще раньше.
Первый прогон очереди обычно происходит через 15 минут, а через 30 минут наступает второй прогон. Это сделано против пробивания грейлиста спам-ботами (некоторые из них умеют делать повторную отправку через несколько минут и 300-секундные грейлисты таким образом пробиваются).
После того, как лет семь назад перестал заниматься коммерческими сервисами почты (системы от 10K ящиков), удивляюсь — зачем строить такие системы, если есть Google Mail for Domains…
Товарищ автор, если вы ещё в сети, а расскажите как использовать DKIM для обеления, а? :)
А то у меня то ли лыжи не едут, толи ещё чего, но acl_smtp_email работает после всех проверок, хоть и до приёма data.
Поэтому особо отбелить, чтобы и не стать fail-релеем, и не городить окончательную фильтрацию по баллам внутри acl_smtp_dkim — не получится, как мне кажется :(
А то у меня то ли лыжи не едут, толи ещё чего, но acl_smtp_email работает после всех проверок, хоть и до приёма data.
Поэтому особо отбелить, чтобы и не стать fail-релеем, и не городить окончательную фильтрацию по баллам внутри acl_smtp_dkim — не получится, как мне кажется :(
Sign up to leave a comment.
Новая старая методика защиты от почтового спама на базе MTA Exim