The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Postfix 2.1.5 старнное опереирование ключами в query_filter"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от dust emailИскать по авторуВ закладки(ok) on 04-Мрт-05, 15:06  (MSK)
Добрый день, предлагаю вашему вниманию мои соображения по поводу не совсем "чистой" обработки query_filter в postfix table lookup механизме.

я оформил свои "иследования" для postfix-users@postfix.org.К несчастью ничего интереного моя переписка с англоязычными колегами мне не принесла, поэтому решил искать правды у своих :)


[Описание]
систуация следующего характера:

нужно распределить доступ между пользователями домена vtg.com.ua, на тех
кто может посылать почту за его пределы и тех кто может пользоватся
почтой только в его пределах.

[Решение]
smtpd_restriction_classes = local, remote
local = check_recipient_access pcre:/usr/local/etc/postfix/maps/local
remote = check_recipient_access pcre:/usr/local/etc/postfix/maps/remote

/usr/local/etc/postfix/maps/local has:
/vtg.com.ua/    OK
/.*/            REJECT local account

/usr/local/etc/postfix/maps/remote has:
/.*/    OK

smtpd_recipient_restrictions =
check_sender_access ldap:/usr/local/etc/postfix/sender.cf,
local,
reject

where /usr/local/etc/postfix/sender.cf has
search_base = cn=remote, ou=groups, dc=vtg
query_filter = member=uid=%u
result_attribute = cn

формат записи в ldap базе:
member=uid=<username1>
member=uid=<username2>
member=uid=<username3>
cn=remote

идея заключается в следующем: username part of email address, которому
разрешено посылать почту во внешний мир хранится в ветке
cn=remote,ou=groups,dc=vtg, при уcпешном поиске должно вернутся поле cn,
которое содержит описанный выше класс remote

[Проблема]
Проблема заключается в следующем механизме обработки поиска, пример из
лог файла:

dict_ldap_lookup: Searching with filter member=uid=strait
dict_ldap_lookup: Search returned nothing
dict_ldap_lookup: Searching with filter member=uid=it.vtg
dict_ldap_lookup: Search returned nothing
dict_ldap_lookup: Searching with filter member=uid=vtg (1)

как видите поиск происходит не только по %u как указано в query_filter =
member=uid=%u а по всем словам встречающимся в адресе

поскольку у меня существует пользователь vtg@vtg.com.ua, находящийся в
групе доступа (member=uid=vtg), срабатывает поиск в последней строке (1)
dict_ldap_lookup: Search returned remote
в результате чего ВСЕ письма будут отправлятся наружу независимо от
наличия/отсутсвия пользователя в списке доступа.

между прочим, команда postmap работает коректно:
при условии что username находится в списке разрешенных,
команда postmap -q username@domain.vtg
ldap:/usr/local/etc/postfix/sender.cf возвращает remote, если отсутсвует
nothing.

более детальный просмотр с ключем -v показывает только один поиск с
query_filter = member=uid=username, а не 3 как в логе работы smtpd

[Выводы]
мне кажется что метод проверки адреса реализованный в
smtpd/smtpd_check.c function check_mail_access не соответсвует идеологии
использования ключей %[usd] для определения query_filter, возможно имеет
смысл пересмотреть эту механику.

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

  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

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

1. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от unk Искать по авторуВ закладки(ok) on 04-Мрт-05, 16:56  (MSK)
>я оформил свои "иследования" для postfix-users@postfix.org.К несчастью ничего интереного моя переписка с
>англоязычными колегами мне не принесла, поэтому решил искать правды у своих
>:)
А, что вы хотите услышать???
Могу как "свой" повторить слова ВиктОра по-русски...
  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от dust emailИскать по авторуВ закладки(ok) on 04-Мрт-05, 17:01  (MSK)
>>я оформил свои "иследования" для postfix-users@postfix.org.К несчастью ничего интереного моя переписка с
>>англоязычными колегами мне не принесла, поэтому решил искать правды у своих
>>:)
>А, что вы хотите услышать???
>Могу как "свой" повторить слова ВиктОра по-русски...

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

