форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[ Отслеживать ]

"Два душещипательных вопроса по Postfix"

Сообщение от Sava on 06-Янв-09, 13:38

Добрый день, уважаемые посетители! Есть два важных вопроса по постфикс. 1) Многим наверное известна ситуация: Для домена есть две МХ записи - основной и резервный МХ. Все работает чудесно, в случае падения первого МХ второй накапливает в себе почту. Но есть спамеры, которые этим пользуются. Подло шлют тонны писем на резервный МХ, и практически оставляют без внимания основной. Таким образом они пытаются обмануть защиту от спама, т.к. резервный МХ в принципе является доверенным доверенным для первого. Из вариантов борьбы я знаю только вариант дописания третьего МХ, который на самом деле смотрит на первый. Но этот нехитрый трюк обманывает только часть спамеров. Не подскажете, как все же быть? Нет ли у постфикса такой штуки, которая могла при получении письма для на втором МХ проверяла доступность первого, и в случае его доступности посылала спамера куда подальше? В EXIM такая фича, если не ошибаюсь, есть. 2) В EXIM есть еще такая очень полезная опция "delay", которая задерживает ответ сервера после установления соединения на N секунд. Нормальные почтовики при этом ждут и ничего не делают, а спамеры частенько не обращая ни на что внимания пуляют свое письмо. На что EXIM обижается и отбивает с "syncronization error". Нет ли похожей штуки в постфикс? delay 5 в рестрикшинах не помогает с виду. Это не грейлстинг!

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Два душещипательных вопроса по Postfix"

Сообщение от Ingoa on 06-Янв-09, 18:36

Можно делать DNS-балансировку IN  MX  10  mail.example.com. IN  MX  10  mail1.example.com. IN  MX  10  mail2.example.com. Можно делать nginx-ом Можно делать редиректом с помощью фильтра Вообще лучше ставить сервера в dmz и балансировать их редиректом pf и iptables умеют >[оверквотинг удален] >постфикса такой штуки, которая могла при получении письма для на втором >МХ проверяла доступность первого, и в случае его доступности посылала спамера >куда подальше? В EXIM такая фича, если не ошибаюсь, есть. >2) В EXIM есть еще такая очень полезная опция "delay", которая задерживает >ответ сервера после установления соединения на N секунд. Нормальные почтовики при >этом ждут и ничего не делают, а спамеры частенько не обращая >ни на что внимания пуляют свое письмо. На что EXIM обижается >и отбивает с "syncronization error". Нет ли похожей штуки в постфикс? >delay 5 в рестрикшинах не помогает с виду. >Это не грейлстинг!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Два душещипательных вопроса по Postfix"
	Сообщение от Sava on 06-Янв-09, 18:50
	>Можно делать DNS-балансировку >IN  MX  10  mail.example.com. >IN  MX  10  mail1.example.com. >IN  MX  10  mail2.example.com. Я не строю отказоустойчивую или load-balancing систему. У меня есть один полноценный почтовый сервер, и есть небольшая раскорячка стоящая в другом городе в подвале. Ее задача - поймать почту в случае недоступности основного МХ, и как только он вернется - отдать ему пропущенное мыло. Все. А проблема в том, что спамеры охотнее шлют спам на резервную раскорячку, чем на первый МХ.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Два душещипательных вопроса по Postfix"
	Сообщение от Ingoa on 06-Янв-09, 19:06
	Понял.Может тогда делать так- когда основной сервер доступен- блокировать фильтром доступ на смтп, когда основной недоступен- открывать порт. крутить скажем раз в 5 сек. коряво, но будет работать. еще еще вариант- не запирать совсем смтп раскорячки, а менять фильтром лимиты наподобие rate-limit connection-per-host-limit. когда основной доступен- жестко ограничивать, когда упал- снимать >Я не строю отказоустойчивую или load-balancing систему. У меня есть один полноценный >почтовый сервер, и есть небольшая раскорячка стоящая в другом городе в >подвале. Ее задача - поймать почту в случае недоступности основного МХ, >и как только он вернется - отдать ему пропущенное мыло. Все. >А проблема в том, что спамеры охотнее шлют спам на резервную >раскорячку, чем на первый МХ.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Два душещипательных вопроса по Postfix"
	Сообщение от Sava on 06-Янв-09, 23:01
	>Понял.Может тогда делать так- когда основной сервер доступен- блокировать фильтром доступ на >смтп, когда основной недоступен- открывать порт. крутить скажем раз в 5 >сек. коряво, но будет работать. еще еще вариант- не запирать совсем >смтп раскорячки, а менять фильтром лимиты наподобие rate-limit connection-per-host-limit. когда основной >доступен- жестко ограничивать, когда упал- снимать Что-мне мне кажется это грязным хаком :) В принципе придумал. В smtpd_recipient_restrictions проверяем check_recipient_access regexp:postfix/mxbackup Внутри которого лежит либо "/backuping.domain.tld/ 450 Use primary MX!" Либо ничего не лежит относительно backuping.domain.tld, тогда почта принимается. Скрипт написать, который будет проверять первичный МХ на работоспособность отдельная задача. Из нехорошестей - надо делать postfix reload в случае изменения статуса основного МХа. Скрипт этот пускать по крону раз в 5 минут, к примеру. Тоже как-то не красиво, но работает. Но это решение только первого моего вопроса :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Два душещипательных вопроса по Postfix"

