Pull to refresh

Comments 72

у меня стойкое ощущение, что я вижу этот топик в 5-й раз
В данном случае могу сказать, что изучая почтовые системы и внедряя их в различных компаниях мне пришлось перелопатить достаточное количество публикаций и топиков в интернете, чтобы вычленить реальную информацию. Также я старался ее протестировать и иногда полученная информация была неверна. Я согласен с вами, что вы, возможно, встречали похожие статьи в интернете, но мне кажется, что именно такую — нет.
Гм… а поясните зачем вам проверка по rbl на моменте проверки получателя, а еще не на стадии коннекта — smtpd_client_restrictions?
Смуту вносит значение параметра «smtpd_delay_reject = yes» по умолчанию в Postfix. Так что все работает, даже если все запихнуть в smtpd_recipient_restrictions, но идеологически верно, конечно, проверку по rbl писать в smtpd_client_restrictions. Возможно, даже, с «smtpd_delay_reject = yes» есть какие-то различия в smtpd_*_restrictions, может кто-то знает хорошо Postfix и откомментирует? :)
на сайте постфикса там есть где-то мануал где рассказывается как на каких стадиях что проверяется, и вот эти ограничения как раз настраивают проверки :)
Есть мнение, что некоторые сервера надо принимать, даже если они в rbl. Например, клиент, который лезет отправить через наш сервер почту, обращается из сети, которая в rbl или в dul (что логично — они же у провайдера в dynamic range), а аутентифицикация сильно позже. Он и не отправит ничего.
Затем и нужен delay reject. Если где-то дальше в правилах пускают авторизированных пользователей, то запрет не будет работать.
Потому что иногда вам нужно от каких-то серверов получить почту. Ведь никто не застрахован от попадания в RBL.
permit_sasl_authenticated никакого отношения не имеет к SSL. параметр означет, что постфикс должен принимать почту от авторизовавшихся через SASL юзеров.

с проверкой обратной DNS никогда не парился.

по моему скромному опыту наиболее эффективная защита — отсекание всех динамических IP по маске, грейлистинг, проверка по блэклистам.

до собственно антиспама доходит примерно 1% плохих писем в итоге. забавно, в статье кстати про собственно антиспам ни слова нет :))
«permit_sasl_authenticated никакого отношения не имеет к SSL» — косвенно имеет! Если вы включаете строку permit_sasl_authenticated в конфиг и не настраиваете почтовый сервер на работу с SSL и TLS, то все ваши логины и пароли через SASL пойдут в открытую. Поэтому не путайте пожалуйста людей.
«с проверкой обратной DNS никогда не парился» — что вы имеете в виду? Вы не проверяете PTR записи? Зря…
«отсекание всех динамических IP по маске, грейлистинг, проверка по блэклистам» — а я разве не описал грейлистинг и блэклисты?
«про собственно антиспам ни слова нет» — у меня настроен spamassassin, но только в режиме не навреди (факстически не работает). Это очень серьезная программа и с ней нужно быть очень внимательным иначе можно зарубить всю почту. Я его держу на самый крайний случай, когда вышеописанные действия перестанут помогать.
спамассассин — великая программа, очень гибкая, если с ней разобраться «до просветления» — потерь полезной почты можно практически избежать (всегда можно из карантина письмо вынуть на крайний случай)
извините, но людей в данном случае путаете вы: «Параметр разрешающий прием почты через SSL» в отношении permit_sasl_authenticated — это чушь. Как там у вас настроен SASL — это уже ваше личное дело. Еще раз повторяю — permit_sasl_authenticated говорит только о том, что нужно пускать авторизовавшихся через SASL юзеров.
Ну, хорошо. Я немного перефразировал, чтобы было правильней. Но, надеюсь, вы не будете возражать, что permit_sasl_authenticated без настроенного SSL и TLS — очень небезопасное решение…
Небезопасное только если есть вероятность сниффа. Поскольку речь в статье речь идет о корпоративной почте, то сервер стоит в DMZ, и снифать трафик некому. Ну а если в самой локалке завелся любитель чужих паролей — с этим вы ничего не сделаете, с такого рода проблемой нужно бороться не внедрением SSL, а административными мерами.
и потом, вы хотите сказать, что без permit_sasl_authenticated, но с SSL/TLS — безопаснее?
Речь идет как раз о тех пользователях, которые снаружи вашей сети.
я буду возражать: как раз какой-нибудь SASL DIGEST-MD5 без TLS вполне безопасен с точки зрения бесполезности перехвата паролей.
>> у меня настроен spamassassin, но только в режиме не навреди (факстически не работает). Это очень серьезная программа и с ней нужно быть очень внимательным иначе можно зарубить всю почту. Я его держу на самый крайний случай, когда вышеописанные действия перестанут помогать.

