The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"smtpd_*_restrictions. Помогите пожалуйста разобраться"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Почта / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 28-Дек-12, 12:32 
Всем добрый день

Прошу, чтобы кто-нибудь помог разобраться с применением 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) читал. Также читал ман и многое многое, в том числе и книгу.

Со всем, вроде разобрался, все понятно, но ограничения сварили кашу в моей голове, прошу помощи, чтобы разобраться.

Заранее спасибо за ответы.

Ответить | Правка | Cообщить модератору

Оглавление

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


1. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от DeadLoco (ok) on 29-Дек-12, 15:19 
> при этом, мой почтовик работает замечательно, жалоб от клиентов не поступало.
> Uptime на данный момент уже месяц... Просто меня злит, что я
> не понимаю сути, хотя по внешним признакам я получил то, что
> хотел.

Если аптайм всего месяц, я бы советовал присмотреться к экзиму. Терять особенно еще нечего, а приобрести можно очень много всякого вкусного.

В частности, вместо чисто бинарных рестрикшнов у экзима на каждом этапе смтп-сессии используются сложные составные проверки, которые можно использовать для непрямого принятия решений. Ну, если в постфиксе это выглядит примерно так:

ЭТАП_СМТП = 
  разрешить_А,
  запретить_Б,
  запретить_В,
  разрешить_Г...

то в экзиме можно сделать так:
АЦЛ_ЭТАП1:
  если условие 1 то $балл = $балл + 10
  если условие 2 то $балл = $балл + 25
  если условие 3 то $балл = $балл + 5
АЦЛ_ЭТАП2:
  если условие 7 то $балл = $балл + 13
  если условие 8 то $балл = $балл + 7
  если условие 9 то $балл = $балл + 2
. . . . .
АЦЛ_ФИНАЛ:
  если $балл > 50 то запретить
  иначе если $балл > 40 то пометить, как крайне подозрительное и разрешить
  иначе если $балл > 30 то пометить, как подозрительное и разрешить
  иначе разрешить

Ну, и по остальному функционалу различия примерно того же порядка, поэтому я рекомендую присмотреться к экзиму, пока еще постфикс не засосал.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 29-Дек-12, 15:26 
> Ну, и по остальному функционалу различия примерно того же порядка, поэтому я
> рекомендую присмотреться к экзиму, пока еще постфикс не засосал.

Это неправильно.
Я имею ввиду, что если сел разбираться, то разберись, - оставлять дела незаконченными не есть хорошо.

Постфикс меня вполне устраивает. Он производительнее сендмыла, легче в настройке. И документация как то... более структурирована что ли.

За экзим возьмусь позже, а пока надо разобраться с постфиксом.

У Вас есть что подсказать по моему вопросу? =)

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Andrey Mitrofanov on 29-Дек-12, 17:40 
>Он производительнее сендмыла,
>легче в настройке.
>И документация как то... более структурирована что ли.

Да! Ваши бенчмарки внушають.
Да! Настроил оба, с этим *всё* легче, а с тем упарился.
Да! Нашёл все ответы в документации. Такая правильнее.

Не, ну, раз всё легко и всё настроилось, то примите наши поздравления. А сложный и ненастроенный ....экзим? ...логично бросить и не тратить время на вопросы.

> За экзим возьмусь позже, а пока надо разобраться с постфиксом.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 29-Дек-12, 20:44 
> А сложный и ненастроенный ....экзим? ...логично бросить и не тратить время
> на вопросы.

Я ни в коем случае не пытаюсь развязать войну МТА или какой-нибудь холивар на эту тему.

Я лишь говорю, что потравтив время на постфикс было бы логично разобраться до конца) я потратил кучу времени, перечитал маны, две книги, но с ограничениями я так и не разобрался, у меня в голове каша, я просто прошу совета у тех, кто в своё время эту кашу расхлебал.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Гектор Зажигайло on 29-Дек-12, 20:53 
> Я ни в коем случае не пытаюсь развязать войну МТА или какой-нибудь
> холивар на эту тему.