Сообщение от g.iliya (ok) on 06-Янв-09, 21:41

По поводу delay: http://www.postfix.org/postconf.5.html#reject_unauth_pipelining и http://www.postfix.org/postconf.5.html#sleep

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Два душещипательных вопроса по Postfix"
	Сообщение от Sava on 06-Янв-09, 23:09
	>По поводу delay: >http://www.postfix.org/postconf.5.html#reject_unauth_pipelining и http://www.postfix.org/postconf.5.html#sleep В первом посте я опечатался насчет "delay 5" Пробовал smtpd_client_restrictions =     permit_mynetworks,                                 permit_sasl_authenticated,                                 check_client_access hash:$base/client_access                                 reject_rbl_client list.dsbl.org,                                 reject_rbl_client bl.spamcop.net,                                 reject_rbl_client sbl-xbl.spamhaus.org,                                 reject_rbl_client cbl.abuseat.org,                                 reject_rbl_client combined.njabl.org,                                 reject_rbl_client rhsbl.ahbl.org,                                 reject_rbl_client multi.surbl.org,                                 reject_rbl_client web.dnsbl.sorbs.net,                                 sleep 10,                                 reject_unauth_pipelining С виду - не помогло. Возможно и ошибаюсь, не доглядел. В догонку вопросик исходя что sleep 10 работает, как бы так сделать, чтоб "однажды прошедшие проверку" хосты больше не задерживались? Их то-ли в базу как-то заносить надо, или в памяти держать...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Два душещипательных вопроса по Postfix"
	Сообщение от g.iliya (ok) on 06-Янв-09, 23:24
	>"однажды прошедшие проверку" хосты больше не задерживались? Их то-ли в базу >как-то заносить надо, или в памяти держать... Я наверно чего-то не понимаю, но я бы сделал просто greylist. Sleep убрал бы вообще, не замечал я высокую эффективность данной опции (но это, как говорится сугубо личное).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Два душещипательных вопроса по Postfix"
	Сообщение от Sava on 07-Янв-09, 16:23
	>>"однажды прошедшие проверку" хосты больше не задерживались? Их то-ли в базу >>как-то заносить надо, или в памяти держать... > >Я наверно чего-то не понимаю, но я бы сделал просто greylist. >Sleep убрал бы вообще, не замечал я высокую эффективность данной опции (но >это, как говорится сугубо личное). Грейлистинг - это хорошо, но накладные расходы слишком велики. Задержка валидной почты мне очень не нравится. А "держать на уме" мегабайт двести мусора, так и подавно... В вот метод delay = 10s в Екзиме мне понравился. Сразу видно в логах что метод красивенно работает. Интересно стало узнать об аналогиях в Постфиксе. Исключительно познавательный интерес.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Два душещипательных вопроса по Postfix"

Сообщение от Vladimir (??) on 07-Янв-09, 11:31

