smtpd_recipient_restrictions with ldap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

smtpd_recipient_restrictions with ldap

Paolo Barbato
Hi.

I’m using following rules in main.cf

smtpd_recipient_restrictions = permit_mynetworks,    check_recipient_access regexp:/opt/trend/imss/postfix/etc/postfix/access,    reject_unauth_pipelining,    reject_non_fqdn_recipient,    reject_unknown_recipient_domain,    reject_unauth_destination, ldap:ldaprfx, reject

where ldaprfx is configured with

ldaprfx_server_host = xx
ldaprfx_search_base = dc=cgprouter
ldaprfx_query_filter = mail=%s
ldaprfx_result_attribute = mail
ldaprfx_result_scope = one
ldaprfx_result_format = OK %s
ldaprfx_version = 3

I see not existent mail correctly denied with 451, but an error is logged in maillog

Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: dict_ldap_lookup: ldaprfx: Search base 'dc=cgprouter' not found: 32: No such object
Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: ldap:ldaprfx: table lookup problem
Apr  3 15:23:04 mail2 postfix/smtpd[11180]: NOQUEUE: reject: RCPT from unknown[xxx: 451 4.3.5 <[hidden email]>: Recipient address rejected: Server configuration error; from=<xx@xxx> to=<xx@xx> proto=ESMTP helo=<xxx>

Is there a way to avoid ldap warnings ?

Is it expected to see logging "Server configuration error" ?


Here what ldapsearch returns:

ldapsearch -v -LLL -hxxxx -b"dc=cgprouter" -x -s one 'mail=notexist@xx'
ldap_initialize( ldap://xxx)
filter: mail=notexist@xxx
requesting: All userApplication attributes
No such object (32)
Additional information: unknown user account

Thanks for any hints .


Regards,
Paolo.


------------------------------------------------------------------------------------------------
Paolo Barbato

Consorzio RFX
corso Stati Uniti,4                                  
35127 Padova - Italy                                    
Network Administrator
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Brett @Google
This is not a warning, it is an error, your base might be wrong. your ldapsearch test would return the same result even if the base was wrong.. try searching for something that exists.. open yourldap with a ldap gui and cut and paste the base, or better test your search config file with postmap -q as that does what postfix does

server configuration error means the ldap query is failing entirely, not that the email is not found, so its something that caused the query to fail, a successful query succeeds but return 0 results, not an error, which is what you are getting..

Cheers
Brett

> On 4 Apr 2017, at 4:48 pm, Paolo Barbato <[hidden email]> wrote:
>
> Hi.
>
> I’m using following rules in main.cf
>
> smtpd_recipient_restrictions = permit_mynetworks,    check_recipient_access regexp:/opt/trend/imss/postfix/etc/postfix/access,    reject_unauth_pipelining,    reject_non_fqdn_recipient,    reject_unknown_recipient_domain,    reject_unauth_destination, ldap:ldaprfx, reject
>
> where ldaprfx is configured with
>
> ldaprfx_server_host = xx
> ldaprfx_search_base = dc=cgprouter
> ldaprfx_query_filter = mail=%s
> ldaprfx_result_attribute = mail
> ldaprfx_result_scope = one
> ldaprfx_result_format = OK %s
> ldaprfx_version = 3
>
> I see not existent mail correctly denied with 451, but an error is logged in maillog
>
> Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: dict_ldap_lookup: ldaprfx: Search base 'dc=cgprouter' not found: 32: No such object
> Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: ldap:ldaprfx: table lookup problem
> Apr  3 15:23:04 mail2 postfix/smtpd[11180]: NOQUEUE: reject: RCPT from unknown[xxx: 451 4.3.5 <[hidden email]>: Recipient address rejected: Server configuration error; from=<xx@xxx> to=<xx@xx> proto=ESMTP helo=<xxx>
>
> Is there a way to avoid ldap warnings ?
>
> Is it expected to see logging "Server configuration error" ?
>
>
> Here what ldapsearch returns:
>
> ldapsearch -v -LLL -hxxxx -b"dc=cgprouter" -x -s one 'mail=notexist@xx'
> ldap_initialize( ldap://xxx)
> filter: mail=notexist@xxx
> requesting: All userApplication attributes
> No such object (32)
> Additional information: unknown user account
>
> Thanks for any hints .
>
>
> Regards,
> Paolo.
>
>
> ------------------------------------------------------------------------------------------------
> Paolo Barbato
>
> Consorzio RFX
> corso Stati Uniti,4                                  
> 35127 Padova - Italy                                          
> Network Administrator
> phone: +39 049 8295097 fax: +39 049 8700718
> ------------------------------------------------------------------------------------------------
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Paolo Barbato
Hi Brett,

yes 4.3.5 is really an error, but when a valid user is found no error is returned.

Such problem arise since ldap return 32: No such object.

[root@mail2 openldap]# postmap -q [hidden email] ldap:/opt/trend/imss/OpenLDAP/etc/openldap/myBad.cf
OK [hidden email]

[root@mail2 openldap]# postmap -q [hidden email] ldap:/opt/trend/imss/OpenLDAP/etc/openldap/myBad.cf
postmap: warning: dict_ldap_lookup: /opt/trend/imss/OpenLDAP/etc/openldap/myBad.cf: Search base 'dc=cgprouter' not found: 32: No such object

Regards,
Paolo.



> On 4 Apr 2017, at 10:35, Brett Maxfield <[hidden email]> wrote:
>
> This is not a warning, it is an error, your base might be wrong. your ldapsearch test would return the same result even if the base was wrong.. try searching for something that exists.. open yourldap with a ldap gui and cut and paste the base, or better test your search config file with postmap -q as that does what postfix does
>
> server configuration error means the ldap query is failing entirely, not that the email is not found, so its something that caused the query to fail, a successful query succeeds but return 0 results, not an error, which is what you are getting..
>
> Cheers
> Brett
>
>> On 4 Apr 2017, at 4:48 pm, Paolo Barbato <[hidden email]> wrote:
>>
>> Hi.
>>
>> I’m using following rules in main.cf
>>
>> smtpd_recipient_restrictions = permit_mynetworks,    check_recipient_access regexp:/opt/trend/imss/postfix/etc/postfix/access,    reject_unauth_pipelining,    reject_non_fqdn_recipient,    reject_unknown_recipient_domain,    reject_unauth_destination, ldap:ldaprfx, reject
>>
>> where ldaprfx is configured with
>>
>> ldaprfx_server_host = xx
>> ldaprfx_search_base = dc=cgprouter
>> ldaprfx_query_filter = mail=%s
>> ldaprfx_result_attribute = mail
>> ldaprfx_result_scope = one
>> ldaprfx_result_format = OK %s
>> ldaprfx_version = 3
>>
>> I see not existent mail correctly denied with 451, but an error is logged in maillog
>>
>> Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: dict_ldap_lookup: ldaprfx: Search base 'dc=cgprouter' not found: 32: No such object
>> Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: ldap:ldaprfx: table lookup problem
>> Apr  3 15:23:04 mail2 postfix/smtpd[11180]: NOQUEUE: reject: RCPT from unknown[xxx: 451 4.3.5 <[hidden email]>: Recipient address rejected: Server configuration error; from=<xx@xxx> to=<xx@xx> proto=ESMTP helo=<xxx>
>>
>> Is there a way to avoid ldap warnings ?
>>
>> Is it expected to see logging "Server configuration error" ?
>>
>>
>> Here what ldapsearch returns:
>>
>> ldapsearch -v -LLL -hxxxx -b"dc=cgprouter" -x -s one 'mail=notexist@xx'
>> ldap_initialize( ldap://xxx)
>> filter: mail=notexist@xxx
>> requesting: All userApplication attributes
>> No such object (32)
>> Additional information: unknown user account
>>
>> Thanks for any hints .
>>
>>
>> Regards,
>> Paolo.
>>
>>
>> ------------------------------------------------------------------------------------------------
>> Paolo Barbato
>>
>> Consorzio RFX
>> corso Stati Uniti,4                                  
>> 35127 Padova - Italy                                          
>> Network Administrator
>> phone: +39 049 8295097 fax: +39 049 8700718
>> ------------------------------------------------------------------------------------------------
>>

------------------------------------------------------------------------------------------------
Paolo Barbato

Consorzio RFX
corso Stati Uniti,4                                  
35127 Padova - Italy                                    
Network Administrator
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Michael Ströder
Paolo Barbato wrote:
> postmap: warning: dict_ldap_lookup: /opt/trend/imss/OpenLDAP/etc/openldap/myBad.cf:
> Search base 'dc=cgprouter' not found: 32: No such object

As Brett already said: Most likely this configuration line is wrong:

ldaprfx_search_base = dc=cgprouter

Make sure to put the right search base served by your LDAP server there (full DN of
database root entry).

Ciao, Michael.


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Paolo Barbato
I use CommuniGate as mailer and they allow a “virtual" ldap tree (very useful in my specific situation) that use dc=cgprouter as base search.


Trouble arise since ldap search returns "No object found” error that broke postfix when the user doesn/t exist.

If I search on another provisioned ldap search base (that unfortunately doesn’t include all objects I’m looking for) no problem arise.

[root@mail2 openldap]# ldapsearch -v -LLL -hmail1.igi.cnr.it -b"cn=igi.cnr.it,o=Consorzio RFX"  -x uid=barbat
ldap_initialize( <a href="ldap://mail1.igi.cnr.it" class="">ldap://mail1.igi.cnr.it )
filter: uid=barbat
requesting: All userApplication attributes

[root@mail2 openldap]# ldapsearch -v -LLL -hmail1.igi.cnr.it -b"dc=cgprouter"  -x uid=barbat
ldap_initialize( <a href="ldap://mail1.igi.cnr.it" class="">ldap://mail1.igi.cnr.it )
filter: uid=barbat
requesting: All userApplication attributes
No such object (32)
Additional information: unknown user account


The latter broke postfix .

I’ve notified them about this, but I guess if can workaround it in postfix…. it seems not.

Regards,
Paolo.

On 4 Apr 2017, at 12:22, Michael Ströder <[hidden email]> wrote:

Paolo Barbato wrote:
postmap: warning: dict_ldap_lookup: /opt/trend/imss/OpenLDAP/etc/openldap/myBad.cf:
Search base 'dc=cgprouter' not found: 32: No such object

As Brett already said: Most likely this configuration line is wrong:

ldaprfx_search_base = dc=cgprouter

Make sure to put the right search base served by your LDAP server there (full DN of
database root entry).

Ciao, Michael.


------------------------------------------------------------------------------------------------
Paolo Barbato

Consorzio RFX
corso Stati Uniti,4                                  
35127 Padova - Italy                                       
Network Administrator 
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Brett @Google
The documentation on that link says dc=cgprouter is virtual, which means it literally wont exist in ldap (wont be found), maybe its an error in the way the mapping is configured, it only rewrites children of that virtual domain to the matching ldap.. so maybe you need to ask the developers of the ldap mapping product ? 

have you tried try omitting the base and simply searching base "" on the virtual ldap ? or adding a mapping option that allows a search at that virtual base to apparently succeed, so it does not throw a not found on that base when there is nothing matched ?

On 4 Apr 2017, at 8:35 pm, Paolo Barbato <[hidden email]> wrote:

I use CommuniGate as mailer and they allow a “virtual" ldap tree (very useful in my specific situation) that use dc=cgprouter as base search.


Trouble arise since ldap search returns "No object found” error that broke postfix when the user doesn/t exist.

If I search on another provisioned ldap search base (that unfortunately doesn’t include all objects I’m looking for) no problem arise.

[root@mail2 openldap]# ldapsearch -v -LLL -hmail1.igi.cnr.it -b"cn=igi.cnr.it,o=Consorzio RFX"  -x uid=barbat
ldap_initialize( <a href="ldap://mail1.igi.cnr.it" class="">ldap://mail1.igi.cnr.it )
filter: uid=barbat
requesting: All userApplication attributes

[root@mail2 openldap]# ldapsearch -v -LLL -hmail1.igi.cnr.it -b"dc=cgprouter"  -x uid=barbat
ldap_initialize( <a href="ldap://mail1.igi.cnr.it" class="">ldap://mail1.igi.cnr.it )
filter: uid=barbat
requesting: All userApplication attributes
No such object (32)
Additional information: unknown user account


The latter broke postfix .

I’ve notified them about this, but I guess if can workaround it in postfix…. it seems not.

Regards,
Paolo.

On 4 Apr 2017, at 12:22, Michael Ströder <[hidden email]> wrote:

Paolo Barbato wrote:
postmap: warning: dict_ldap_lookup: /opt/trend/imss/OpenLDAP/etc/openldap/myBad.cf:
Search base 'dc=cgprouter' not found: 32: No such object

As Brett already said: Most likely this configuration line is wrong:

ldaprfx_search_base = dc=cgprouter

Make sure to put the right search base served by your LDAP server there (full DN of
database root entry).

Ciao, Michael.


------------------------------------------------------------------------------------------------
Paolo Barbato

Consorzio RFX
corso Stati Uniti,4                                  
35127 Padova - Italy                                       
Network Administrator 
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Paolo Barbato

On 4 Apr 2017, at 13:16, Brett Maxfield <[hidden email]> wrote:

The documentation on that link says dc=cgprouter is virtual, which means it literally wont exist in ldap (wont be found), maybe its an error in the way the mapping is configured, it only rewrites children of that virtual domain to the matching ldap.. so maybe you need to ask the developers of the ldap mapping product ? 


I’ve suggested to CommuniGate developers to return empty result and not an error 32, if "object”  (mail, alias, forwarder, ...) doesn’t exist, since this the only way to grant interoperability with postfix, but I believe with other MTA.

 
Regards,
Paolo.



have you tried try omitting the base and simply searching base "" on the virtual ldap ? or adding a mapping option that allows a search at that virtual base to apparently succeed, so it does not throw a not found on that base when there is nothing matched ?

On 4 Apr 2017, at 8:35 pm, Paolo Barbato <[hidden email]> wrote:

I use CommuniGate as mailer and they allow a “virtual" ldap tree (very useful in my specific situation) that use dc=cgprouter as base search.


Trouble arise since ldap search returns "No object found” error that broke postfix when the user doesn/t exist.

If I search on another provisioned ldap search base (that unfortunately doesn’t include all objects I’m looking for) no problem arise.

[root@mail2 openldap]# ldapsearch -v -LLL -hmail1.igi.cnr.it -b"cn=igi.cnr.it,o=Consorzio RFX"  -x uid=barbat
ldap_initialize( <a href="ldap://mail1.igi.cnr.it" class="">ldap://mail1.igi.cnr.it )
filter: uid=barbat
requesting: All userApplication attributes

[root@mail2 openldap]# ldapsearch -v -LLL -hmail1.igi.cnr.it -b"dc=cgprouter"  -x uid=barbat
ldap_initialize( <a href="ldap://mail1.igi.cnr.it" class="">ldap://mail1.igi.cnr.it )
filter: uid=barbat
requesting: All userApplication attributes
No such object (32)
Additional information: unknown user account


The latter broke postfix .

I’ve notified them about this, but I guess if can workaround it in postfix…. it seems not.

Regards,
Paolo.

On 4 Apr 2017, at 12:22, Michael Ströder <[hidden email]> wrote:

Paolo Barbato wrote:
postmap: warning: dict_ldap_lookup: /opt/trend/imss/OpenLDAP/etc/openldap/myBad.cf:
Search base 'dc=cgprouter' not found: 32: No such object

As Brett already said: Most likely this configuration line is wrong:

ldaprfx_search_base = dc=cgprouter

Make sure to put the right search base served by your LDAP server there (full DN of
database root entry).

Ciao, Michael.


------------------------------------------------------------------------------------------------
Paolo Barbato

Consorzio RFX
corso Stati Uniti,4                                  
35127 Padova - Italy                                       
Network Administrator 
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------


------------------------------------------------------------------------------------------------
Paolo Barbato

Consorzio RFX
corso Stati Uniti,4                                  
35127 Padova - Italy                                       
Network Administrator 
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Christian Rößner
In reply to this post by Paolo Barbato
Hi,

> Am 04.04.2017 um 08:48 schrieb Paolo Barbato <[hidden email]>:
>
> smtpd_recipient_restrictions =
...
> ldap:ldaprfx,
...

Maybe I am wrong, but aren't you missing a keyword here? Something like check_sender_access or check_recipient_access or vice versa?

...
check_XYZ_access ldap:ldaprfx,
...

Christian
--
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Paolo Barbato
Hi Christian,  the keyword can be omitted see http://postfix.1071664.n5.nabble.com/smtpd-recipient-restrictions-multiple-tables-in-check-recipient-access-td86603.html

Regards,
Paolo.

On 4 Apr 2017, at 16:53, Christian Rößner <[hidden email]> wrote:

Hi,

Am 04.04.2017 um 08:48 schrieb Paolo Barbato <[hidden email]>:

smtpd_recipient_restrictions =
...
ldap:ldaprfx,
...

Maybe I am wrong, but aren't you missing a keyword here? Something like check_sender_access or check_recipient_access or vice versa?

...
check_XYZ_access ldap:ldaprfx,
...

Christian
--
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345


------------------------------------------------------------------------------------------------
Paolo Barbato

Consorzio RFX
corso Stati Uniti,4                                  
35127 Padova - Italy                                       
Network Administrator 
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Christian Rößner

> Am 04.04.2017 um 17:04 schrieb Paolo Barbato <[hidden email]>:
>
> Hi Christian,  the keyword can be omitted see http://postfix.1071664.n5.nabble.com/smtpd-recipient-restrictions-multiple-tables-in-check-recipient-access-td86603.html

I just read the official documentation (man 5 postconf) under smtpd_recipient_restrictions. I do not see that your config is valid.

>> ...
>> check_XYZ_access ldap:ldaprfx,
>> ...

Give it a try and report back

Christian
--
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345


smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Viktor Dukhovni
In reply to this post by Christian Rößner

> On Apr 4, 2017, at 10:53 AM, Christian Rößner <[hidden email]> wrote:
>
>> smtpd_recipient_restrictions =
> ...
>> ldap:ldaprfx,
> ...
>
> Maybe I am wrong, but aren't you missing a keyword here? Something like check_sender_access or check_recipient_access or vice versa?
>
> ...
> check_XYZ_access ldap:ldaprfx,

The "check_recipient_access" is implied, and though such
implicit use is discouraged, this is not the OP's problem.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Christian Rößner

> Am 04.04.2017 um 17:22 schrieb Viktor Dukhovni <[hidden email]>:
>
>
>> On Apr 4, 2017, at 10:53 AM, Christian Rößner <[hidden email]> wrote:
>>
>>> smtpd_recipient_restrictions =
>> ...
>>> ldap:ldaprfx,
>> ...
>>
>> Maybe I am wrong, but aren't you missing a keyword here? Something like check_sender_access or check_recipient_access or vice versa?
>>
>> ...
>> check_XYZ_access ldap:ldaprfx,
>
> The "check_recipient_access" is implied, and though such
> implicit use is discouraged, this is not the OP's problem.
Yes, you are right. I did not read carefully enough. Sorry.

Does the CGPro support replication? Maybe you could add a consumer to your MTA. That way, you had a fixed known base. Non existent entries would probably not result in error 32 for that fixed base DN.

Just an idea.

Christian
--
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Viktor Dukhovni
In reply to this post by Paolo Barbato
On Tue, Apr 04, 2017 at 08:48:33AM +0200, Paolo Barbato wrote:

> I’m using following rules in main.cf
>
> smtpd_recipient_restrictions =
> permit_mynetworks,
> check_recipient_access regexp:/opt/trend/imss/postfix/etc/postfix/access,
> reject_unauth_pipelining,
> reject_non_fqdn_recipient,
> reject_unknown_recipient_domain,
> reject_unauth_destination,
> ldap:ldaprfx,
> reject

Using access(5) to perform recipient validation is not the preferred
way to reject non-existent recipients.  Instead, make sure each domain
appears in the appropriate address class (see ADDRESS_CLASS_README),
and configure the corresponding recipient vaidation tables.

For better performance, change "ldap:ldaprfx" to "proxy:ldap:ldaprfx",
and consider moving the table definition out of main.cf into a
".cf" file.

> ldaprfx_server_host = xx
> ldaprfx_search_base = dc=cgprouter
> ldaprfx_query_filter = mail=%s
> ldaprfx_result_attribute = mail
> ldaprfx_result_scope = one
> ldaprfx_result_format = OK %s
> ldaprfx_version = 3
>
> I see not existent mail correctly denied with 451, but an error is logged in maillog
>
> Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: dict_ldap_lookup: ldaprfx: Search base 'dc=cgprouter' not found: 32: No such object

The LDAP server should not deny the existence of the search base.

> Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: ldap:ldaprfx: table lookup problem
> Apr  3 15:23:04 mail2 postfix/smtpd[11180]: NOQUEUE: reject: RCPT from unknown[xxx: 451 4.3.5 <[hidden email]>: Recipient address rejected: Server configuration error; from=<xx@xxx> to=<xx@xx> proto=ESMTP helo=<xxx>

Then you'll be able to reject invalid recipients with a 5XX permanent
error, and avoid noisy warnings in the log.

> Is it expected to see logging "Server configuration error" ?

Yes, because your search base is invalid

> Here what ldapsearch returns:
>
> ldapsearch -v -LLL -hxxxx -b"dc=cgprouter" -x -s one 'mail=notexist@xx'
> ldap_initialize( ldap://xxx)
> filter: mail=notexist@xxx
> requesting: All userApplication attributes
> No such object (32)

The "No such object" error is undesirable, instead, this should
quietly return no result.

Postfix ignores "no such object" only when the search base is
constructed dynamically via "%[sud]" expansions.

What do the DNs of valid users look like?  There's a slim chance
that you can interpolate part of the recipient address into the
search base, and thereby avoid the error.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Viktor Dukhovni
On Tue, Apr 04, 2017 at 04:02:34PM +0000, Viktor Dukhovni wrote:

> > Here what ldapsearch returns:
> >
> > ldapsearch -v -LLL -hxxxx -b"dc=cgprouter" -x -s one 'mail=notexist@xx'
> > ldap_initialize( ldap://xxx)
> > filter: mail=notexist@xxx
> > requesting: All userApplication attributes
> > No such object (32)
>
> The "No such object" error is undesirable, instead, this should
> quietly return no result.
>
> Postfix ignores "no such object" only when the search base is
> constructed dynamically via "%[sud]" expansions.
>
> What do the DNs of valid users look like?  There's a slim chance
> that you can interpolate part of the recipient address into the
> search base, and thereby avoid the error.

Turns out you're in luck:

    https://www.communigate.com/communigatepro/LDAP.html#RouterDN

It seems you can use 'record retrieval':

    search_base = mail=%s,dc=cgprouter
    scope = base
    query_filter = mail=%s
    result_attribute = mail

Earlier comments still apply.  It is not clear why you'd want to
delegate access decisions from Postfix to a Communigate system,
but if that's what you want, so be it...

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Paolo Barbato
In reply to this post by Viktor Dukhovni
Hi Viktor,

Il giorno 04/apr/2017, alle ore 18.02, Viktor Dukhovni ha scritto:

On Tue, Apr 04, 2017 at 08:48:33AM +0200, Paolo Barbato wrote:

I’m using following rules in main.cf

smtpd_recipient_restrictions =
permit_mynetworks,
check_recipient_access regexp:/opt/trend/imss/postfix/etc/postfix/access,
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unauth_destination,
ldap:ldaprfx,
reject

Using access(5) to perform recipient validation is not the preferred
way to reject non-existent recipients.  Instead, make sure each domain
appears in the appropriate address class (see ADDRESS_CLASS_README),
and configure the corresponding recipient vaidation tables.

on the edge I'm using TrendMicro IMSVA  that bundle postix 2.7.x as MTA.
Postfix configurations files  are maintained via some web forms available on main IMSVA web console.
It's possible to activate check on recipients against multiple ldap servers. A local openldap server is then put in place acting as local cache. 

In production main.cf file include an entry for ldap:ldapimsva.

Since CGPro virtual search base dc=cgprouter is not directly configurable via IMSVA, now I understand why (error 32), I've tried to add a separate instance ldap:ldaprfx in main.cf manually.
   

For better performance, change "ldap:ldaprfx" to "proxy:ldap:ldaprfx",
and consider moving the table definition out of main.cf into a
".cf" file.


Very effective suggestions, although if CGPro developers will accept my proposal, I'm confident that I'll be able to add CGPro virtual base directly using IMSVA web console.


Regards,
Paolo.


ldaprfx_server_host = xx
ldaprfx_search_base = dc=cgprouter
ldaprfx_query_filter = mail=%s
ldaprfx_result_attribute = mail
ldaprfx_result_scope = one
ldaprfx_result_format = OK %s
ldaprfx_version = 3

I see not existent mail correctly denied with 451, but an error is logged in maillog

Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: dict_ldap_lookup: ldaprfx: Search base 'dc=cgprouter' not found: 32: No such object

The LDAP server should not deny the existence of the search base.

Apr  3 15:23:04 mail2 postfix/smtpd[11180]: warning: ldap:ldaprfx: table lookup problem
Apr  3 15:23:04 mail2 postfix/smtpd[11180]: NOQUEUE: reject: RCPT from unknown[xxx: 451 4.3.5 <[hidden email]>: Recipient address rejected: Server configuration error; from=<xx@xxx> to=<xx@xx> proto=ESMTP helo=<xxx>

Then you'll be able to reject invalid recipients with a 5XX permanent
error, and avoid noisy warnings in the log.

Is it expected to see logging "Server configuration error" ?

Yes, because your search base is invalid

Here what ldapsearch returns:

ldapsearch -v -LLL -hxxxx -b"dc=cgprouter" -x -s one 'mail=notexist@xx'
ldap_initialize( <a href="ldap://xxx">ldap://xxx)
filter: mail=notexist@xxx
requesting: All userApplication attributes
No such object (32)

The "No such object" error is undesirable, instead, this should
quietly return no result.

Postfix ignores "no such object" only when the search base is
constructed dynamically via "%[sud]" expansions.

What do the DNs of valid users look like?  There's a slim chance
that you can interpolate part of the recipient address into the
search base, and thereby avoid the error.

--
Viktor.

------------------------------------------------------------------------------------------------
Paolo Barbato

corso Stati Uniti,4                                  
35127 Padova - Italy                                        
Network Administrator 
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Viktor Dukhovni

> On Apr 4, 2017, at 12:30 PM, Paolo Barbato <[hidden email]> wrote:
>
>> For better performance, change "ldap:ldaprfx" to "proxy:ldap:ldaprfx"
>
> Very effective suggestions, although if CGPro developers
> will accept my proposal, I'm confident that I'll be able
> to add CGPro virtual base directly using IMSVA web console.

When using LDAP in the Postfix SMTP server (smtpd(8)), it
is important to use "proxy:ldap:..." instead of "ldap:..."
when defining LDAP tables.  This significantly reduces the
number of concurrent connections seen by the LDAP server.
Many LDAP servers are not prepared to handle hundreds to
thousands of simultaneous connections.

In some cases you may need to augment "proxy_read_maps"
with the tables you intend to use.

Recent Postfix versions have a default settings of:

  $ postconf -fd proxy_read_maps
  proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
    $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
    $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
    $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
    $smtpd_sender_login_maps $sender_bcc_maps $recipient_bcc_maps
    $smtp_generic_maps $lmtp_generic_maps $alias_maps $smtpd_client_restrictions
    $smtpd_helo_restrictions $smtpd_sender_restrictions
    $smtpd_relay_restrictions $smtpd_recipient_restrictions

which covers all the tables listed in the various restriction lists.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Paolo Barbato
Viktor,

here new ldaprfx.cf

server_host = 150.178.3.89:389
bind=no
search_base = mail=%s,dc=cgprouter
scope = base
query_filter = mail=%s
result_attribute = mail
result_format = OK %s
version = 3

here postmap check
[root@mail2 postfix]# postmap -q [hidden email] ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf
[root@mail2 postfix]# 
[root@mail2 postfix]# postmap -q [hidden email] ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf


thats really fine.

....but after inserted ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf in main.cf  an new error come up "warning: dict_ldap_lookup: Search error 1: Operations error " and Server configuration error is there again.

?

I've anyway just receive a feedback from CGPro developers that I share as promised:

For 6.2c3 (later this April):
LDAP: search for non-routable address under the dc=cgprouter base now returns empty result rather than routing error.

Th request with scope=base still returns error if the address can notbe routed.

Regards,
Paolo


Il giorno 04/apr/2017, alle ore 18.39, Viktor Dukhovni ha scritto:


On Apr 4, 2017, at 12:30 PM, Paolo Barbato <[hidden email]> wrote:

For better performance, change "ldap:ldaprfx" to "proxy:ldap:ldaprfx"

Very effective suggestions, although if CGPro developers
will accept my proposal, I'm confident that I'll be able
to add CGPro virtual base directly using IMSVA web console.

When using LDAP in the Postfix SMTP server (smtpd(8)), it
is important to use "proxy:ldap:..." instead of "ldap:..."
when defining LDAP tables.  This significantly reduces the
number of concurrent connections seen by the LDAP server.
Many LDAP servers are not prepared to handle hundreds to
thousands of simultaneous connections.

In some cases you may need to augment "proxy_read_maps"
with the tables you intend to use.

Recent Postfix versions have a default settings of:

 $ postconf -fd proxy_read_maps
 proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
   $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
   $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
   $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
   $smtpd_sender_login_maps $sender_bcc_maps $recipient_bcc_maps
   $smtp_generic_maps $lmtp_generic_maps $alias_maps $smtpd_client_restrictions
   $smtpd_helo_restrictions $smtpd_sender_restrictions
   $smtpd_relay_restrictions $smtpd_recipient_restrictions

which covers all the tables listed in the various restriction lists.

--
Viktor.


------------------------------------------------------------------------------------------------
Paolo Barbato

corso Stati Uniti,4                                  
35127 Padova - Italy                                        
Network Administrator 
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Viktor Dukhovni

> On Apr 4, 2017, at 3:35 PM, Paolo Barbato <[hidden email]> wrote:
>
> here new ldaprfx.cf
>
> server_host = 150.178.3.89:389
> bind=no
> search_base = mail=%s,dc=cgprouter
> scope = base
> query_filter = mail=%s
> result_attribute = mail
> result_format = OK %s
> version = 3
>
> here postmap check
> [root@mail2 postfix]# postmap -q [hidden email] ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf
> [root@mail2 postfix]#
> [root@mail2 postfix]# postmap -q [hidden email] ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf
> OK [hidden email]
>
>
> thats really fine.
>
> ....but after inserted ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf in main.cf  an new error come up "warning: dict_ldap_lookup: Search error 1: Operations error " and Server configuration error is there again.

And the reason you're not posting the "postconf -n" output showing the
new settings and the full error message (and any related log entries)
is ...?

Do test making the query as a non-root user.  Do check whether your
SMTP server processes are chrooted and perhaps can't connect to LDAP
servers as a result.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Brett @Google
In reply to this post by Paolo Barbato
On Wed, Apr 5, 2017 at 5:35 AM, Paolo Barbato <[hidden email]> wrote:

I've anyway just receive a feedback from CGPro developers that I share as promised:

For 6.2c3 (later this April):
LDAP: search for non-routable address under the dc=cgprouter base now returns empty result rather than routing error.

Th request with scope=base still returns error if the address can notbe routed.
It's lucky they will fix it, i was about to suggest using openldap with the meta backend instead as it seems an odd behavior for an ldap meant for mailers.

The answer to the following used a openldap server, with some shared entries, with a meta backend to allow querying of several seperate servers as one :

http://serverfault.com/questions/106869/how-can-i-proxy-multiple-ldap-servers-and-still-have-grouping-of-users-on-the-p

A similar setup, but with a different solution. Probably simpler to keep using your same product, if they fix the empty base search.

Cheers
Brett
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: smtpd_recipient_restrictions with ldap

Paolo Barbato
In reply to this post by Viktor Dukhovni

On 5 Apr 2017, at 01:08, Viktor Dukhovni <[hidden email]> wrote:


On Apr 4, 2017, at 3:35 PM, Paolo Barbato <[hidden email]> wrote:

here new ldaprfx.cf

server_host = 150.178.3.89:389
bind=no
search_base = mail=%s,dc=cgprouter
scope = base
query_filter = mail=%s
result_attribute = mail
result_format = OK %s
version = 3

here postmap check
[root@mail2 postfix]# postmap -q [hidden email] ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf
[root@mail2 postfix]#
[root@mail2 postfix]# postmap -q [hidden email] ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf
OK [hidden email]


thats really fine.

....but after inserted ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf in main.cf  an new error come up "warning: dict_ldap_lookup: Search error 1: Operations error " and Server configuration error is there again.

And the reason you're not posting the "postconf -n" output showing the
new settings and the full error message (and any related log entries)
is …?
I’ve tried before arranging an amend part, but good old majordomo explain that it posted for soem reasons..

here another try:

Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 5a 02 01 01 63 55 04  22 6d 61 69 6c 3d 75 6d   0Z...cU."mail=um
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  65 61 69 40 69 67 69 2e  63 6e 72 2e 69 74 2c 64   [hidden email],d
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  63 3d 63 67 70 72 6f 75  74 65 72 0a 01 00 0a 01   c=cgprouter.....
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  00 02 01 00 02 01 0a 01  01 00 a3 18 04 04 6d 61   ..............ma
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0040:  69 6c 04 10 75 6d 65 61  69 40 69 67 69 2e 63 6e   [hidden email]
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0050:  72 2e 69 74 30 06 04 04  6d 61 69 6c               r.it0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_write: want=92, written=92
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 5a 02 01 01 63 55 04  22 6d 61 69 6c 3d 75 6d   0Z...cU."mail=um
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  65 61 69 40 69 67 69 2e  63 6e 72 2e 69 74 2c 64   [hidden email],d
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  63 3d 63 67 70 72 6f 75  74 65 72 0a 01 00 0a 01   c=cgprouter.....
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  00 02 01 00 02 01 0a 01  01 00 a3 18 04 04 6d 61   ..............ma
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0040:  69 6c 04 10 75 6d 65 61  69 40 69 67 69 2e 63 6e   [hidden email]
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0050:  72 2e 69 74 30 06 04 04  6d 61 69 6c               r.it0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=8, got=8
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 20 02 01 01 65 1b 0a                            0 ...e..
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=26, got=26
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  01 20 04 00 04 14 75 6e  6b 6e 6f 77 6e 20 75 73   . ....unknown us
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  65 72 20 61 63 63 6f 75  6e 74                     er account
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: request done: ld 0x812ab00 msgid 1
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 4e 02 01 02 63 49 04  1c 6d 61 69 6c 3d 69 67   0N...cI..mail=ig
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  69 2e 63 6e 72 2e 69 74  2c 64 63 3d 63 67 70 72   i.cnr.it,dc=cgpr
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  6f 75 74 65 72 0a 01 00  0a 01 00 02 01 00 02 01   outer...........
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  0a 01 01 00 a3 12 04 04  6d 61 69 6c 04 0a 69 67   ........mail..ig
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0040:  69 2e 63 6e 72 2e 69 74  30 06 04 04 6d 61 69 6c   i.cnr.it0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_write: want=80, written=80
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 4e 02 01 02 63 49 04  1c 6d 61 69 6c 3d 69 67   0N...cI..mail=ig
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  69 2e 63 6e 72 2e 69 74  2c 64 63 3d 63 67 70 72   i.cnr.it,dc=cgpr
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  6f 75 74 65 72 0a 01 00  0a 01 00 02 01 00 02 01   outer...........
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  0a 01 01 00 a3 12 04 04  6d 61 69 6c 04 0a 69 67   ........mail..ig
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0040:  69 2e 63 6e 72 2e 69 74  30 06 04 04 6d 61 69 6c   i.cnr.it0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=8, got=8
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 20 02 01 02 65 1b 0a                            0 ...e..
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=26, got=26
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  01 20 04 00 04 14 75 6e  6b 6e 6f 77 6e 20 75 73   . ....unknown us
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  65 72 20 61 63 63 6f 75  6e 74                     er account
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: request done: ld 0x812ab00 msgid 2
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 46 02 01 03 63 41 04  18 6d 61 69 6c 3d 63 6e   0F...cA..mail=cn
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  72 2e 69 74 2c 64 63 3d  63 67 70 72 6f 75 74 65   r.it,dc=cgproute
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  72 0a 01 00 0a 01 00 02  01 00 02 01 0a 01 01 00   r...............
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  a3 0e 04 04 6d 61 69 6c  04 06 63 6e 72 2e 69 74   ....mail..cnr.it
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0040:  30 06 04 04 6d 61 69 6c                            0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_write: want=72, written=72
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 46 02 01 03 63 41 04  18 6d 61 69 6c 3d 63 6e   0F...cA..mail=cn
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  72 2e 69 74 2c 64 63 3d  63 67 70 72 6f 75 74 65   r.it,dc=cgproute
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  72 0a 01 00 0a 01 00 02  01 00 02 01 0a 01 01 00   r...............
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  a3 0e 04 04 6d 61 69 6c  04 06 63 6e 72 2e 69 74   ....mail..cnr.it
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0040:  30 06 04 04 6d 61 69 6c                            0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=8, got=8
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 20 02 01 03 65 1b 0a                            0 ...e..
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=26, got=26
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  01 20 04 00 04 14 75 6e  6b 6e 6f 77 6e 20 75 73   . ....unknown us
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  65 72 20 61 63 63 6f 75  6e 74                     er account
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: request done: ld 0x812ab00 msgid 3
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 3e 02 01 04 63 39 04  14 6d 61 69 6c 3d 69 74   0>...c9..mail=it
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  2c 64 63 3d 63 67 70 72  6f 75 74 65 72 0a 01 00   ,dc=cgprouter...
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  0a 01 00 02 01 00 02 01  0a 01 01 00 a3 0a 04 04   ................
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  6d 61 69 6c 04 02 69 74  30 06 04 04 6d 61 69 6c   mail..it0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_write: want=64, written=64
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 3e 02 01 04 63 39 04  14 6d 61 69 6c 3d 69 74   0>...c9..mail=it
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  2c 64 63 3d 63 67 70 72  6f 75 74 65 72 0a 01 00   ,dc=cgprouter...
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  0a 01 00 02 01 00 02 01  0a 01 01 00 a3 0a 04 04   ................
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  6d 61 69 6c 04 02 69 74  30 06 04 04 6d 61 69 6c   mail..it0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=8, got=8
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 20 02 01 04 65 1b 0a                            0 ...e..
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=26, got=26
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  01 20 04 00 04 14 75 6e  6b 6e 6f 77 6e 20 75 73   . ....unknown us
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  65 72 20 61 63 63 6f 75  6e 74                     er account
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: request done: ld 0x812ab00 msgid 4
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 46 02 01 05 63 41 04  18 6d 61 69 6c 3d 75 6d   0F...cA..mail=um
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  65 61 69 40 2c 64 63 3d  63 67 70 72 6f 75 74 65   eai@,dc=cgproute
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  72 0a 01 00 0a 01 00 02  01 00 02 01 0a 01 01 00   r...............
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  a3 0e 04 04 6d 61 69 6c  04 06 75 6d 65 61 69 40   ....mail..umeai@
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0040:  30 06 04 04 6d 61 69 6c                            0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_write: want=72, written=72
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 46 02 01 05 63 41 04  18 6d 61 69 6c 3d 75 6d   0F...cA..mail=um
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  65 61 69 40 2c 64 63 3d  63 67 70 72 6f 75 74 65   eai@,dc=cgproute
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0020:  72 0a 01 00 0a 01 00 02  01 00 02 01 0a 01 01 00   r...............
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0030:  a3 0e 04 04 6d 61 69 6c  04 06 75 6d 65 61 69 40   ....mail..umeai@
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0040:  30 06 04 04 6d 61 69 6c                            0...mail
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=8, got=8
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 24 02 01 05 65 1f 0a                            0$...e..
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_read: want=30, got=30
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  01 01 04 00 04 18 69 6e  63 6f 72 72 65 63 74 20   ......incorrect
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0010:  45 2d 6d 61 69 6c 20 61  64 64 72 65 73 73         E-mail address
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: request done: ld 0x812ab00 msgid 5
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: warning: dict_ldap_lookup: Search error 1: Operations error 
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 05 02 01 06 42 00                               0....B.
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug: ldap_write: want=7, written=7
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: dict_ldap_debug:   0000:  30 05 02 01 06 42 00                               0....B.
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: warning: ldap:/opt/trend/imss/postfix/etc/postfix/ldaprfx.cf: table lookup problem
Apr  4 20:51:41 mail2 postfix/smtpd[28942]: NOQUEUE: reject: RCPT from unknown[201.165.255.9]: 451 4.3.5 <[hidden email]>: Recipient address rejected: Server configuration error; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<customer-HMO-255-9.megared.net.mx>


it seems that record retrival try multiple attempt before report the error mentioned.



Do test making the query as a non-root user.  Do check whether your
SMTP server processes are chrooted and perhaps can't connect to LDAP
servers as a result.

--
Viktor.


------------------------------------------------------------------------------------------------
Paolo Barbato

Consorzio RFX
corso Stati Uniti,4                                  
35127 Padova - Italy                                       
Network Administrator 
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------

12
Loading...