Зря. Обожаю холивары и с удовольствием бы поучаствовал.

Exim отличный сервер, но в нём периодически обнаруживают такие уязвимости, с которыми лучше не сталкиваться пока нет 100% уверенности в своих силах.

Поэтому просто не обращайте внимание на фанатов экзима, они хотят заманить в свою секту как можно больше народа, чтобы те разделили из боль. Эффект сопереживания из психологии или как-то так

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 29-Дек-12, 21:05 
>> Я ни в коем случае не пытаюсь развязать войну МТА или какой-нибудь
>> холивар на эту тему.
> Зря. Обожаю холивары и с удовольствием бы поучаствовал.

Может быть я бы тоже поучаствовал, но я не использовал экзим.

Могу "попробовать" отстоять Сендмыл =)

> Exim отличный сервер, но в нём периодически обнаруживают такие уязвимости, с которыми
> лучше не сталкиваться пока нет 100% уверенности в своих силах.
> Поэтому просто не обращайте внимание на фанатов экзима, они хотят заманить в
> свою секту как можно больше народа, чтобы те разделили из боль.
> Эффект сопереживания из психологии или как-то так

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

16. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от DeadLoco (ok) on 31-Дек-12, 04:42 
> Exim отличный сервер, но в нём периодически обнаруживают такие уязвимости, с которыми
> лучше не сталкиваться пока нет 100% уверенности в своих силах.

Вы не могли бы привести пример хотя бы трех таких уязвимостей с указанием периода их обнаружения, а также с указанием примеров невозможности устранения этих уязвимостей штатными средствами обновления софтов?

Заранее благодарен за ответ.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

17. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Гектор Зажигайло on 31-Дек-12, 16:23 
> Вы не могли бы привести пример хотя бы трех таких уязвимостей с

Нее, не мог бы. Последний раз, когда я решился посмотреть (исключительно из любопытсва. Postfix отличный сервер и полностью меня устраивает) в сторону Exim'а в нём нашли такое:
http://www.exim.org/lurker/message/20101207.215955.bb32d4f2....

Т.е. возможность !!удалённо выполнять нехорошее с привилегиями root'а!! на моём сервере. Я мальчишка избалованный, привык, что привилегии root'а - это только мои привилегии. И мои заказчики точно не будут ждать третьей уязвимости и не будут анализировать невозможность устранения этих уязвимостей штатными средствами "обновления софтов". Мне просто перестанут деньги платить. Кроме того, написание кода, это как мышление - оно не меняется со временем. Поэтому нафиг.

Если вы сходите по вышеприведённой ссылке, там юноша сидел с tcpdump'ом и всё вдумчиво и грамотно расследовал, а здесь человек не до конца разобрался с текстовыми настройками, задокументированными по самые помидоры. Зачем ему такие сложности на старте ?

Поймите меня правильно: я не против Exim'a, я только за. Больше Exim'a - меньше конкурентов!

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от ALex_hha (??) on 31-Дек-12, 16:47 
> Я мальчишка избалованный, привык, что привилегии root'а - это только мои
> привилегии. И мои заказчики точно не будут ждать третьей уязвимости и
> не будут анализировать невозможность устранения этих уязвимостей штатными средствами
> "обновления софтов". Мне просто перестанут деньги платить.

с таким подходом вам надо не использовать интернет и linux вообще :) В ядре ведь тоже находят уязвимости, а то вдруг вам тоже перестанут деньги платить

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

20. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Гектор Зажигайло on 31-Дек-12, 19:00 
> с таким подходом вам надо не использовать интернет и linux вообще :)

А я linux и не использую :-) Не агритесь вы так. Я обожаю экзимку! С Новым Годом !

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

21. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от ALex_hha (??) on 01-Янв-13, 18:44 
>> с таким подходом вам надо не использовать интернет и linux вообще :)
> А я linux и не использую :-) Не агритесь вы так. Я
> обожаю экзимку! С Новым Годом !