и второе схема-то работает не первый день тестил (щас правда через hash)
а почему в ldap глючит я превел выдержки из логов...и в код не поленился залезть. Там действительно идет тупая проверка всех возможных комбинаций логин, домен + екстеншен...вот мне и не понятно, зачем ввожить ключи, если всеравно поиск ими не ограничен ?

  Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от unk Искать по авторуВ закладки(ok) on 04-Мрт-05, 17:06  (MSK)
>>Могу как "свой" повторить слова ВиктОра по-русски...
>дык не смог мил человек убедить меня в непраильности моих размышлений :)
А ткните меня носом в message-id его аргументов.

PS:
sorry остальное (пока) поскипал - домой пора.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от dust emailИскать по авторуВ закладки(ok) on 04-Мрт-05, 17:23  (MSK)
>>>Могу как "свой" повторить слова ВиктОра по-русски...
>>дык не смог мил человек убедить меня в непраильности моих размышлений :)
>А ткните меня носом в message-id его аргументов.

Виктор не особо озадачил себя аргументированием, отмахнувшись абстрактным
Even higher up than that. The structure of your proposed restrictions
is wrong regardless of the table contents

после моей попытки детального описания работы моей схемы появился некий mouss <usebsd@free,fr>, заявивший следующее:

>> smtpd_recipient_restrictions =
>> check_sender_access ldap:/usr/local/etc/postfix/sender.cf,
>> local,

>there's no such thing as "local" in smtpd_muble_restrictions. back to
>postconf(5)? use _only_ one of the allowed statements.

кстате именно в этом мане (парвда в другом разделе) четко написанно что можно, привожу выдержку:

"smtpd_restriction_classes (default: empty)

User-defined aliases for groups of access restrictions. The
aliases CAN BE SPECIFIED in smtpd_recipient_restrictions etc.,
and on the right-hand side of a Postfix access(5) table."


>> so, if "*check_sender_access*" returns something then search ends
>> if search returns nothing, postfix checks next condition - class LOCAL.

>no, it won't. It's ok for a check to return a class, it's not ok for a
>class to turn a check...

это заявление вообще вызвало у меня недоумение, на что я эмоционально (надо было держать себя в руках) поинтересовался о его познаниях в парсинге переменных и алиасов :)

и после этого все забили...

  Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от unk Искать по авторуВ закладки(ok) on 04-Мрт-05, 18:21  (MSK)
>>>дык не смог мил человек убедить меня в непраильности моих размышлений
>>А ткните меня носом в message-id его аргументов.
>Виктор не особо озадачил себя аргументированием, отмахнувшись абстрактным
Если возможно дайте все-таки message-id (у меня mutt почему-то побил эту ветку на части с разным скорингом, а нормально читать через веб не могу...)
  Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от dust emailИскать по авторуВ закладки(ok) on 04-Мрт-05, 18:53  (MSK)
>>>>дык не смог мил человек убедить меня в непраильности моих размышлений
>>>А ткните меня носом в message-id его аргументов.
>>Виктор не особо озадачил себя аргументированием, отмахнувшись абстрактным
>Если возможно дайте все-таки message-id

166672 Re: Maybe design error in lookup mechanism Victor Duchovni    Wed  3/2/2005
166677 Re: Maybe design error in lookup mechanism Michaylov Michael    Wed  3/2/2005
166679 Re: Maybe design error in lookup mechanism Victor Duchovni    Wed  3/2/2005
166687 Re: Maybe design error in lookup mechanism Victor Duchovni    Wed  3/2/2005
166697 Re: Maybe design error in lookup mechanism Michaylov Michael    Wed  3/2/2005
166702 Re: Maybe design error in lookup mechanism Michaylov Michael    Wed  3/2/2005
166720 Re: Maybe design error in lookup mechanism mouss    Wed  3/2/2005
166772 Re: Maybe design error in lookup mechanism Michaylov Michael    Thu  3/3/2005

  Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от unk Искать по авторуВ закладки(ok) on 04-Мрт-05, 20:06  (MSK)
