Добрый день, предлагаю вашему вниманию мои соображения по поводу не совсем "чистой" обработки 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:
/.*/ OKsmtpd_recipient_restrictions =
check_sender_access ldap:/usr/local/etc/postfix/sender.cf,
local,
rejectwhere /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 мне кажется более прозрачным с точки зрения
идеологии.
>я оформил свои "иследования" для postfix-users@postfix.org.К несчастью ничего интереного моя переписка с
>англоязычными колегами мне не принесла, поэтому решил искать правды у своих
>:)
А, что вы хотите услышать???
Могу как "свой" повторить слова ВиктОра по-русски...
>>я оформил свои "иследования" для postfix-users@postfix.org.К несчастью ничего интереного моя переписка с
>>англоязычными колегами мне не принесла, поэтому решил искать правды у своих
>>:)
>А, что вы хотите услышать???
>Могу как "свой" повторить слова ВиктОра по-русски...дык не смог мил человек убедить меня в непраильности моих размышлений :)
основоной аргумент был что мол нельзя юзать класс напрямую в рестрикшенах, когда в мане четко написанно что можно...и второе схема-то работает не первый день тестил (щас правда через hash)
а почему в ldap глючит я превел выдержки из логов...и в код не поленился залезть. Там действительно идет тупая проверка всех возможных комбинаций логин, домен + екстеншен...вот мне и не понятно, зачем ввожить ключи, если всеравно поиск ими не ограничен ?
>>Могу как "свой" повторить слова ВиктОра по-русски...
>дык не смог мил человек убедить меня в непраильности моих размышлений :)
А ткните меня носом в message-id его аргументов.PS:
sorry остальное (пока) поскипал - домой пора.
>>>Могу как "свой" повторить слова ВиктОра по-русски...
>>дык не смог мил человек убедить меня в непраильности моих размышлений :)
>А ткните меня носом в 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...это заявление вообще вызвало у меня недоумение, на что я эмоционально (надо было держать себя в руках) поинтересовался о его познаниях в парсинге переменных и алиасов :)
и после этого все забили...
>>>дык не смог мил человек убедить меня в непраильности моих размышлений
>>А ткните меня носом в message-id его аргументов.
>Виктор не особо озадачил себя аргументированием, отмахнувшись абстрактным
Если возможно дайте все-таки message-id (у меня mutt почему-то побил эту ветку на части с разным скорингом, а нормально читать через веб не могу...)
>>>>дык не смог мил человек убедить меня в непраильности моих размышлений
>>>А ткните меня носом в message-id его аргументов.
>>Виктор не особо озадачил себя аргументированием, отмахнувшись абстрактным
>Если возможно дайте все-таки message-id166672 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
>>Если возможно дайте все-таки message-id
>166772 Re: Maybe design error in lookup mechanism Michaylov Michael
> Thu 3/3/2005
Спасибо.
Покажите пожалуста _полный_ вывод smtpd -v
>>>Если возможно дайте все-таки message-id
>>166772 Re: Maybe design error in lookup mechanism Michaylov Michael
>> Thu 3/3/2005
>Спасибо.
>Покажите пожалуста _полный_ вывод smtpd -vMar 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.
тогда ихняя механика останится прежней, а использование ключей будет приводить к ожидаемым результатам
да совсем забыл...у меня куча внутрених доменов .vtg
для каждого отдела...в логе пример с доменом it.vtg
дальше после прохода все чеков адрес через cannonical mapping транслируется во внешний vtg.com.uaи вот и менно из-за наличия у меня пользовательской части vtg (vtg@vtg.com.ua) и происходит глюк...ну а дальше я просто полез уже во внутрености и наткнулся на такую вот обработку
>но как мне кажется в случае с использованием query_filter и %[usd] ключей
>этот символ "@", должен прописыватся автоматом, чего не делается.
Пардон. Кто и где обещал то, что при подстовке %u "@" будет включен в запрос???
>думаю если ВСЕ мои рассуждения верны нужно сделать патч, который будет при
>наличии ключа %u добовлять к username части окончание "@" или перфикс
>"@" перед доменной частью в случаи с %d.
>тогда ихняя механика останится прежней, а использование ключей будет приводить к ожидаемым
>результатам
Ожидаемым _вами_, но не другими...
>Пардон. Кто и где обещал то, что при подстовке %u "@" будет
>включен в запрос???согласен с такой формулировкой..но ее я вывел после того как залез в исходники, где просто идет перебор всего и вся пока не найдется какой-нить результат.
>Ожидаемым _вами_, но не другими...
в документации четко указано что поиск задается по ключам, %u - юзерская часть, %d - домнная, так скажите мне на милость почему в строку ...uid=%u парсается домен причем по всем его состовляющим ?
я делаю postmap -q все прекрасно...в выводе я вижу свой query_filter и его содержимое, а в работе smtpd такой подарок ?!
>>Пардон. Кто и где обещал то, что при подстовке %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 определен свой _набор_ _порядок_ запросов.
>Почему при 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 люди спешат с выводами...
>P.S. жаль что на postfix-user@postfix.org люди спешат с выводами...
Скажите (только честно), что ВиктОр был прав в первом ответе вам:
"Message-ID: <20050302152440.GI28114@piias899.ms.com>"
>>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 и неправильном понимании ключей. Но до туда обсуждение почему-то не дошло...
>хм..при всем желании, я не вижу ничего правильного или полезного :(
>он сфокусировал все на конфиге, а именно на smtpd_recipient_restrictions =
Так как бы там и описан порядок запросов...>и "wrong on so many levels" кажется мне несколько предвзятым высказыванием
Ну я не могу читаеть чужие мысли и не знаю что именно он имел в виду, но например ваш pcre кривоват...>моя же ошибка заключалась в query_filter и неправильном понимании ключей. Но до
>туда обсуждение почему-то не дошло...
Я думаю, что его задела ваша постановка вапроса (с напором - ребята у вас баг)...
А после вашего ответа mouse (я согласен с вами - воинствующий ламер) вам действительно никто не ответит - там не принят такой стиль :)