Очень напрасно. Правда его правильная настройка отнимает большое кол-во времени, но мой личный результат превзошел все ожидания. После кропотливых проверок и выверок правил, а также упорной тренировки байес фильтра, были выведены золотые правила, которые допускали 0,001 % вероятности блокировки «правильного» письма и около 99 % блокировки неправильного письма. В условиях 1000 спам писем в день, это действительно очень хороший результат.
Причем, все это происходило на stand-alone сервере, на котором крутилось 15-20 активных доменов.
Всесто postgrey лучше использовать policyd. Он позволяет существенно больше и есть отбивалка по HELO.
Если я не ошибаюсь policyd хранит информацию в БД, типа mySQL, Postgres или SQLite 3. В случае же postgrey — база данных не нужна. Если не хочется заморачиваться с БД, то postgrey выгодней.
Если не требуются возможности policyd то да. Хотя вот мне сильно интересно как вы будете останавливать активную рассылку вирусом изнутри сети.
для этого существует антивирус.
Пока у антивируса появятся сигнатуры ваш домен заблокируют ваши же любимые dnsbl листы )))
У вас такое было? На моем опыте не было.
Напрасно вы ориентируетесь только на случаи из собственной практики. Описанный allan_sundry пример достаточно вероятен.
SNMP-trap на определенное (подозрительное) значение инициированных smtp-сессий?
Нет. Там просто можно указать сколько писем может пользователь отправить в еденицу времени.
А по производительности он как на больших нагрузках? Мне кажется что каждый раз делать проверку sql-запросом будет намного накладнее чем в key-value базе.
Ещё кстати есть SQLgrey — тоже аналогичная policyd штука.

Сейчас вот настраивают сервер и не знаю что выбрать — postgrey, policyd, SQLgrey, в рунете и буржунете сравнений этих демонов вообще никаких не нашёл ;(

Кто уже анализировал — может опишите у кого какие преимущества и недостатки?

Кстати, есть ещё policyd-weight — но это вроде уже совсем другое…
А по производительности он как на больших нагрузках? Мне кажется что каждый раз делать проверку sql-запросом будет намного накладнее чем в key-value базе.

Нормально. Опять же вы забываете что база у вас там будет небольшая и будет постоянно в памяти, как и собственно закешируется сам sql запрос.

policyd последний на perl но на производительность практически не сказывается, умеет много чего хотя документация достаточно заморочная.
Ну как небольшая, ассортимент IP-адресов в инете немалый ;) Сейчас у меня настроена блокировка через fail2ban (если с ip 20 раз подряд пытаются отправить а наш сервер его всё отсылает назад с ошибкой, то через iptables прописываю ему drop all на 12 часов), так вот там бывает под 1000 ип-шников накапливается.

Да и попытки заслать спам идут постоянно в очень больших количествах, так что по нагрузке на проц тоже я думаю заметно будет — разница между SQL-запросом и nosql-запросом значительная, судя по статьям.

И что Вы порекомедуете тогда из этих оставшихся вариантов — policyd или sqlgrey?

Кстати, если под рукой есть мануал по их настройке какой — кинете может ссылкой?
Ну как небольшая, ассортимент IP-адресов в инете немалый

К вам весь интернет сразу ломиться не будет.

Да и попытки заслать спам идут постоянно в очень больших количествах, так что по нагрузке на проц тоже я думаю заметно будет — разница между SQL-запросом и nosql-запросом значительная, судя по статьям.

Тут раз уже про это говорили. Типа ой у нас что-то медленно делается селект, надо срочно вводить NoSQL вертикальное масштабирование! Ребята я тут обнаружил у вас индекса там на столбце небыло, сейчас все работает в 400 раз быстрее.

policyd все же
Хорошая статейка… мне бы такую N-е время назад, когда 3-е суток с постфиксом ковырялся =)
В мемориз на всякий случай.
рекомендую достаточно критично подходить к написанному, и по крайней мере четко понимать какая директива что делает…
могу еще раз сообщить о своем опыте. Вышеописанные действия принесли мне серьезные плоды: «После установки почтового сервера общее число попыток прислать письмо на мой домен — 150.000 в сутки, с каждой неделей это число уменьшается за счет отработки правил (мой сервак потихоньку забывают спаммеры). На сегодняшний день это число уже около 15.000 в сутки.»
Из этих 15000 попыток передать письмо серверу — спама около 14500 и он отсекается.

Я готов принимать реальные замечания, а просто критиковать — не стоит.
реальное замечание было выше, про SASL. вот человек бездумно вставит эту директиву, а у него может и SMTP аутентификации-то нет…

потом, сказал бы пару слов про список блэклист-серверов — у SORBS раньше было много левых срабатываний, потом они заносят в списки сразу подсети, а не отдельные хосты, плюс денег требуют за удаление. я рекомендовал бы юзать только спамкоп и спамхаус…