>>Если возможно дайте все-таки message-id
>166772  Re: Maybe design error in lookup mechanism  Michaylov Michael
>    Thu  3/3/2005
Спасибо.
Покажите пожалуста _полный_ вывод smtpd -v

  Рекомендовать в FAQ | Cообщить модератору | Наверх

8. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от dust emailИскать по авторуВ закладки(ok) on 04-Мрт-05, 20:22  (MSK)
>>>Если возможно дайте все-таки message-id
>>166772  Re: Maybe design error in lookup mechanism  Michaylov Michael
>>    Thu  3/3/2005
>Спасибо.
>Покажите пожалуста _полный_ вывод smtpd -v

Mar  4 19:09:41 gate postfix/smtpd[80704]: connect from solar.it.vtg[192.168.30.165]
Mar  4 19:09:41 gate postfix/smtpd[80704]: dict_ldap_lookup: Searching with filter (&(mail=strait@it.vtg)(objectClass=CourierMailAccount))
Mar  4 19:09:41 gate postfix/smtpd[80704]: dict_ldap_lookup: Search returned strait
Mar  4 19:09:41 gate postfix/cleanup[79496]: 750C08342: message-id=<20050304170941.750C08342@core.vtg.com.ua>
Mar  4 19:09:41 gate postfix/qmgr[75633]: 750C08342: from=<postmaster@vtg.com.ua>, size=254, nrcpt=1 (queue active)
Mar  4 19:09:41 gate postfix/virtual[80705]: 750C08342: to=<strait@it.vtg>, relay=virtual, delay=0, status=deliverable (delivers to maildir)
Mar  4 19:09:41 gate postfix/qmgr[75633]: 750C08342: removed

тут идет поиск на соответсвие логина и почты (reject_sender_login_mismatch у меня sasl авторизация), потом проверка на существование отправителя (reject_unverified_sender)

Mar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Searching with filter member=uid=strait
Mar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Search returned nothing
Mar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Searching with filter member=uid=it.vtg
Mar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Search returned nothing
Mar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Searching with filter member=uid=vtg
Mar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Search returned remote
Mar  4 19:09:44 gate postfix/smtpd[80704]: check_table_result: ldap:/usr/local/etc/postfix/sender.cf remote it.vtg
Mar  4 19:09:44 gate postfix/smtpd[80704]: check_table_result: pcre:/usr/local/etc/postfix/maps/remote OK strait@rootshell.beMar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Searching with filter (&(mail=strait@rootshell.be)(objectClass=CourierMailAlias))
Mar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Search returned nothing
Mar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Searching with filter (&(mail=@rootshell.be)(objectClass=CourierMailAlias))
Mar  4 19:09:44 gate postfix/smtpd[80704]: dict_ldap_lookup: Search returned nothing
Mar  4 19:09:44 gate postfix/smtpd[80704]: 7C6C88344: client=solar.it.vtg[192.168.30.165], sasl_method=LOGIN, sasl_username=strait
Mar  4 19:09:44 gate postfix/cleanup[79496]: 7C6C88344: message-id=<1109956181.9578.1.camel@solar.it.vtg>
Mar  4 19:09:44 gate postfix/smtpd[80704]: disconnect from solar.it.vtg[192.168.30.165]
Mar  4 19:09:44 gate postfix/qmgr[75633]: 7C6C88344: from=<strait@vtg.com.ua>, size=596, nrcpt=1 (queue active)
Mar  4 19:09:45 gate postfix/pickup[75632]: 11BBD834C: uid=1010 from=<strait@vtg.com.ua>
Mar  4 19:09:45 gate postfix/pipe[80706]: 7C6C88344: to=<strait@rootshell.be>, relay=myfilter, delay=1, status=sent (dummy)
Mar  4 19:09:45 gate postfix/qmgr[75633]: 7C6C88344: removed
Mar  4 19:09:45 gate postfix/cleanup[79496]: 11BBD834C: message-id=<1109956181.9578.1.camel@solar.it.vtg>
Mar  4 19:09:45 gate postfix/qmgr[75633]: 11BBD834C: from=<strait@vtg.com.ua>, size=786, nrcpt=1 (queue active)
Mar  4 19:09:46 gate postfix/smtp[79497]: 11BBD834C: to=<strait@rootshell.be>, relay=boogey.rootshell.be[217.22.55.49], delay=1, status=sent (250 Ok: queued as 0517B2D58F)
Mar  4 19:09:46 gate postfix/qmgr[75633]: 11BBD834C: removed

