Question about nested LDAP queries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about nested LDAP queries

Thomas GUIRRIEC

Hi all,

Just a little question.

I have configured Postfix  (3.5.8 from Alpine Linux) with "recipient_canonical_classes = envelope_recipient" & "recipient_canonical_maps = ldap:/etc/postfix/recipient_canonical" to rewrite envelope recepient by an OpenLDAP attribute (preferredRFC822recipient)

I also set "local_header_rewrite_clients = static:all"

When i inspect my OpenLDAP Logs, i see that there is two nested LDAP Search Queries coming from Postfix during the cleanup service.

The first use "%s" as value of LDAP filter.

The second use the value of preferedRFC822recipient :

5ff75ca0 conn=1002 fd=24 ACCEPT from IP=172.17.157.2:33452 (IP=0.0.0.0:389)
5ff75ca0 conn=1002 op=0 EXT oid=1.3.6.1.4.1.1466.20037
5ff75ca0 conn=1002 op=0 STARTTLS
5ff75ca0 conn=1002 op=0 RESULT oid= err=0 text=
5ff75ca0 conn=1002 fd=24 TLS established tls_ssf=256 ssf=256
5ff75ca0 conn=1002 op=1 SRCH base="o=guirriec,c=fr" scope=2 deref=0 filter=[hidden email]
5ff75ca0 conn=1002 op=1 SRCH attr=preferredRFC822recipient
5ff75ca0 conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
5ff75ca0 conn=1002 op=2 SRCH base="o=guirriec,c=fr" scope=2 deref=0 filter=[hidden email]
5ff75ca0 conn=1002 op=2 SRCH attr=preferredRFC822recipient
5ff75ca0 conn=1002 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=

I have enabled debug_peer_list, and verbose mode on smtpd, cleanup and trivial-rewrite.

Here is the partial cleaning output corresponding of both :

