Всем добрый деньПрошу, чтобы кто-нибудь помог разобраться с применением smtpd_*_restrictions.
1. Вопрос первый
Я знаю, что порядок расположения ограничений в разделах smtpd_*_restrictions играет важную роль. Это и понятно, - если получен reject или OK, то дальнейшие правила не применяются.
Также, как я понял, не играет роли, как располагать правила - каждый в своем разделе или все пихнуть в smtpd_recipient_restrictions - все равно будет играть роль порядок расположения правил. Но, нагляднее располагать каждое ограничение в "своем" разделе. При этом надо включать опцию:
smtpd_delay_reject = yes
Чтобы Postfix, принимая письмо, дошел до smtpd_recipient_restrictions и применил правила оттуда.По такой логике запись вида:
++++++++++++++++++++++
smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unauth_pipelining,
check_client_access hash:/usr/local/etc/postfix/access_client,
check_client_access pcre:/usr/local/etc/postfix/access_client.pcre,
reject_unknown_client_hostname,
check_helo_access hash:/usr/local/etc/postfix/access_helo,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
check_sender_access hash:/usr/local/etc/postfix/access_sender,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unverified_sender,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unverified_recipient,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client combined.njabl.org,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client dul.ru,
reject_rbl_client dynablock.njabl.org,
reject_rbl_client opm.blitzed.org,
reject_rhsbl_client blackhole.securitysage.com,
reject_rhsbl_client rhsbl.sorbs.net,
reject_rhsbl_sender blackhole.securitysage.com,
reject_rhsbl_sender rhsbl.sorbs.net,
permit
++++++++++++++++++++++аналогична этой записи:
++++++++++++++++++++++
smtpd_client_restrictions =
reject_unauth_pipelining
check_client_access hash:/usr/local/etc/postfix/access_client
check_client_access pcre:/usr/local/etc/postfix/access_client.pcre
reject_unknown_client_hostname
reject_rbl_client cbl.abuseat.org
reject_rbl_client combined.njabl.org
reject_rbl_client dnsbl.njabl.org
reject_rbl_client dul.ru
reject_rbl_client dynablock.njabl.org
reject_rbl_client opm.blitzed.org
reject_rhsbl_client blackhole.securitysage.com
reject_rhsbl_client rhsbl.sorbs.net
smtpd_helo_restrictions =
check_helo_access hash:/usr/local/etc/postfix/access_helo
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
smtpd_sender_restrictions =
check_sender_access hash:/usr/local/etc/postfix/access_sender
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unverified_sender
reject_rhsbl_sender blackhole.securitysage.com
reject_rhsbl_sender rhsbl.sorbs.net
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unverified_recipient
++++++++++++++++++++++Подтвердите, пожалуйста, или опровергните эти мои мысли?
2. Вопрос 2ой
Если ответ на первый вопрос "да, все верно", то объясните мне один момент, над которым я уже голову сломал:
перечитав кучу конфигов я замечал, что одни и те же опции указываются в разных разделах, например reject_unauth_pipelining люди указывают и в smtpd_recipient_restrictions и в smtpd_sender_restrictions. Но ведь это же нелогично - reject_unauth_pipelining актуальна только при коннекте, т.е. при smtpd_client_restrictions, когда удаленный сервер начинает "говорить" слишком рано.
Аналогичная ситуация с permit_sasl_authenticated и permit_mynetworks - они указываются во всех разделах, хотя согласно книге "The Book of Postfix" (авторы: Ralf Hildebrandt, Patrick Koetter) так быть не должно.
А permit_sasl_authenticated должен быть актуален только на этапе smtpd_sender_restrictions, разве нет?
Т.е. мой вопрос в том, правильно ли задавать опции только в тех разделах, в которых они должны быть?
3. Вопрос 3ий
Вот мой конфиг, - приведены опции, касающиеся ограничений:
++++++++++++++++++++++
strict_rfc821_envelopes = yes
disable_vrfy_command = no
smtpd_helo_required = yes
smtp_always_send_ehlo = yes
smtp_never_send_ehlo=no
smtpd_delay_reject = yes
smtpd_reject_unlisted_sender = yes
smtpd_reject_unlisted_recipient = yes
address_verify_sender = <>
allow_percent_hack=no
show_user_unknown_table_name=no
...
smtpd_client_restrictions=
permit_sasl_authenticated
check_client_access hash:/usr/local/etc/postfix/checks/access_client
check_client_access pcre:/usr/local/etc/postfix/checks/access_client.pcre
permit_mynetworks
reject_rbl_client bl.spamcop.net
reject_rbl_client dnsbl.sorbs.net
reject_unauth_pipelining
reject_unknown_client_hostname
reject_unknown_reverse_client_hostname
smtpd_helo_restrictions =
permit_mynetworks,
reject_invalid_helo_hostname,
smtpd_etrn_restrictions =
permit_mynetworks,
reject
smtpd_sender_restrictions =
permit_mynetworks,
check_sender_access hash:/usr/local/etc/postfix/checks/access_sender,
permit_sasl_authenticated,
reject_authenticated_sender_login_mismatch,
reject_sender_login_mismatch,
reject_unauthenticated_sender_login_mismatch,
permit_sasl_authenticated,
reject_unknown_sender_domain,
reject_unlisted_sender,
reject_non_fqdn_sender,
check_sender_access hash:/usr/local/etc/postfix/checks/access_sender
smtpd_recipient_restrictions=
permit_mynetworks,
#check_policy_service inet:127.0.0.1:10023,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unlisted_recipient,
permit_sasl_authenticated,
reject_unauth_destination,
permit_auth_destination,
check_recipient_access hash:/etc/aliases
smtpd_data_restrictions=
permit_mynetworks,
reject_unauth_pipelining,
reject_multi_recipient_bounce
++++++++++++++++++++++Как видите, у меня также permit_sasl_authenticated указан в двух местах.
Если уберу из smtpd_client_restrictions, постфикс разрывает соединение при попытке отправить письмо из почтового клиента (любого)
Если уберу из smtpd_recipient_restrictions, то получаю ошибку Relay access Denied.
Меня инетресует "правильность". Если буду знать, как правильно указывать, то буду шаманить с порядком опций и их количеством, поэтому задаю эти вопросы. Хотя при этом, мой почтовик работает замечательно, жалоб от клиентов не поступало. Uptime на данный момент уже месяц... Просто меня злит, что я не понимаю сути, хотя по внешним признакам я получил то, что хотел.
Раздел, посвященный авторизации (http://www.postfix.org/SASL_README.html) читал. Также читал ман и многое многое, в том числе и книгу.
Со всем, вроде разобрался, все понятно, но ограничения сварили кашу в моей голове, прошу помощи, чтобы разобраться.
Заранее спасибо за ответы.
> при этом, мой почтовик работает замечательно, жалоб от клиентов не поступало.
> Uptime на данный момент уже месяц... Просто меня злит, что я
> не понимаю сути, хотя по внешним признакам я получил то, что
> хотел.Если аптайм всего месяц, я бы советовал присмотреться к экзиму. Терять особенно еще нечего, а приобрести можно очень много всякого вкусного.
В частности, вместо чисто бинарных рестрикшнов у экзима на каждом этапе смтп-сессии используются сложные составные проверки, которые можно использовать для непрямого принятия решений. Ну, если в постфиксе это выглядит примерно так:
ЭТАП_СМТП =
разрешить_А,
запретить_Б,
запретить_В,
разрешить_Г...
то в экзиме можно сделать так:АЦЛ_ЭТАП1:
если условие 1 то $балл = $балл + 10
если условие 2 то $балл = $балл + 25
если условие 3 то $балл = $балл + 5
АЦЛ_ЭТАП2:
если условие 7 то $балл = $балл + 13
если условие 8 то $балл = $балл + 7
если условие 9 то $балл = $балл + 2
. . . . .
АЦЛ_ФИНАЛ:
если $балл > 50 то запретить
иначе если $балл > 40 то пометить, как крайне подозрительное и разрешить
иначе если $балл > 30 то пометить, как подозрительное и разрешить
иначе разрешить
Ну, и по остальному функционалу различия примерно того же порядка, поэтому я рекомендую присмотреться к экзиму, пока еще постфикс не засосал.
> Ну, и по остальному функционалу различия примерно того же порядка, поэтому я
> рекомендую присмотреться к экзиму, пока еще постфикс не засосал.Это неправильно.
Я имею ввиду, что если сел разбираться, то разберись, - оставлять дела незаконченными не есть хорошо.Постфикс меня вполне устраивает. Он производительнее сендмыла, легче в настройке. И документация как то... более структурирована что ли.
За экзим возьмусь позже, а пока надо разобраться с постфиксом.
У Вас есть что подсказать по моему вопросу? =)
>Он производительнее сендмыла,
>легче в настройке.
>И документация как то... более структурирована что ли.Да! Ваши бенчмарки внушають.
Да! Настроил оба, с этим *всё* легче, а с тем упарился.
Да! Нашёл все ответы в документации. Такая правильнее.Не, ну, раз всё легко и всё настроилось, то примите наши поздравления. А сложный и ненастроенный ....экзим? ...логично бросить и не тратить время на вопросы.
> За экзим возьмусь позже, а пока надо разобраться с постфиксом.
> А сложный и ненастроенный ....экзим? ...логично бросить и не тратить время
> на вопросы.Я ни в коем случае не пытаюсь развязать войну МТА или какой-нибудь холивар на эту тему.
Я лишь говорю, что потравтив время на постфикс было бы логично разобраться до конца) я потратил кучу времени, перечитал маны, две книги, но с ограничениями я так и не разобрался, у меня в голове каша, я просто прошу совета у тех, кто в своё время эту кашу расхлебал.
> Я ни в коем случае не пытаюсь развязать войну МТА или какой-нибудь
> холивар на эту тему.Зря. Обожаю холивары и с удовольствием бы поучаствовал.
Exim отличный сервер, но в нём периодически обнаруживают такие уязвимости, с которыми лучше не сталкиваться пока нет 100% уверенности в своих силах.
Поэтому просто не обращайте внимание на фанатов экзима, они хотят заманить в свою секту как можно больше народа, чтобы те разделили из боль. Эффект сопереживания из психологии или как-то так
>> Я ни в коем случае не пытаюсь развязать войну МТА или какой-нибудь
>> холивар на эту тему.
> Зря. Обожаю холивары и с удовольствием бы поучаствовал.Может быть я бы тоже поучаствовал, но я не использовал экзим.
Могу "попробовать" отстоять Сендмыл =)
> Exim отличный сервер, но в нём периодически обнаруживают такие уязвимости, с которыми
> лучше не сталкиваться пока нет 100% уверенности в своих силах.
> Поэтому просто не обращайте внимание на фанатов экзима, они хотят заманить в
> свою секту как можно больше народа, чтобы те разделили из боль.
> Эффект сопереживания из психологии или как-то так
> Exim отличный сервер, но в нём периодически обнаруживают такие уязвимости, с которыми
> лучше не сталкиваться пока нет 100% уверенности в своих силах.Вы не могли бы привести пример хотя бы трех таких уязвимостей с указанием периода их обнаружения, а также с указанием примеров невозможности устранения этих уязвимостей штатными средствами обновления софтов?
Заранее благодарен за ответ.
> Вы не могли бы привести пример хотя бы трех таких уязвимостей сНее, не мог бы. Последний раз, когда я решился посмотреть (исключительно из любопытсва. Postfix отличный сервер и полностью меня устраивает) в сторону Exim'а в нём нашли такое:
http://www.exim.org/lurker/message/20101207.215955.bb32d4f2....Т.е. возможность !!удалённо выполнять нехорошее с привилегиями root'а!! на моём сервере. Я мальчишка избалованный, привык, что привилегии root'а - это только мои привилегии. И мои заказчики точно не будут ждать третьей уязвимости и не будут анализировать невозможность устранения этих уязвимостей штатными средствами "обновления софтов". Мне просто перестанут деньги платить. Кроме того, написание кода, это как мышление - оно не меняется со временем. Поэтому нафиг.
Если вы сходите по вышеприведённой ссылке, там юноша сидел с tcpdump'ом и всё вдумчиво и грамотно расследовал, а здесь человек не до конца разобрался с текстовыми настройками, задокументированными по самые помидоры. Зачем ему такие сложности на старте ?
Поймите меня правильно: я не против Exim'a, я только за. Больше Exim'a - меньше конкурентов!
> Я мальчишка избалованный, привык, что привилегии root'а - это только мои
> привилегии. И мои заказчики точно не будут ждать третьей уязвимости и
> не будут анализировать невозможность устранения этих уязвимостей штатными средствами
> "обновления софтов". Мне просто перестанут деньги платить.с таким подходом вам надо не использовать интернет и linux вообще :) В ядре ведь тоже находят уязвимости, а то вдруг вам тоже перестанут деньги платить
> с таким подходом вам надо не использовать интернет и linux вообще :)А я linux и не использую :-) Не агритесь вы так. Я обожаю экзимку! С Новым Годом !
>> с таким подходом вам надо не использовать интернет и linux вообще :)
> А я linux и не использую :-) Не агритесь вы так. Я
> обожаю экзимку! С Новым Годом !и не думал, не являюсь слепым поклонником ни первого ни второго :)
>>> в нём периодически обнаруживают такие уязвимости, с которыми лучше не сталкиваться
>> Вы не могли бы привести пример хотя бы трех таких уязвимостей с
> Нее, не мог бы.Какое-то из двух ваших утверждений является ложью, не так ли?
> Последний раз, когда я решился посмотреть (исключительно из
> любопытсва. Postfix отличный сервер и полностью меня устраивает) в сторону Exim'а
> в нём нашли такое:
> http://www.exim.org/lurker/message/20101207.215955.bb32d4f2....Дебиан-релейтед дырку ставим в вину экзиму? Ню-ню... Плохой, плохой экзим!
> Всем добрый деньЛев Толстой на проводе. Люди, которые специализируются на обработке информации, пропускают её через свои мозги в огромных количествах. Поэтому, очень часто, они болезненно воспринимают такие гигантские вопросы. Хотите получить качественные вопросы - будьте лаконичны.
Если кратко то, man 5 postconf
> При этом надо включать опцию: smtpd_delay_reject = yes
Она включена по умолчанию.
smtpd_ХХХ_restrictions это на каком этапе что проверять. Т.е когда, а не что.
smtpd_recipient_restrictions = не что проверить для получателя, а что проверить когда придёт команда RCPT TO: mail@domain.tld
Сюда складывают по причинам:
а) всё в одном месте
а1) в лог пишется картина целиком: что, кто и кому.
б) только так можно сделать некоторые ящики всегда доступными. postmaster, abuse или ящик для ОСОБО ВАЖНОЙ ПОЧТЫ
>> Всем добрый деньи ещё я бы включил reject_sender_login_mismatch
Фишка в том, что сейчас куча народу понавтыкала spf (что правильно). Поэтому, если ваш пользователь будет слать через ваш сервер письма с from не вашими, то на том конце могут воспринять это неоднозначно. У меня одно время такие подсоединения банились. Хотя это уже через чур.
>>> Всем добрый день
> и ещё я бы включил reject_sender_login_mismatchв рабочем конфиге включена, но, опять же, я не уверен в правильной последовательности.
Более менее открывает глаза на происходящее эта статья:
http://freesource.info/wiki/Dokumentacija/Postfix/antispam/r...
но все равно остаются вопросы...
> Лев Толстой на проводе. Люди, которые специализируются на обработке информации, пропускают
> её через свои мозги в огромных количествах. Поэтому, очень часто, они
> болезненно воспринимают такие гигантские вопросы. Хотите получить качественные вопросы
> - будьте лаконичны.Пожалуй, я с Вами соглашусь.
Если кратко, то меня интересует почему в книге "Postfix. Подробное руководство" приведен пример таких ограничений:
smtpd_recipient_restrictions =
reject_non_fqdn_recipient
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/roleaccount_exceptions
reject_non_fqdn_hostname
reject_invalid_hostname
check_helo_access pcre:/etc/postfix/helo_checks
check_sender_access hash:/etc/postfix/rhsbl_sender_exceptions
reject_rhsbl_sender dsn.rfcignorant.org
check_sender_access hash:/etc/postfix/common_spam_senderdomains
permitкогда ограничения тут (только с моей стороны) являются не последоваельными. Ведь надо проводить проверки от коннекта до end_of_data?
И можно ли считать такой вид проверок:
smtpd_client_restrictions=
reject_rbl_client relays.ordb.org
smtpd_helo_restrictions=
reject_non_fqdn_helo_hostname
reject_invalid_helo_hostname
check_helo_access pcre:/etc/postfix/helo_checks
smtpd_etrn_restrictions=
smtpd_sender_restrictions=
reject_non_fqdn_sender
reject_unknown_sender_domain
check_sender_access hash:/etc/postfix/rhsbl_sender_exceptions
check_sender_mx_access cidr:/etc/postfix/bogus_mx
check_sender_access hash:/etc/postfix/common_spam_senderdomains
check_sender_access regexp:/etc/postfix/common_spam_senderdomain_keywords
reject_unverified_sender
smtpd_recipient_restrictions=
reject_non_fqdn_recipient
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/roleaccount_exceptions
smtpd_data_restrictions=
reject_multi_recipient_bounce
smtpd_end_of_data_restrictions=
[/code\Аналогичным первому.
И второй вопрос - есть ли смысл вкладывать проверки из других разделов в те, что находятся ЛЕВЕЕ. Если да, то зачем? Ведь их можно применить в своем разделе?
> Если кратко то, man 5 postconf
Это, понятное дело, прочитано в первую очередь.
> smtpd_recipient_restrictions = не что проверить для получателя, а что проверить когда придёт
> команда RCPT TO: mail@domain.tld
> Сюда складывают по причинам:
> а) всё в одном месте
> а1) в лог пишется картина целиком: что, кто и кому.Разве это не зависит от delay_rejects? Разве не эта опция позволяет получить в логе полную картину происходящего, ведь ограничение начинают применяться только на этапе RCPT TO, собрав до этого все данные об отправителе/получателе.
> б) только так можно сделать некоторые ящики всегда доступными. postmaster, abuse или
> ящик для ОСОБО ВАЖНОЙ ПОЧТЫаналогично от А1?
> Если кратко то, man 5 postconf
> Это, понятное дело, прочитано в первую очередь.Хренасе! Оо А я много лет одолеть не могу.
> Ведь надо проводить проверки от коннекта до end_of_data?
Оо
# telnet localhost 25
Trying 127.0.0.1... -------- smtpd_client_restrictions
Connected to localhost.
Escape character is '^]'.
220 mail.domain.tld ESMTP
helo porno.ru ------ smtpd_helo_restrictions
250 mail.domain.tld
mail from:admin@domain.tld ----- smtpd_sender_restrictions
250 2.1.0 Ok
rcpt to:admin@domain.tld ----- smtpd_recipient_restrictions
553 5.7.1 <admin@domain.tld>: Sender address rejected: not logged insmtpd_recipient_restrictions
reject_rbl_client relays.ordb.org
Мне прислали команду rcpt to я проверил по чёрным спискам ай пи адресНо, я могу захотеть проверить а не постмастеру ли прислали письмо. Если прислали постмастеру, то я всяко хочу его принять. Вдруг там мой брат по разуму простит в белый список внести его криво настроенный сервер
Т.е. я могу сначала мейл проверить, а потом адрес айпи.
>[оверквотинг удален]
> Trying 127.0.0.1... -------- smtpd_client_restrictions
> Connected to localhost.
> Escape character is '^]'.
> 220 mail.domain.tld ESMTP
> helo porno.ru ------ smtpd_helo_restrictions
> 250 mail.domain.tld
> mail from:admin@domain.tld ----- smtpd_sender_restrictions
> 250 2.1.0 Ok
> rcpt to:admin@domain.tld ----- smtpd_recipient_restrictions
> 553 5.7.1 <admin@domain.tld>: Sender address rejected: not logged inОб этом я и говорю.
от client до recipient (а следом data -> end_of_data)
> smtpd_recipient_restrictions
> reject_rbl_client relays.ordb.org
> Мне прислали команду rcpt to я проверил по чёрным спискам ай пи
> адрес
> Но, я могу захотеть проверить а не постмастеру ли прислали письмо. Если
> прислали постмастеру, то я всяко хочу его принять. Вдруг там мой
> брат по разуму простит в белый список внести его криво настроенный
> сервер
> Т.е. я могу сначала мейл проверить, а потом адрес айпи.Это понятно, а применительно к примеру из книги?
Там проверка клиента по спискам (а значит это client_restrictions) идет последняя, что является более логичным. Но ведь это проверка на уровне client_restriction, а значит она должна применяться первой, хоть и стоит в самом низу?
Значит, переписанный мной пример актуален? или всё же нет?
Или, dalay_checks откладывает проверку до rcpt to, а потом применяет ВСЕ ограничения, перечисленные в rcpt_restrictions в том порядке, в котором они перечислены, несмотря на то, что они не относятся к разделу rcpt_restrictions?
Судя по тому, что permit_sasl_authentificated работает в любом разделе, то так и есть, но правильно ли это?
> Это понятно, а применительно к примеру из книги?Пример из книги довольно логичен. А в вашем примере вы будете, например, проверять собственные адреса по rbl Нафига это надо ?
> Там проверка клиента по спискам (а значит это client_restrictions) идет последняя, что
> является более логичным. Но ведь это проверка на уровне client_restriction, а
> значит она должна применяться первой, хоть и стоит в самом низу?Бред. Клиент прислал rcpt to пошли проверки из секции smtpd_recipient_restrictions в том порядке, в каком они там указаны. Проверки не на уровне. Проверки КОГДА они срабатывают. Не заморачивайтесь сейчас доп флагами, которые вы включаете.
Пришла команда RCPT TO запустились проверки из smtpd_recipient_restrictions в том порядке, в каком они там указаны и всё. Не надо никаких "на уровне"
> Значит, переписанный мной пример актуален? или всё же нет?Пример ужасен.
> Пример ужасен.Поскольку у вас всё равно включен флаг "отложить до rcpt to", то, разбив правила по группам, вы просто затруднили себе управление их порядком срабатывания
>> Пример ужасен.
> Поскольку у вас всё равно включен флаг "отложить до rcpt to", то,
> разбив правила по группам, вы просто затруднили себе управление их порядком
> срабатыванияСтановится яснее
до RCPT TO я соберу всю необходимую информацию.
Правила выставляю согласно из силе. Например, если нету recipient в моих таблицах, то логично сразу сделать reject.
Если есть реципиент, то можно проверить валидность отправителя и так далее справа налево
Попробую переписать собственные ограничения, выложу здесь =)
Спасибо за ответы!
> Попробую переписать собственные ограничения, выложу здесь =)Как и обещал, выкладываю конфиг.
Несколько примечаний:
1. Привел также опции, которые касаются ограничений перед самими ограничениями
2. Все, что идет до permit_mynetworks и permit_saslauthentificated влияет на работу как "своих" клиентов, так и не моих. Таким образом, есть определенный набор опций, которые должны соблюдать все. Если попадётся валидный отправитель, то он сможет оповестить меня через исключенные из проверок аккаунты и я занесу его в соответствующие мапы исключений с параметром ОК
strict_rfc821_envelopes = yes
disable_vrfy_command = no
smtpd_helo_required = yes
smtp_always_send_ehlo = yes
smtp_never_send_ehlo=no
smtpd_delay_reject = yes
smtpd_reject_unlisted_sender = yes
smtpd_reject_unlisted_recipient = yes
address_verify_sender = <>
allow_percent_hack=no
allow_untrusted_routing = no
resolve_null_domain = no
resolve_numeric_domain = nosmtpd_recipient_restrictions =
#Может быть письмо отправлено postmaster/abuse/hostmaster/webmaster. такое письмо я хочу принять.check_recipient_access hash:/usr/local/etc/postfix/checks/account_exceptions
#Я не хочу ни принимать почту, ни как-либо проверять её от клиентов, которых я явно заблокировал
check_client_access hash:/usr/local/etc/postfix/checks/access_client
#Я не хочу ни принимать почту, ни как-либо проверять её от клиентов, которых я явно заблокировал
check_client_access pcre:/usr/local/etc/postfix/checks/access_client.pcre#А также не хочу ничего принимать от конкретных почтовых ящиков, которые я сам определил
check_sender_access hash:/usr/local/etc/postfix/checks/access_sender
#не хочу принимать почту, если мой recipient не Fully Qualified Dimain Name
reject_non_fqdn_recipient
#не хочу принимать почту от не Fully Qualified Dimain Name
reject_non_fqdn_sender
#не хочу принимать почту из несуществующих доменов
reject_unknown_sender_domain
#не хочу принимать почту для несуществующих доменов
reject_unknown_recipient_domain
#reject_sender_login_mismatch для не аутентифицированных клиентовreject_unauthenticated_sender_login_mismatch
#reject_sender_login_mismatch для аутентифицированных клиентов.
reject_authenticated_sender_login_mismatch
#Хочу, чтобы имя отправителя и имя, указанное в поле MAIL FROM соответствовали
#друг другу. Иначе - reject. Эти три опции актуальны, потому что спамеры очень
#любят подделывать поле MAIL FROM устраивая рассылку таким образом через ваш сервер.reject_sender_login_mismatch
#127.0.0.1 (а именно этот адрес указан в mynetworks) разрешаю всё
permit_mynetworks
#залогинившимся разрешаю всё
permit_sasl_authenticated
#закрываю open_relay
reject_unauth_destination
#Те, кто начинаю "говорить" слишком рано - отбрасываются
reject_unauth_pipelining
#Включаю грейлистинг. Delay в 5 минут, whitelisting в 30 днейcheck_policy_service inet:127.0.0.1:10023
#Те, кто использует моё имя при HELO, автоматически считаются спамерами. Дальнейший диалог бессмысленен.
check_helo_access hash:/usr/local/etc/postfix/checks/access_helo
#Не принимаю почту от клиентов, не зарегистрированных в ДНС
reject_unknown_client_hostname
reject_non_fqdn_helo_hostname
#Если удаленный сервер/клиент представился не полным именем, то отлуп
reject_invalid_helo_hostname
#Делаю запрос серверу отправителю на наличие учетки, от которой идет письмо. Если таковой учетки не имеется - отлуп
reject_unverified_sender
#Проверяю наличие получателя
reject_unverified_recipient
#Проверяю наличие получателя 2
reject_unlisted_recipient
#В самом конце идут черные списки. Во-первых, если валидный клиент хочет отправить мне письмо, но он в
#черном списке, то он может отправить мне письмо и я добавлю его в исключения.
#Во-вторых, если "мой" клиент хочет отправить письмо через мой сервер из сети, которая находится в черном
#списке, то он пройдет аутентификацию, т.е. проверка закончится на permit_sasl_authenticated и не дойдет до черного спискаreject_rbl_client bl.spamcop.net
reject_rbl_client sbl.spamhaus.org
reject_rbl_client dnsbl.sorbs.net#Если все правила вернули DUNNO, то применяем правило по-умолчанию и принимаем письмо.
permit
smtpd_data_restrictions =
reject_multi_recipient_bounceИ привожу содержимое используемых файлов:
account_exceptions:
postmaster@ OK
abuse@ OK
hostmaster@ OK
webmaster@ OK
checks/access_client
(пока что пусто)
checks/access_client.pcre
/[ax]dsl.*\..*\..*/i REJECT Your message looks like SPAM
/\.dsl.*\..*\..*/i REJECT Your message looks like SPAM
/cable.*\..*\..*/i REJECT Your message looks like SPAM
/client.*\..*\..*/i REJECT Your message looks like SPAM
/dhcp.*\..*\..*/i REJECT Your message looks like SPAM
/dial.*\..*\..*/i REJECT Your message looks like SPAM
/dialup.*\..*\..*/i REJECT Your message looks like SPAM
/dslam.*\..*\..*/i REJECT Your message looks like SPAM
/host.*\..*\..*/i REJECT Your message looks like SPAM
/node.*\..*\..*/i REJECT Your message looks like SPAM
/pool.*\..*\..*/i REJECT Your message looks like SPAM
/ppp.*\..*\..*/i REJECT Your message looks like SPAM
/user.*\..*\..*/i REJECT Your message looks like SPAMchecks/access_sender
(пока что пусто)
checks/access_helo
127.0.0.1 REJECT Your server configured incorrectly
localhost REJECT Your server configured incorrectly
localhost.localdomain REJECT Your server configured incorrectly
localhost.mydomain.ru REJECT Your server configured incorrectly
192.168 REJECT Your server configured incorrectly
1.1.1.1(Ваш внешний ip) REJECT Your server configured incorrectly
mail.mydomain.ru REJECT Your server configured incorrectly
/([0-9]{1,3}(\.|-)){3}[0-9]{1,3}/i REJECT Your server configured incorrectly
The Book of Postfix (Ральф Гильдебрандт, Патрик Кеттер)
Глава 7, в часности Таблицы 7.1 и 7.2 должны помочь Вам.
> The Book of Postfix (Ральф Гильдебрандт, Патрик Кеттер)
> Глава 7, в часности Таблицы 7.1 и 7.2 должны помочь Вам.Читал
Более того, я сюда оттуда примеры копировал =)
> ЧиталИз таблиц понятен порядок проверки рестрикшинсов:
_1 smtpd_client_restrictions
_2 smtpd_helo_restrictions
_3 smtpd_etrn_restrictions
_4 smtpd_sender_restrictions
_5 smtpd_recipient_restrictions
_6 smtpd_data_restrictions
_7 smtpd_end_of_data_restrictions
Что Вас смущает? (я как то уже потерялся)...
> Что Вас смущает? (я как то уже потерялся)...Гектор Зажигайло ранее ответил на мои вопросы
> Проверки КОГДА они срабатывают. Не заморачивайтесь сейчас
> доп флагами, которые вы включаете.
>
> Пришла команда RCPT TO запустились проверки из
> smtpd_recipient_restrictions в том порядке, в
> каком они там указаны и всё. Не надо никаких "на уровне"Я запустался в том, как правильней указать рестрикшены.
dalay_checks отклыдвает проверки до RCPT TO, - и вот тут меня смущал факт наличия 7 групп для разбиваения проверок и схемой их управления.
Я колебался между указанием всего в "своем" разделе или указанием всего в одном разделе - recipient_restrictions.
Если раскидать ограничения по "своим" разделам, то управление оными усложняется, потому что они все равно применятся в том порядке, в котором они идут. Раз ограничения применяются "КОГДА", то логичней их кинуть в recipient_restrictions в нужном порядке - как и приведенный в книге пример.
Я просто не понимал ПОЧЕМУ этого нигде так не объяснено и думал, что правильным методом является указание ограничения в своем разделе.