впринципе читая документацию и исходники я пришел к выводу что оплошность допустили вот в чем:

если хотят делать проверку на username часть а потом на domain.name пусть делают, НО !!! у них не всегда идет проверка символа "@"...

тоесть есть ли речь идет про hash - без проблем, я сам указываю:
username@      some_class
@domain.name   some_class

но как мне кажется в случае с использованием query_filter и %[usd] ключей этот символ "@", должен прописыватся автоматом, чего не делается.

думаю если ВСЕ мои рассуждения верны нужно сделать патч, который будет при наличии ключа %u добовлять к username части окончание "@" или перфикс "@" перед доменной частью в случаи с %d.

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

  Рекомендовать в FAQ | Cообщить модератору | Наверх

9. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от dust emailИскать по авторуВ закладки(ok) on 04-Мрт-05, 20:34  (MSK)
да совсем забыл...у меня куча внутрених доменов .vtg
для каждого отдела...в логе пример с доменом it.vtg
дальше после прохода все чеков адрес через cannonical mapping транслируется во внешний vtg.com.ua

и вот и менно из-за наличия у меня пользовательской части vtg (vtg@vtg.com.ua) и происходит глюк...ну а дальше я просто полез уже во внутрености и наткнулся на такую вот обработку

  Рекомендовать в FAQ | Cообщить модератору | Наверх

10. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от unk Искать по авторуВ закладки(ok) on 04-Мрт-05, 20:45  (MSK)
>но как мне кажется в случае с использованием query_filter и %[usd] ключей
>этот символ "@", должен прописыватся автоматом, чего не делается.
Пардон. Кто и где обещал то, что при подстовке %u "@" будет включен в запрос???


>думаю если ВСЕ мои рассуждения верны нужно сделать патч, который будет при
>наличии ключа %u добовлять к username части окончание "@" или перфикс
>"@" перед доменной частью в случаи с %d.
>тогда ихняя механика останится прежней, а использование ключей будет приводить к ожидаемым
>результатам
Ожидаемым _вами_, но не другими...

  Рекомендовать в FAQ | Cообщить модератору | Наверх

11. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от dust emailИскать по авторуВ закладки(ok) on 04-Мрт-05, 20:52  (MSK)
>Пардон. Кто и где обещал то, что при подстовке %u "@" будет
>включен в запрос???

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

>Ожидаемым _вами_, но не другими...

в документации четко указано что поиск задается по ключам, %u - юзерская часть, %d - домнная, так скажите мне на милость почему в строку ...uid=%u парсается домен причем по всем его состовляющим ?

я делаю postmap -q все прекрасно...в выводе я вижу свой query_filter и его содержимое, а в работе smtpd такой подарок ?!

  Рекомендовать в FAQ | Cообщить модератору | Наверх

12. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от unk Искать по авторуВ закладки(ok) on 04-Мрт-05, 21:00  (MSK)
>>Пардон. Кто и где обещал то, что при подстовке %u "@" будет
>>включен в запрос???
>согласен с такой формулировкой..но ее я вывел после того как залез в
>исходники, где просто идет перебор всего и вся пока не найдется
>какой-нить результат.
Вы передергиваете!
Здесь четко смотрим user@full.domain.tld, full.domain.tld, domain.tld tld, user