вы поймите, я не говорю что вы неправы или что-то плохо настроили. я призываю тех кто будет юзать ваш HowTo, чтоб они понимали что они делают, т.к. от их действий будет зависеть почта множества людей.
Кроме того, dsbl.org умер (причем довольно давно). И кажется полезным дать ссылку на drbl (из-за упомянутого work.rsbs.express.ru) www.agk.nnov.ru/drbl/ru/index.html
про листы поддерживаю
>… и спамхаус…

Шютка, да? Система банящая сразу по /24 адекватной не может быть в принципе. Уж сколько о нем писано-переписанно.
51 Reject HELO/EHLO 0.04%
71 Reject unknown user 0.05%
26 Reject sender address 0.02%
24801 Reject client host 19.16%
21838 Reject unknown client host 16.87%
82640 Reject RBL 63.85%

итого: 129428 запретов приема
с похожими правилами за сутки, правда без постгрея и полисид и в текущем сезоне, обычно порядка 300.000

правда не считая того, что доходит до спам фильтра непосредственно
Небольшое дополнение про postgrey для тех, кого не устраивает задержка в доставке писем. Мое начальство было категорически против любых задержек и, как потом оказалось, не зря — некоторые отправители предпринимали вторую попытку отсылки письма чуть ли не через 15 часов. Пришлось пойти на хитрость. Теперь у меня грейлистятся только «клиенты» pbl.spamhaus.org и те, у кого нет PTR записи. Получилось довольно эффективно и жалоб нет, т.к. в грейлистинг, судя по статистике, попадают всего 2% реальных писем и, как правило, они не на столько важны ибо если IP в pbl.spamhaus.org да или PTR записи нету, то это какие-то несерьёзные люди, которые не могут нормально настроить почтовый сервер :)
rbl повторяются

> reject_rbl_client list.dsbl.org
У меня в логах вообще писал, что не могу найти list.dsbl.org.
list.dsbl.org не стоит использовать. Его выключили еще год назад.
Спасибо, Sb0y! Исправил — как-то залетело при написании…
spamassassin с razor+pyzor+dc дополнительно и спам точно не дойдет, а также выловить около 100 писем спама и скормить их spamassassin
в smtpd_recipient_restrictions = также бы посоветовал вставить проверку на подделку собственного домена, много спама идет с
user@mydomian.com на user@mydomian.com

permit_mynetworks,
permit_sasl_authenticated,
check_sender_access hash:/etc/postfix/disallow_my_domain

в /etc/postfix/disallow_my_domain вставить
mydomian.com 554 lincoln-grp.com spameer?

таким оброзом если приходит письмо от user@mydomian.com с не локальной сети (permit_mynetworks) и не от пользователя с smtp аутентификацией (permit_sasl_authenticated) шлём лесом!

в /etc/postfix/header_checks также
/^From=/ DISCARD
/^From:*$/ DISCARD
/^From:/ DISCARD

от совсем кривых спаммеров.
Всё это на продакшине более чем на 10 серверов, помогает и жалоб небыло.

>>mydomian.com 554 lincoln-grp.com
lincoln-grp.com заменить на mydomian.com
с рабочего конфига тянул )
бывает что кто-то шлёт чёрти откуда, из командировки, через корп почту. при таком сценарии защита от фейка вызовет проблемы.
В таком случае обчно помогает SMTP auth
интересная мысль megadoizer — нужно посмотреть. Недавно знакомые сталкивались с такой же проблемкой по подделке домена. Но есть одно НО, нужно посмотреть в какое место поставить check_sender_access hash:/etc/postfix/disallow_my_domain. Вы же прекрасно понимаете, что очень многое зависит от последовательности размещения правил проверки. Что-то не то поставил раньше и пошли потери или наоборот… :)
Обычно для этого используют SPF.
Совет и просьба и призыв к админам: не дропайте письма rbl-ами. Да, это их очень просто настроить и они дают быстрый результат. Но рано или поздно ваши клиенты (или их партнеры по переписке) отгребут проблем. Вон, у автора спамхаус в списке. Нередко они блэклистят русские IP целыми сетками.
Не поленитесь настроить spamassassin. Он тоже может использовать rbl-ы, проверять helo, правильность FQDN, обратную зону.
в моем случае, да и в большинстве это решается занесением сервака в один из вышеуказанных файлов хеша. Пользователи тоже не дремлют и, если возникают такие проблемы, то быстро сообщают. Таких случаев было не более десятка.
Сервер list.dsbl.org выключили еще год назад и использовать его не следует. Интересно, сколько он еще будет всплывать в руководствах для начинающих?
Спасибо foboss! Только что еще раз проверил — да, так и есть. Убрал из статьи.
Также есть тип спама, который легко отсечь и жить спокойно (не могу сказать, как это выразить в postfix, ибо exim-user ) — будет перловыми регекспами.
sender_address =~ /^(teq|\|)/
150 тысяч в сутки спама?
И сколько же у вас пользователей, просто любопытно?
около 100. домену уже 15 лет, а пользаки за это время сумели зарегистрироваться на куче нехороших сайтов — вот и перло столько писем, сейчас намного меньше — около 15000 попыток.
А не правильней ли будет распределить все проверки по своим этапам?