cleanup[86]: initial envelope A [hidden email]
cleanup[86]: initial envelope R [hidden email]
cleanup[86]: send attr request = rewrite
cleanup[86]: send attr rule = local
cleanup[86]: send attr address = [hidden email]
trivial-rewrite[85]: master_notify: status 0
trivial-rewrite[85]: rewrite socket: wanted attribute: request
trivial-rewrite[85]: input attribute name: request
trivial-rewrite[85]: input attribute value: rewrite
trivial-rewrite[85]: rewrite socket: wanted attribute: rule
trivial-rewrite[85]: input attribute name: rule
trivial-rewrite[85]: input attribute value: local
trivial-rewrite[85]: rewrite socket: wanted attribute: address
trivial-rewrite[85]: input attribute name: address
trivial-rewrite[85]: input attribute value: [hidden email]
trivial-rewrite[85]: rewrite socket: wanted attribute: (list terminator)
trivial-rewrite[85]: input attribute name: (end)
trivial-rewrite[85]: `local' `[hidden email]' -> `[hidden email]'
trivial-rewrite[85]: send attr flags = 0
trivial-rewrite[85]: send attr address = [hidden email]
trivial-rewrite[85]: master_notify: status 1
cleanup[86]: private/rewrite socket: wanted attribute: flags
cleanup[86]: input attribute name: flags
cleanup[86]: input attribute value: 0
cleanup[86]: private/rewrite socket: wanted attribute: address
cleanup[86]: input attribute name: address
cleanup[86]: input attribute value: [hidden email]
cleanup[86]: private/rewrite socket: wanted attribute: (list terminator)
cleanup[86]: input attribute name: (end)
cleanup[86]: rewrite_clnt: local: [hidden email] -> [hidden email]
cleanup[86]: dict_ldap_lookup: In dict_ldap_lookup
cleanup[86]: match_string: /etc/postfix/recipient_canonical: guirriec.fr ~? guirriec.fr
cleanup[86]: dict_ldap_lookup: No existing connection for LDAP source /etc/postfix/recipient_canonical, reopening
cleanup[86]: dict_ldap_connect: Connecting to server ldap://ldap-guirriec
cleanup[86]: dict_ldap_connect: Actual Protocol version used is 3.
smtpd[83]: vstream_buf_get_ready: fd 9 got 6
smtpd[83]: < unknown[10.253.133.242]: DATA
smtpd[83]: rec_put: type M len 0 data 
smtpd[83]: rec_put: type N len 56 data Received: 
smtpd[83]: rec_put: type N len 60 data ?by mailhu
smtpd[83]: rec_put: type N len 67 data ?for <bob@
smtpd[83]: > unknown[10.253.133.242]: 354 End data with <CR><LF>.<CR><LF>
smtpd[83]: vstream_fflush_some: fd 9 flush 37
smtpd[83]: vstream_buf_get_ready: fd 9 got 76
smtpd[83]: rec_put: type N len 26 data From: send
smtpd[83]: rec_put: type N len 25 data To: bob@gu
smtpd[83]: rec_put: type N len 13 data Subject: T
smtpd[83]: rec_put: type N len 4 data test
smtpd[83]: rec_put: type X len 0 data 
smtpd[83]: rec_put: type E len 0 data 
smtpd[83]: vstream_fflush_some: fd 23 flush 271
cleanup[86]: dict_ldap_connect: Cached connection handle for LDAP source /etc/postfix/recipient_canonical
cleanup[86]: dict_ldap_lookup: /etc/postfix/recipient_canonical: Searching with filter ([hidden email])
cleanup[86]: dict_ldap_get_values[1]: Search found 1 match(es)
cleanup[86]: dict_ldap_get_values[1]: search returned 1 value(s) for requested result attribute preferredRFC822recipient
cleanup[86]: dict_ldap_get_values[1]: Leaving dict_ldap_get_values
cleanup[86]: dict_ldap_lookup: Search returned [hidden email]
cleanup[86]: maps_find: recipient_canonical_maps: ldap:/etc/postfix/recipient_canonical(0,lock|fold_fix|utf8_request): [hidden email] = [hidden email]
cleanup[86]: mail_addr_find: [hidden email] -> [hidden email]
cleanup[86]: send attr request = rewrite
cleanup[86]: send attr rule = local
cleanup[86]: send attr address = [hidden email]
trivial-rewrite[85]: master_notify: status 0
trivial-rewrite[85]: rewrite socket: wanted attribute: request
trivial-rewrite[85]: input attribute name: request
trivial-rewrite[85]: input attribute value: rewrite
trivial-rewrite[85]: rewrite socket: wanted attribute: rule
trivial-rewrite[85]: input attribute name: rule
trivial-rewrite[85]: input attribute value: local
trivial-rewrite[85]: rewrite socket: wanted attribute: address
trivial-rewrite[85]: input attribute name: address
trivial-rewrite[85]: input attribute value: [hidden email]
trivial-rewrite[85]: rewrite socket: wanted attribute: (list terminator)
trivial-rewrite[85]: input attribute name: (end)
trivial-rewrite[85]: `local' `[hidden email]' -> `[hidden email]'
trivial-rewrite[85]: send attr flags = 0
trivial-rewrite[85]: send attr address = [hidden email]
trivial-rewrite[85]: master_notify: status 1
cleanup[86]: private/rewrite socket: wanted attribute: flags
cleanup[86]: input attribute name: flags
cleanup[86]: input attribute value: 0
cleanup[86]: private/rewrite socket: wanted attribute: address
cleanup[86]: input attribute name: address
cleanup[86]: input attribute value: [hidden email]
cleanup[86]: private/rewrite socket: wanted attribute: (list terminator)
cleanup[86]: input attribute name: (end)
cleanup[86]: rewrite_clnt: local: [hidden email] -> [hidden email]
cleanup[86]: mail_addr_map: [hidden email] -> 0: [hidden email]
cleanup[86]: dict_ldap_lookup: In dict_ldap_lookup
cleanup[86]: match_string: /etc/postfix/recipient_canonical: guirriec.fr ~? guirriec.fr
cleanup[86]: dict_ldap_lookup: Using existing connection for LDAP source /etc/postfix/recipient_canonical
cleanup[86]: dict_ldap_lookup: /etc/postfix/recipient_canonical: Searching with filter ([hidden email])
cleanup[86]: dict_ldap_get_values[1]: Search found 1 match(es)
cleanup[86]: dict_ldap_get_values[1]: search returned 1 value(s) for requested result attribute preferredRFC822recipient
cleanup[86]: dict_ldap_get_values[1]: Leaving dict_ldap_get_values
cleanup[86]: dict_ldap_lookup: Search returned [hidden email]
cleanup[86]: maps_find: recipient_canonical_maps: ldap:/etc/postfix/recipient_canonical(0,lock|fold_fix|utf8_request): [hidden email] = [hidden email]
cleanup[86]: mail_addr_find: [hidden email] -> [hidden email]
cleanup[86]: rewrite_clnt: cached: local: [hidden email] -> [hidden email]
cleanup[86]: mail_addr_map: [hidden email] -> 0: [hidden email]
cleanup[86]: been_here: [hidden email]: 0
cleanup[86]: initial envelope M 