>>Ожидаемым _вами_, но не другими...
>
>в документации четко указано что поиск задается по ключам, %u - юзерская
>часть, %d - домнная, так скажите мне на милость почему в
>строку ...uid=%u парсается домен причем по всем его состовляющим ?
Порядок запроса смотрите выше.
Почему при uid=%u подставляется домен:
When the input key is an address of the form
user@domain, %u  is  replaced  by  the  (RFC
2254) quoted local part of the address. Oth-
erwise, %u is replaced by the entire  search
string.

>я делаю postmap -q все прекрасно...в выводе я вижу свой query_filter и
>его содержимое, а в работе smtpd такой подарок ?!
postmap туп - все что он умеет - спросить _буквально_ то что вы хотите.
smtpd(8) гибок - для каждого smtpd_foo_restriction определен свой _набор_ _порядок_  запросов.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

13. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от dust emailИскать по авторуВ закладки(ok) on 04-Мрт-05, 21:19  (MSK)
>Почему при uid=%u подставляется домен:
>When the input key is an address of the form
>user@domain, %u  is  replaced  by  the  (RFC
>
>2254) quoted local part of the address. Oth-
>erwise, %u is replaced by the entire  search
>string.

что ж это уже кое что :)

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

P.S. жаль что на postfix-user@postfix.org люди спешат с выводами...

  Рекомендовать в FAQ | Cообщить модератору | Наверх

14. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от unk Искать по авторуВ закладки(ok) on 04-Мрт-05, 21:22  (MSK)
>P.S. жаль что на postfix-user@postfix.org люди спешат с выводами...
Скажите (только честно), что ВиктОр был прав в первом ответе вам:
"Message-ID: <20050302152440.GI28114@piias899.ms.com>"

  Рекомендовать в FAQ | Cообщить модератору | Наверх

15. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от dust emailИскать по авторуВ закладки(ok) on 04-Мрт-05, 21:49  (MSK)
>>P.S. жаль что на postfix-user@postfix.org люди спешат с выводами...
>Скажите (только честно), что ВиктОр был прав в первом ответе вам:
>"Message-ID: <20050302152440.GI28114@piias899.ms.com>"

его ответ:
Stop right there and go back to basics. Read books, online docs, list
archives, ... until you understand restrictions a lot better. This
is wrong on so many levels it is hard to know where to start.

        http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt
        http://www.postfix.org/SMTPD_ACCESS_README.html
        http://www.postfix.org/RESTRICTION_CLASS_README.html

хм..при всем желании, я не вижу ничего правильного или полезного :(
он сфокусировал все на конфиге, а именно на smtpd_recipient_restrictions = ...
и "wrong on so many levels" кажется мне несколько предвзятым высказыванием

моя же ошибка заключалась в query_filter и неправильном понимании ключей. Но до туда обсуждение почему-то не дошло...

  Рекомендовать в FAQ | Cообщить модератору | Наверх

16. "Postfix 2.1.5 старнное опереирование ключами в query_filter"
Сообщение от unk Искать по авторуВ закладки(ok) on 04-Мрт-05, 21:56  (MSK)
>хм..при всем желании, я не вижу ничего правильного или полезного :(
>он сфокусировал все на конфиге, а именно на smtpd_recipient_restrictions =
Так как бы там и описан порядок запросов...

>и "wrong on so many levels" кажется мне несколько предвзятым высказыванием
Ну я не могу читаеть чужие мысли и не знаю что именно он имел в виду, но например ваш pcre кривоват...

>моя же ошибка заключалась в query_filter и неправильном понимании ключей. Но до
>туда обсуждение почему-то не дошло...
Я думаю, что его задела ваша постановка вапроса (с напором - ребята у вас баг)...
А после вашего ответа mouse (я согласен с вами - воинствующий ламер) вам действительно никто не ответит - там не принят такой стиль :)

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

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




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

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