Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 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), а аутентифицикация сильно позже. Он и не отправит ничего.
Потому что иногда вам нужно от каких-то серверов получить почту. Ведь никто не застрахован от попадания в RBL.
permit_sasl_authenticated никакого отношения не имеет к SSL. параметр означет, что постфикс должен принимать почту от авторизовавшихся через SASL юзеров.
с проверкой обратной DNS никогда не парился.
по моему скромному опыту наиболее эффективная защита — отсекание всех динамических IP по маске, грейлистинг, проверка по блэклистам.
до собственно антиспама доходит примерно 1% плохих писем в итоге. забавно, в статье кстати про собственно антиспам ни слова нет :))
с проверкой обратной DNS никогда не парился.
по моему скромному опыту наиболее эффективная защита — отсекание всех динамических IP по маске, грейлистинг, проверка по блэклистам.
до собственно антиспама доходит примерно 1% плохих писем в итоге. забавно, в статье кстати про собственно антиспам ни слова нет :))
«permit_sasl_authenticated никакого отношения не имеет к SSL» — косвенно имеет! Если вы включаете строку permit_sasl_authenticated в конфиг и не настраиваете почтовый сервер на работу с SSL и TLS, то все ваши логины и пароли через SASL пойдут в открытую. Поэтому не путайте пожалуйста людей.
«с проверкой обратной DNS никогда не парился» — что вы имеете в виду? Вы не проверяете PTR записи? Зря…
«отсекание всех динамических IP по маске, грейлистинг, проверка по блэклистам» — а я разве не описал грейлистинг и блэклисты?
«про собственно антиспам ни слова нет» — у меня настроен spamassassin, но только в режиме не навреди (факстически не работает). Это очень серьезная программа и с ней нужно быть очень внимательным иначе можно зарубить всю почту. Я его держу на самый крайний случай, когда вышеописанные действия перестанут помогать.
«с проверкой обратной 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 — безопаснее?
и потом, вы хотите сказать, что без permit_sasl_authenticated, но с SSL/TLS — безопаснее?
>> у меня настроен spamassassin, но только в режиме не навреди (факстически не работает). Это очень серьезная программа и с ней нужно быть очень внимательным иначе можно зарубить всю почту. Я его держу на самый крайний случай, когда вышеописанные действия перестанут помогать.
Очень напрасно. Правда его правильная настройка отнимает большое кол-во времени, но мой личный результат превзошел все ожидания. После кропотливых проверок и выверок правил, а также упорной тренировки байес фильтра, были выведены золотые правила, которые допускали 0,001 % вероятности блокировки «правильного» письма и около 99 % блокировки неправильного письма. В условиях 1000 спам писем в день, это действительно очень хороший результат.
Причем, все это происходило на stand-alone сервере, на котором крутилось 15-20 активных доменов.
Очень напрасно. Правда его правильная настройка отнимает большое кол-во времени, но мой личный результат превзошел все ожидания. После кропотливых проверок и выверок правил, а также упорной тренировки байес фильтра, были выведены золотые правила, которые допускали 0,001 % вероятности блокировки «правильного» письма и около 99 % блокировки неправильного письма. В условиях 1000 спам писем в день, это действительно очень хороший результат.
Причем, все это происходило на stand-alone сервере, на котором крутилось 15-20 активных доменов.
Всесто postgrey лучше использовать policyd. Он позволяет существенно больше и есть отбивалка по HELO.
Если я не ошибаюсь policyd хранит информацию в БД, типа mySQL, Postgres или SQLite 3. В случае же postgrey — база данных не нужна. Если не хочется заморачиваться с БД, то postgrey выгодней.
А по производительности он как на больших нагрузках? Мне кажется что каждый раз делать проверку sql-запросом будет намного накладнее чем в key-value базе.
Ещё кстати есть SQLgrey — тоже аналогичная policyd штука.
Сейчас вот настраивают сервер и не знаю что выбрать — postgrey, policyd, SQLgrey, в рунете и буржунете сравнений этих демонов вообще никаких не нашёл ;(
Кто уже анализировал — может опишите у кого какие преимущества и недостатки?
Кстати, есть ещё policyd-weight — но это вроде уже совсем другое…
Ещё кстати есть 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?
Кстати, если под рукой есть мануал по их настройке какой — кинете может ссылкой?
Да и попытки заслать спам идут постоянно в очень больших количествах, так что по нагрузке на проц тоже я думаю заметно будет — разница между SQL-запросом и nosql-запросом значительная, судя по статьям.
И что Вы порекомедуете тогда из этих оставшихся вариантов — policyd или sqlgrey?
Кстати, если под рукой есть мануал по их настройке какой — кинете может ссылкой?
Ну как небольшая, ассортимент IP-адресов в инете немалый
К вам весь интернет сразу ломиться не будет.
Да и попытки заслать спам идут постоянно в очень больших количествах, так что по нагрузке на проц тоже я думаю заметно будет — разница между SQL-запросом и nosql-запросом значительная, судя по статьям.
Тут раз уже про это говорили. Типа ой у нас что-то медленно делается селект, надо срочно вводить NoSQL вертикальное масштабирование! Ребята я тут обнаружил у вас индекса там на столбце небыло, сейчас все работает в 400 раз быстрее.
policyd все же
Хорошая статейка… мне бы такую N-е время назад, когда 3-е суток с постфиксом ковырялся =)
В мемориз на всякий случай.
В мемориз на всякий случай.
рекомендую достаточно критично подходить к написанному, и по крайней мере четко понимать какая директива что делает…
могу еще раз сообщить о своем опыте. Вышеописанные действия принесли мне серьезные плоды: «После установки почтового сервера общее число попыток прислать письмо на мой домен — 150.000 в сутки, с каждой неделей это число уменьшается за счет отработки правил (мой сервак потихоньку забывают спаммеры). На сегодняшний день это число уже около 15.000 в сутки.»
Из этих 15000 попыток передать письмо серверу — спама около 14500 и он отсекается.
Я готов принимать реальные замечания, а просто критиковать — не стоит.
Из этих 15000 попыток передать письмо серверу — спама около 14500 и он отсекается.
Я готов принимать реальные замечания, а просто критиковать — не стоит.
реальное замечание было выше, про SASL. вот человек бездумно вставит эту директиву, а у него может и SMTP аутентификации-то нет…
потом, сказал бы пару слов про список блэклист-серверов — у SORBS раньше было много левых срабатываний, потом они заносят в списки сразу подсети, а не отдельные хосты, плюс денег требуют за удаление. я рекомендовал бы юзать только спамкоп и спамхаус…
вы поймите, я не говорю что вы неправы или что-то плохо настроили. я призываю тех кто будет юзать ваш HowTo, чтоб они понимали что они делают, т.к. от их действий будет зависеть почта множества людей.
потом, сказал бы пару слов про список блэклист-серверов — у SORBS раньше было много левых срабатываний, потом они заносят в списки сразу подсети, а не отдельные хосты, плюс денег требуют за удаление. я рекомендовал бы юзать только спамкоп и спамхаус…
вы поймите, я не говорю что вы неправы или что-то плохо настроили. я призываю тех кто будет юзать ваш HowTo, чтоб они понимали что они делают, т.к. от их действий будет зависеть почта множества людей.
вот подробнее про SORBS: www.antispam.ru/sh?act=msg&id=1081337178
Кроме того, dsbl.org умер (причем довольно давно). И кажется полезным дать ссылку на drbl (из-за упомянутого work.rsbs.express.ru) www.agk.nnov.ru/drbl/ru/index.html
про листы поддерживаю
>… и спамхаус…
Шютка, да? Система банящая сразу по /24 адекватной не может быть в принципе. Уж сколько о нем писано-переписанно.
Шютка, да? Система банящая сразу по /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
правда не считая того, что доходит до спам фильтра непосредственно
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
> reject_rbl_client list.dsbl.org
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 серверов, помогает и жалоб небыло.
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
с рабочего конфига тянул )
lincoln-grp.com заменить на mydomian.com
с рабочего конфига тянул )
бывает что кто-то шлёт чёрти откуда, из командировки, через корп почту. при таком сценарии защита от фейка вызовет проблемы.
интересная мысль megadoizer — нужно посмотреть. Недавно знакомые сталкивались с такой же проблемкой по подделке домена. Но есть одно НО, нужно посмотреть в какое место поставить check_sender_access hash:/etc/postfix/disallow_my_domain. Вы же прекрасно понимаете, что очень многое зависит от последовательности размещения правил проверки. Что-то не то поставил раньше и пошли потери или наоборот… :)
Обычно для этого используют SPF.
Совет и просьба и призыв к админам: не дропайте письма rbl-ами. Да, это их очень просто настроить и они дают быстрый результат. Но рано или поздно ваши клиенты (или их партнеры по переписке) отгребут проблем. Вон, у автора спамхаус в списке. Нередко они блэклистят русские IP целыми сетками.
Не поленитесь настроить spamassassin. Он тоже может использовать rbl-ы, проверять helo, правильность FQDN, обратную зону.
Не поленитесь настроить spamassassin. Он тоже может использовать rbl-ы, проверять helo, правильность FQDN, обратную зону.
Сервер list.dsbl.org выключили еще год назад и использовать его не следует. Интересно, сколько он еще будет всплывать в руководствах для начинающих?
Неплохая статья, однако лучше jimsun.linxnet.com/misc/postfix-anti-UCE.txt еще ничего в интернете не встречалось.
Также есть тип спама, который легко отсечь и жить спокойно (не могу сказать, как это выразить в postfix, ибо exim-user ) — будет перловыми регекспами.
sender_address =~ /^(teq|\|)/
sender_address =~ /^(teq|\|)/
150 тысяч в сутки спама?
И сколько же у вас пользователей, просто любопытно?
И сколько же у вас пользователей, просто любопытно?
А не правильней ли будет распределить все проверки по своим этапам?
Проверки хоста (check_helo_access reject_invalid_hostname reject_non_fqdn_hostname и т.п.)
— в smtpd_helo_restrictions (ограничения на этапе получения helo)
Проверки отправителя (reject_non_fqdn_sender)
— в smtpd_sender_restrictions (ограничения на этапе получения from)
По крайней мере, когда я настраивал, распределил у себя так и работает нормально. А тут получается что всё в одну кучу…
Даже наверно будет лучше, спамер получит отлуп и освоободит сервак от соединения на этапе отправки helo если у него неправильный hostname, а не после того как сообщит чего и кому послать хочет. Или всё же лучше проверять всё в конце, когда получены все данные о письме?
Проверки хоста (check_helo_access reject_invalid_hostname reject_non_fqdn_hostname и т.п.)
— в smtpd_helo_restrictions (ограничения на этапе получения helo)
Проверки отправителя (reject_non_fqdn_sender)
— в smtpd_sender_restrictions (ограничения на этапе получения from)
По крайней мере, когда я настраивал, распределил у себя так и работает нормально. А тут получается что всё в одну кучу…
Даже наверно будет лучше, спамер получит отлуп и освоободит сервак от соединения на этапе отправки helo если у него неправильный hostname, а не после того как сообщит чего и кому послать хочет. Или всё же лучше проверять всё в конце, когда получены все данные о письме?
Из листов использую:
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_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, чего и где прописывать?
Коли начали мериться цифрами, то и я внесу свою лепту,
скормил 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
скормил 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 в данном случае будет одни и те же проверки гонять дважды для каждого письма, что необоснованно увеличит нагрузку на сервер.
Например, эти:
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain
Насколько я понимаю, postfix в данном случае будет одни и те же проверки гонять дважды для каждого письма, что необоснованно увеличит нагрузку на сервер.
Технология грейлистинга достаточна эффективна, но как говорят — хуже спамеров, только борцы со спамом.
всё что описано в статье — более чем очевидно даже для начинающего postmaster.
а вот про address verification ни слова не сказано, хотя этот метод защиты на порядок эффективней того, что описано в статье и почта с ним не задерживается (как при грейлистинге) и не теряется.
а вот про 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 отправителя и можем его послать в далёкие дали не дожидаясь пока он скажет чего хотел ;)
smtpd_sender_restrictions — это он проверяет когда узнаёт адрес отправителя (from)
smtpd_recipient_restrictions — когда узнаёт адрес получателя.
Но по-идее проверяет-то он оба раза одно и то же — ip-адрес с которого пытаются отослать.
Поэтому получается что вторая проверка лишняя. Или я ошибаюсь?
Кстати, может логичней reject_rbl_client проверять на стадии smtpd_helo_restrictions? На этом этапе мы уже знаем ip отправителя и можем его послать в далёкие дали не дожидаясь пока он скажет чего хотел ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защита пользователей почтового сервера от спаммеров — несколько шагов, которые помогут вам отослать спаммеров подальше