I don't understand why Postix does the second LDAP Query with ([hidden email]) filter .

Can someone explain me ?

Best regards.

Thomas

Reply | Threaded
Open this post in threaded view
|

Re: Question about nested LDAP queries

Viktor Dukhovni
On Thu, Jan 07, 2021 at 10:24:23PM +0100, Thomas GUIRRIEC wrote:

> I have configured Postfix  (3.5.8 from Alpine Linux) with
> "recipient_canonical_classes = envelope_recipient" &
> "recipient_canonical_maps = ldap:/etc/postfix/recipient_canonical" to

Why would you do this?   Envelope recipient rewriting is already done
automatically by "virtual_alias_maps".  There's no need to shoehorn
recipient_canonical_maps into this role.

> When i inspect my OpenLDAP Logs, i see that there is two nested LDAP
> Search Queries coming from Postfix during the cleanup service.

Both recipient_canonical_maps and virtual_alias_maps are recursive.

    http://www.postfix.org/postconf.5.html#canonical_maps

     Specify zero or more "type:name" lookup tables, separated by
     whitespace or comma. Tables will be searched in the specified order
     until a match is found. Note: these lookups are recursive.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Question about nested LDAP queries

Thomas GUIRRIEC
Thank you for your reply and for the tip with virtual_alias.

So, if i understand, virtual_alias and canonical  always do recursive
lookup until the key equals the value (with LDAP table) :

A -> A (STOP)

A -> B; B -> B (STOP)

A -> B; B -> C; C-> C (STOP)

Is that correct ?

Best regards.

Le 07/01/2021 à 23:04, Viktor Dukhovni a écrit :

> On Thu, Jan 07, 2021 at 10:24:23PM +0100, Thomas GUIRRIEC wrote:
>
>> I have configured Postfix  (3.5.8 from Alpine Linux) with
>> "recipient_canonical_classes = envelope_recipient" &
>> "recipient_canonical_maps = ldap:/etc/postfix/recipient_canonical" to
> Why would you do this?   Envelope recipient rewriting is already done
> automatically by "virtual_alias_maps".  There's no need to shoehorn
> recipient_canonical_maps into this role.
>
>> When i inspect my OpenLDAP Logs, i see that there is two nested LDAP
>> Search Queries coming from Postfix during the cleanup service.
> Both recipient_canonical_maps and virtual_alias_maps are recursive.
>
>      http://www.postfix.org/postconf.5.html#canonical_maps
>
>       Specify zero or more "type:name" lookup tables, separated by
>       whitespace or comma. Tables will be searched in the specified order
>       until a match is found. Note: these lookups are recursive.
>
Reply | Threaded
Open this post in threaded view
|

Re: Question about nested LDAP queries

Wietse Venema
Thomas GUIRRIEC:

> Thank you for your reply and for the tip with virtual_alias.
>
> So, if i understand, virtual_alias and canonical? always do recursive
> lookup until the key equals the value (with LDAP table) :
>
> A -> A (STOP)
>
> A -> B; B -> B (STOP)
>
> A -> B; B -> C; C-> C (STOP)
>
> Is that correct ?

Surprisingly, the search also terminates when the answer is 'not found'.

        Wietse