>> Подло шлют тонны писем на резервный МХ, А что у вас проверки получателя на backup mx нет? И тот весь мусор вместо reject-a  перенаправляет на основной?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Два душещипательных вопроса по Postfix"
	Сообщение от Sava on 07-Янв-09, 16:10
	>>> Подло шлют тонны писем на резервный МХ, > > А что у вас проверки получателя на backup mx нет? > И тот весь мусор вместо reject-a  перенаправляет на основной? Само собой, уважаемый. Принцип работы резервного МХ такой. Ему позволено релеить почту для домена, резервным для которого он является. Тоесть в ДНС прописано МХ 10 mainmx.domain.tld и MX 20 secondarymx.domain.tld. Так вот в общем случае на вторичном МХ должно быть прописано что relay_domains = domain.tld и в транспортах domain.tld smtp:[mainmx.domain.tld] если хотим релеить почту ИМЕННО в mainmx.domain.tld либо же просто domain.tld relay чтоб он заглядывал в ДНС для поиска подходящего МХ. И так оно все отлично работает. Если первичный МХ упал, то мыло идет на вторичный, который в свою очередь не может сразу отдать ее первичному и держит ее в очереди (deffered). Таким образом мыло не теряется. (В общем случае справедливо заметить что и без резервного МХ она пропасть не должна. Любой _нормальный_ почтовый сервер будет держать ее у себя некоторое время (около 2 недель стандартно), но перестраховка не помешает.)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Два душещипательных вопроса по Postfix"
	Сообщение от Vladimir (??) on 07-Янв-09, 17:52
	>> Само собой, уважаемый. Принцип работы резервного МХ такой. Ему позволено релеить почту для домена,   Но при этом он не должен принимать почту для несуществующих пользователей домена.   А у вас она скорее всего принимается.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Два душещипательных вопроса по Postfix"
	Сообщение от Sava on 07-Янв-09, 20:17
	>>> Само собой, уважаемый. Принцип работы резервного МХ такой. Ему позволено релеить почту для домена, > >  Но при этом он не должен принимать почту для несуществующих >пользователей домена. >  А у вас она скорее всего принимается. Он должен принимать всю почту. Он ничего не знает о пользователях домена, он просто передает весь поток другому хосту. Все. Проблему решил. Всем спасибо! :) ЗЫ. Если кто-то может что-то конструктивное сказать - говорите.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Два душещипательных вопроса по Postfix"
	Сообщение от Vladimir (??) on 08-Янв-09, 10:04
	>> Он ничего не знает о пользователях домена, он просто передает весь поток другому хосту Вот в этом и ошибка. http://www.freesource.info/wiki/Dokumentacija/Postfix/BackupMX&
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Два душещипательных вопроса по Postfix"
	Сообщение от Sava on 08-Янв-09, 17:11
	>>> Он ничего не знает о пользователях домена, он просто передает весь поток другому хосту > > Вот в этом и ошибка. > > http://www.freesource.info/wiki/Dokumentacija/Postfix/BackupMX& А как применить данное утверждение, если в домене пару тысяч юзеров? Я понимаю, хорошо конечно на всех МХ-ах знать всех пользователей, но... В таком случае надо либо хранить виртуальных пользователей централизованно, либо синхронизировать базу между всеми участниками обработки почты для домена. В принципе репликацией (my|pg)sql это сделать можно, но схема получается уже не простая. На мой взгляд все же проще резервному МХ спрашивать у основного "эй, мужик, ты живой?" и если он живой, то просто не релеить для него почту.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Два душещипательных вопроса по Postfix"
	Сообщение от Vladimir (??) on 08-Янв-09, 17:50
	>> А как применить данное утверждение, если в домене пару тысяч юзеров? Я понимаю, хорошо конечно на всех МХ-ах знать всех пользователей, Ldap используйте для этого. Ни и репликацию настраивайте, если у вас так серьезно. А в противном случае получайте кучу мусора. Интересно, сколько у вас такого добра в гигабайтах в месяц выходит?   >> На мой взгляд все же проще резервному МХ спрашивать у основного "эй, мужик, ты живой?" и если он живой, то просто не релеить для него почту.   А вот это какой огород.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Два душещипательных вопроса по Postfix"
	Сообщение от Sava on 08-Янв-09, 19:51
	>>> А как применить данное утверждение, если в домене пару тысяч юзеров? Я понимаю, хорошо конечно на всех МХ-ах знать всех пользователей, > > Ldap используйте для этого. Ни и репликацию настраивайте, если у вас >так серьезно. > А в противном случае получайте кучу мусора. Интересно, сколько у вас >такого добра в гигабайтах в месяц выходит? > >  >> На мой взгляд все же проще резервному МХ спрашивать у основного "эй, мужик, ты живой?" и если он живой, то просто не релеить для него почту. > >  А вот это какой огород. А это в огород самого первого вопроса, если вы его читали. Он звучал как, как сделать так, чтоб вторичный МХ не релеил почту пока жив основной, потому что спамеры шлют почту для домена через резервный МХ. Понятное дело что спам не проходит все-равно, вопрос в лишнем потоке через вторичный МХ, тогда, когда его там быть не должно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]