и не думал, не являюсь слепым поклонником ни первого ни второго :)

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

19. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от DeadLoco (ok) on 31-Дек-12, 18:20 
>>> в нём периодически обнаруживают такие уязвимости, с которыми лучше не сталкиваться
>> Вы не могли бы привести пример хотя бы трех таких уязвимостей с
> Нее, не мог бы.

Какое-то из двух ваших утверждений является ложью, не так ли?

> Последний раз, когда я решился посмотреть (исключительно из
> любопытсва. Postfix отличный сервер и полностью меня устраивает) в сторону Exim'а
> в нём нашли такое:
> http://www.exim.org/lurker/message/20101207.215955.bb32d4f2....

Дебиан-релейтед дырку ставим в вину экзиму? Ню-ню... Плохой, плохой экзим!

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

4. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Гектор Зажигайло on 29-Дек-12, 20:27 
> Всем добрый день

Лев Толстой на проводе. Люди, которые специализируются на обработке информации, пропускают её через свои мозги в огромных количествах. Поэтому, очень часто, они болезненно воспринимают такие гигантские вопросы. Хотите получить качественные вопросы - будьте лаконичны.

Если кратко то, man 5 postconf

> При этом надо включать опцию:  smtpd_delay_reject = yes

Она включена по умолчанию.

smtpd_ХХХ_restrictions это на каком этапе что проверять. Т.е когда, а не что.

smtpd_recipient_restrictions = не что проверить для получателя, а что проверить когда придёт команда RCPT TO: mail@domain.tld

Сюда складывают по причинам:
а) всё в одном месте
а1) в лог пишется картина целиком: что, кто и кому.
б) только так можно сделать некоторые ящики всегда доступными. postmaster, abuse или ящик для ОСОБО ВАЖНОЙ ПОЧТЫ


Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Гектор Зажигайло on 29-Дек-12, 20:59 
>> Всем добрый день

и ещё я бы включил reject_sender_login_mismatch

Фишка в том, что сейчас куча народу понавтыкала spf (что правильно). Поэтому, если ваш пользователь будет слать через ваш сервер письма с from не вашими, то на том конце могут воспринять это неоднозначно. У меня одно время такие подсоединения банились. Хотя это уже через чур.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

10. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 29-Дек-12, 21:10 
>>> Всем добрый день
> и ещё я бы включил reject_sender_login_mismatch

в рабочем конфиге включена, но, опять же, я не уверен в правильной последовательности.

Более менее открывает глаза на происходящее эта статья:

http://freesource.info/wiki/Dokumentacija/Postfix/antispam/r...

но все равно остаются вопросы...


Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

8. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 29-Дек-12, 21:01 
> Лев Толстой на проводе. Люди, которые специализируются на обработке информации, пропускают
> её через свои мозги в огромных количествах. Поэтому, очень часто, они
> болезненно воспринимают такие гигантские вопросы. Хотите получить качественные вопросы
> - будьте лаконичны.

Пожалуй, я с Вами соглашусь.

Если кратко, то меня интересует почему в книге "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?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

11. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Гектор Зажигайло on 29-Дек-12, 21:25 
> Если кратко то, 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 in

smtpd_recipient_restrictions
    reject_rbl_client relays.ordb.org
Мне прислали команду rcpt to я проверил по чёрным спискам ай пи адрес

Но, я могу захотеть проверить а не постмастеру ли прислали письмо. Если прислали постмастеру, то я всяко хочу его принять. Вдруг там мой брат по разуму простит в белый список внести его криво настроенный сервер

Т.е. я могу сначала мейл проверить, а потом адрес айпи.


Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 29-Дек-12, 21:51 
>[оверквотинг удален]
> 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 работает в любом разделе, то так и есть, но правильно ли это?

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Гектор Зажигайло on 29-Дек-12, 22:11 
> Это понятно, а применительно к примеру из книги?