Проверки хоста (check_helo_access reject_invalid_hostname reject_non_fqdn_hostname и т.п.)
— в smtpd_helo_restrictions (ограничения на этапе получения helo)

Проверки отправителя (reject_non_fqdn_sender)
— в smtpd_sender_restrictions (ограничения на этапе получения from)

По крайней мере, когда я настраивал, распределил у себя так и работает нормально. А тут получается что всё в одну кучу…
Даже наверно будет лучше, спамер получит отлуп и освоободит сервак от соединения на этапе отправки helo если у него неправильный hostname, а не после того как сообщит чего и кому послать хочет. Или всё же лучше проверять всё в конце, когда получены все данные о письме?
В конце, включив delay reject, потому что с кривым HELO может быть пользователь вашего домена пытающийся послать почту, но без delay его сразу же пошлют и не дадут шанс авторизироваться.
Из листов использую:

reject_rbl_client zen.spamhaus.org=127.0.0.10
reject_rbl_client zen.spamhaus.org=127.0.0.11
reject_rbl_client zen.spamhaus.org

Этого хватает!
Сорбс и спамкоп иногда себя очень плохов ведут по отношению ко многим нашим провайдерам, так что нафиг.
reject_non_fqdn_hostname -> «Keep your mobile charged and expect to go short on sleep. Or food.»
Если у меня почта на моем домене сделана через Google Apps, чего и где прописывать?
В таком случае у тебя за почту отвечает целиком Google, ты же в днс указал его MX'ы.
Коли начали мериться цифрами, то и я внесу свою лепту,
скормил maillog pflogsumm'у —
611k rejected (98%) — за сутки
Postfix+postgrey+amavisd-new

кусок конфига:
show_user_unknown_table_name = no
smtpd_client_restrictions =
permit_mynetworks,
check_client_access hash:/usr/local/etc/postfix/whitelistip
reject_rbl_client zen.spamhaus.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client bl.spamcop.net,
permit

smtpd_sender_restrictions =
reject_unknown_sender_domain,
reject_non_fqdn_sender,
reject_invalid_hostname,
reject_unknown_address,
reject_non_fqdn_recipient

smtpd_recipient_restrictions =
permit_mynetworks,
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unauth_pipelining,
reject_unknown_recipient_domain,
check_recipient_access hash: путь,
reject_unlisted_recipient,
reject_unverified_recipient,
reject_unauth_destination,
check_policy_service амависд-нью
permit
А для чего одни и те же проверки стоят на двух этапах — smtpd_sender_restrictions и smtpd_recipient_restrictions?
Например, эти:
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain

Насколько я понимаю, postfix в данном случае будет одни и те же проверки гонять дважды для каждого письма, что необоснованно увеличит нагрузку на сервер.
Технология грейлистинга достаточна эффективна, но как говорят — хуже спамеров, только борцы со спамом.
всё что описано в статье — более чем очевидно даже для начинающего postmaster.

а вот про address verification ни слова не сказано, хотя этот метод защиты на порядок эффективней того, что описано в статье и почта с ним не задерживается (как при грейлистинге) и не теряется.
Если вы внимательно читали указанную вами ссылку, то в первой же строчке указано «The sender/recipient address verification feature described in this document is suitable only for low-traffic sites». А это означает, что для высоконагруженных систем, когда у вас по 50.000 и более попыток соединений идет в сутки — абсолютно не эффективно (если конечно у вас не навороченный сервак).
В добавок в этой же статье далее идет «It performs poorly under high load; excessive sender address verification activity may even cause your site to be blacklisted by some providers» — я думаю в блэклисты никому не хочется попасть?
А зачем reject_rbl_client проверяется в двух местах?
smtpd_sender_restrictions — это он проверяет когда узнаёт адрес отправителя (from)
smtpd_recipient_restrictions — когда узнаёт адрес получателя.
Но по-идее проверяет-то он оба раза одно и то же — ip-адрес с которого пытаются отослать.
Поэтому получается что вторая проверка лишняя. Или я ошибаюсь?

Кстати, может логичней reject_rbl_client проверять на стадии smtpd_helo_restrictions? На этом этапе мы уже знаем ip отправителя и можем его послать в далёкие дали не дожидаясь пока он скажет чего хотел ;)
Only those users with full accounts are able to leave comments. Log in, please.