Пример из книги довольно логичен. А в вашем примере вы будете, например, проверять собственные адреса по rbl Нафига это надо ?

> Там проверка клиента по спискам (а значит это client_restrictions) идет последняя, что
> является более логичным. Но ведь это проверка на уровне client_restriction, а
> значит она должна применяться первой, хоть и стоит в самом низу?

Бред. Клиент прислал rcpt to пошли проверки из секции smtpd_recipient_restrictions в том порядке, в каком они там указаны. Проверки не на уровне. Проверки КОГДА они срабатывают. Не заморачивайтесь сейчас доп флагами, которые вы включаете.

Пришла команда RCPT TO запустились проверки из smtpd_recipient_restrictions в том порядке, в каком они там указаны и всё. Не надо никаких "на уровне"


> Значит, переписанный мной пример актуален? или всё же нет?

Пример ужасен.


Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Гектор Зажигайло on 29-Дек-12, 22:32 
> Пример ужасен.

Поскольку у вас всё равно включен флаг "отложить до rcpt to", то, разбив правила по группам, вы просто затруднили себе управление их порядком срабатывания

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 29-Дек-12, 22:51 
>> Пример ужасен.
> Поскольку у вас всё равно включен флаг "отложить до rcpt to", то,
> разбив правила по группам, вы просто затруднили себе управление их порядком
> срабатывания

Становится яснее

до RCPT TO я соберу всю необходимую информацию.

Правила выставляю согласно из силе. Например, если нету recipient в моих таблицах, то логично сразу сделать reject.

Если есть реципиент, то можно проверить валидность отправителя и так далее справа налево

Попробую переписать собственные ограничения, выложу здесь =)

Спасибо за ответы!

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

26. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 06-Янв-13, 02:30 
> Попробую переписать собственные ограничения, выложу здесь =)

Как и обещал, выкладываю конфиг.

Несколько примечаний:

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 = no

smtpd_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 SPAM

checks/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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

22. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Loly on 02-Янв-13, 13:58 
The Book of Postfix (Ральф Гильдебрандт, Патрик Кеттер)
Глава 7, в часности Таблицы 7.1 и 7.2 должны помочь Вам.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 02-Янв-13, 15:14 
> The Book of Postfix (Ральф Гильдебрандт, Патрик Кеттер)
> Глава 7, в часности Таблицы 7.1 и 7.2 должны помочь Вам.

Читал

Более того, я сюда оттуда примеры копировал =)

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

24. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от Loly on 02-Янв-13, 17:54 
> Читал

Из таблиц понятен порядок проверки рестрикшинсов:

_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


Что Вас смущает? (я как то уже потерялся)...

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

25. "smtpd_*_restrictions. Помогите пожалуйста разобраться"  +/
Сообщение от mr brightside (ok) on 03-Янв-13, 02:28 
> Что Вас смущает? (я как то уже потерялся)...

Гектор Зажигайло ранее ответил на мои вопросы

> Проверки КОГДА они срабатывают. Не заморачивайтесь сейчас
> доп флагами, которые вы включаете.
>
> Пришла команда RCPT TO запустились проверки из
> smtpd_recipient_restrictions в том порядке, в
> каком они там указаны и всё. Не надо никаких "на уровне"

Я запустался в том, как правильней указать рестрикшены.

dalay_checks отклыдвает проверки до RCPT TO, - и вот тут меня смущал факт наличия 7 групп для разбиваения проверок и схемой их управления.

Я колебался между указанием всего в "своем" разделе или указанием всего в одном разделе - recipient_restrictions.

Если раскидать ограничения по "своим" разделам, то управление оными усложняется, потому что они все равно применятся в том порядке, в котором они идут. Раз ограничения применяются "КОГДА", то логичней их кинуть в recipient_restrictions в нужном порядке - как и приведенный в книге пример.

Я просто не понимал ПОЧЕМУ этого нигде так не объяснено и думал, что правильным методом является указание ограничения в своем разделе.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру