LDAP lookup: 451 Temporary Lookup Failure problem

Kerem ERKAN

unread,

Dec 6, 2004, 3:44:49 AM12/6/04

to

Hello list,

I have a problem that I could not fix and wanted to have your opinions.
We are using Postfix 2.1.5 on a FreeBSD 5.2.1 system with
amavisd-new+clamav+spamassassin as a mail gateway. Behind this system
there is an exchange server which we don't want to expose to the outer
world.

The postfix sees our mail domain as a relay domain, and it is
configured to lookup users from the exchange server with LDAP. It
should give a "554 relay user not found" error when a relay user is not
found, but it gives a "451 Temporary lookup failure" error instead.

When a search is done ia ldapsearch for an unknown user, the server
gives a Success result with no other information like "user not found"
etc. But when postfix gets the same result it turns it into a 451
error.

FreeBSD server has openldap-client 2.1.23 installed.

Any suggestions?

Kerem

Cami

unread,

Dec 6, 2004, 3:47:28 AM12/6/04

to

Kerem ERKAN wrote:

> The postfix sees our mail domain as a relay domain, and it is configured
> to lookup users from the exchange server with LDAP. It should give a
> "554 relay user not found" error when a relay user is not found, but it
> gives a "451 Temporary lookup failure" error instead.

Please post `postconf -n` and include your ldap configs.

Cami

KEREM ERKAN

unread,

Dec 6, 2004, 4:06:40 AM12/6/04

to

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4DB72.D6D2A420
Content-Type: text/plain

My postconf -n output:

----------------------------------------------------------------------------
--------------------

biff = no
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
disable_vrfy_command = yes
empty_address_recipient = MAILER-DAEMON
header_checks = pcre:/etc/postfix/header_checks
html_directory = /etc/postfix/HTML
local_recipient_maps =
mail_owner = postfix
mailbox_size_limit = 1000000000
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
maximal_backoff_time = 240
message_size_limit = 80000000
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydomain = basari.com.tr
myhostname = postman.basari.com.tr
mynetworks = xxx.xxx.xxx.0/24, 127.0.0.0/8
myorigin = $mydomain
nested_header_checks =
newaliases_path = /usr/bin/newaliases
notify_classes =
queue_directory = /var/spool/postfix
queue_minfree = 200000000
queue_run_delay = 60
readme_directory = /etc/postfix/readme
relay_domains = basari.com.tr basari.com kaan.com.tr sibermarket.com.tr
relay_recipient_maps = ldap:/etc/postfix/relay_maps.cf
relayhost = [xxx.xxx.xxx.xxx]:26
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_helo_name = spamfilter.basari.com.tr
smtpd_banner = $myhostname ESMTP Server
smtpd_client_restrictions = permit_mynetworks, check_client_access
hash:/etc/postfix/access, reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net, reject_rbl_client relays.ordb.org
smtpd_hard_error_limit = 10
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access
hash:/etc/postfix/helo_access
smtpd_recipient_restrictions = reject_unauth_destination
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender,
reject_unknown_sender_domain, check_sender_access
hash:/etc/postfix/access, check_sender_access
regexp:/etc/postfix/sender_header_checks
unknown_local_recipient_reject_code = 550

----------------------------------------------------------------------------

My relay_maps.cf file:

server_host = ldap://xxx.xxx.xxx.xxx:390

search_base = cn=Recipients,ou=DOMAIN,o=DOMAIN

query_filter = (|(mail=%s) (otherMailbox=smtp*%s))

result_attribute = mail

version = 3

bind = yes

bind_dn = cn=an_exchange_admin_user,cn=Recipients,ou=DOMAIN,o=DOMAIN

bind_pw = password

----------------------------------------------------------------------------

Binding as an admin is needed because it should see some hidden users as
well as regular users.

Regards,

Kerem
----------------------------------------------------------------------------
Bu e-posta ve ilisikteki dosyalar sadece gonderilen birey ya da kurumun
kullanimi icindir. Bu mesajda kullanilan ifadeler, kurumumuzun tum
politikalarini temsil etmeyebilir. Bu nedenle sozkonusu e-posta bilgileri
kurumumuza karsi kullanilamaz ve butunuyle kurumumuzu baglayici olamaz. Bu
mesaji yanlislikla aldiysaniz, lutfen gondericiye bildiriniz ve
sisteminizden siliniz. BASARI HOLDING hakkinda bilgi almak icin lutfen web
sitemizi ziyaret ediniz. ( http://www.basari.com.tr ) Bu e-posta bilinen tum
bilgisayar viruslerine karsi korunmaktadir.
This e-mail and any attached files are intended solely for the use of the
individual or entity to whom they are addressed. The statements or
expressions used in this message may not represent our organization policy
and therefore cannot be binding for or used against BASARI HOLDING Inc. If
you have received this message accidentally, please notify the sender
immediately and delete it from your system. To get more information about
BASARI HOLDING, please visit our web site. ( http://www.basari.com.tr ) This
e-mail is protected against all known computer viruses.

------_=_NextPart_001_01C4DB72.D6D2A420
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: LDAP lookup: 451 Temporary Lookup Failure problem</TITLE>
</HEAD>
<BODY>

My postconf -n output:

---------------------------------------------------------------=
---------------------------------

biff =3D no
 command_directory =3D /usr/sbin
 config_directory =3D /etc/postfix
 daemon_directory =3D /usr/libexec/postfix
 debug_peer_level =3D 2
 disable_vrfy_command =3D yes
 empty_address_recipient =3D MAILER-DAEMON
 header_checks =3D =
pcre:/etc/postfix/header_checks
 html_directory =3D /etc/postfix/HTML
 local_recipient_maps =3D 
 mail_owner =3D postfix
 mailbox_size_limit =3D 1000000000
 mailq_path =3D /usr/bin/mailq
 manpage_directory =3D /usr/local/man
 maximal_backoff_time =3D 240
 message_size_limit =3D 80000000
 mime_header_checks =3D =
pcre:/etc/postfix/mime_header_checks
 mydomain =3D basari.com.tr
 myhostname =3D postman.basari.com.tr
 mynetworks =3D xxx.xxx.xxx.0/24, 127.0.0.0/8
 myorigin =3D $mydomain
 nested_header_checks =3D 
 newaliases_path =3D /usr/bin/newaliases
 notify_classes =3D 
 queue_directory =3D /var/spool/postfix
 queue_minfree =3D 200000000
 queue_run_delay =3D 60
 readme_directory =3D /etc/postfix/readme
 relay_domains =3D basari.com.tr basari.com =
kaan.com.tr sibermarket.com.tr
 relay_recipient_maps =3D =
ldap:/etc/postfix/relay_maps.cf
 relayhost =3D [xxx.xxx.xxx.xxx]:26
 sample_directory =3D /etc/postfix
 sendmail_path =3D /usr/sbin/sendmail
 setgid_group =3D postdrop
 smtp_helo_name =3D spamfilter.basari.com.tr
 smtpd_banner =3D $myhostname ESMTP Server
 smtpd_client_restrictions =3D =
permit_mynetworks,  check_client_access =
hash:/etc/postfix/access,   reject_rbl_client =
sbl-xbl.spamhaus.org,     reject_rbl_client =
bl.spamcop.net,       reject_rbl_client =
relays.ordb.org

smtpd_hard_error_limit =3D 10
 smtpd_helo_required =3D yes
 smtpd_helo_restrictions =3D =
permit_mynetworks,    check_helo_access =
hash:/etc/postfix/helo_access
 smtpd_recipient_restrictions =3D =
reject_unauth_destination
 smtpd_sender_restrictions =3D =
permit_mynetworks,  reject_non_fqdn_sender, =
reject_unknown_sender_domain,   check_sender_access =
hash:/etc/postfix/access,       =
check_sender_access regexp:/etc/postfix/sender_header_checks

unknown_local_recipient_reject_code =3D 550

---------------------------------------------------------------=
-------------

My relay_maps.cf file:

server_host =3D ldap://xxx.xxx.xxx.xxx:390

search_base =3D =
cn=3DRecipients,ou=3DDOMAIN,o=3DDOMAIN

query_filter =3D (|(mail=3D%s) =
(otherMailbox=3Dsmtp*%s))

result_attribute =3D mail

version =3D 3

bind =3D yes

bind_dn =3D =
cn=3Dan_exchange_admin_user,cn=3DRecipients,ou=3DDOMAIN,o=3DDOMAIN</FONT=
>

bind_pw =3D password

---------------------------------------------------------------=
-------------

Binding as an admin is needed because it should see =
some hidden users as well as regular users.

Regards,

Kerem
 ---------------------------------------------------------------=
-------------
 Bu e-posta ve ilisikteki dosyalar sadece gonderilen =
birey ya da kurumun kullanimi icindir. Bu mesajda kullanilan ifadeler, =
kurumumuzun tum politikalarini temsil etmeyebilir. Bu nedenle sozkonusu =
e-posta bilgileri kurumumuza karsi kullanilamaz ve butunuyle kurumumuzu =
baglayici olamaz. Bu mesaji yanlislikla aldiysaniz, lutfen gondericiye =
bildiriniz ve sisteminizden siliniz. BASARI HOLDING hakkinda bilgi =
almak icin lutfen web sitemizi ziyaret ediniz. ( <A =
HREF=3D"http://www.basari.com.tr" =
TARGET=3D"_blank">http://www.basari.com.tr</A> ) Bu e-posta bilinen tum =
bilgisayar viruslerine karsi korunmaktadir.

This e-mail and any attached files are intended =
solely for the use of the individual or entity to whom they are =
addressed. The statements or expressions used in this message may not =
represent our organization policy and therefore cannot be binding for =
or used against BASARI HOLDING Inc. If you have received this message =
accidentally, please notify the sender immediately and delete it from =
your system. To get more information about BASARI HOLDING, please visit =
our web site. ( <A HREF=3D"http://www.basari.com.tr" =
TARGET=3D"_blank">http://www.basari.com.tr</A> ) This e-mail is =
protected against all known computer viruses.

</BODY>
</HTML>
------_=_NextPart_001_01C4DB72.D6D2A420--

KEREM ERKAN

unread,

Dec 6, 2004, 5:27:44 AM12/6/04

to

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4DB7E.255869D0
Content-Type: text/plain

I have done a postmap -v -q unknow...@basari.com.tr
<mailto:unknow...@basari.com.tr> ldap:/etc/postfix/relay_maps.cf query
and the last lines are:

postmap: dict_ldap_get_values[1]: Search found 0 match(es)
postmap: dict_ldap_get_values[1]: Leaving dict_ldap_get_values
postmap: dict_ldap_lookup: Search returned nothing
postmap: dict_ldap_close: Closed connection handle for LDAP source
/etc/postfix/relay_maps.cf

I think postfix gets the "postmap: dict_ldap_lookup: Search returned
nothing" part and handles it with problems. It should return a 554 for this
one but it returns 451. Maybe a source code hack is required but I don't
have the necessary knowledge.

Can anybody help?

Kerem
----------------------------------------------------------------------------
Bu e-posta ve ilisikteki dosyalar sadece gonderilen birey ya da kurumun
kullanimi icindir. Bu mesajda kullanilan ifadeler, kurumumuzun tum
politikalarini temsil etmeyebilir. Bu nedenle sozkonusu e-posta bilgileri
kurumumuza karsi kullanilamaz ve butunuyle kurumumuzu baglayici olamaz. Bu
mesaji yanlislikla aldiysaniz, lutfen gondericiye bildiriniz ve
sisteminizden siliniz. BASARI HOLDING hakkinda bilgi almak icin lutfen web
sitemizi ziyaret ediniz. ( http://www.basari.com.tr ) Bu e-posta bilinen tum
bilgisayar viruslerine karsi korunmaktadir.
This e-mail and any attached files are intended solely for the use of the
individual or entity to whom they are addressed. The statements or
expressions used in this message may not represent our organization policy
and therefore cannot be binding for or used against BASARI HOLDING Inc. If
you have received this message accidentally, please notify the sender
immediately and delete it from your system. To get more information about
BASARI HOLDING, please visit our web site. ( http://www.basari.com.tr ) This
e-mail is protected against all known computer viruses.

------_=_NextPart_001_01C4DB7E.255869D0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV>I =
have done a=20
postmap -v -q <A=20
href=3D"mailto:unknow...@basari.com.tr">unknow...@basari.com.tr</A=
>=20
ldap:/etc/postfix/relay_maps.cf query and the last lines=20
are:</DIV>
<DIV><SPAN=20
class=3D104122410-06122004> </DIV>
<DIV>postmap:=20
dict_ldap_get_values[1]: Search found 0 match(es) postmap:=20
dict_ldap_get_values[1]: Leaving dict_ldap_get_values postmap:=20
dict_ldap_lookup: Search returned nothing postmap: dict_ldap_close: =
Closed=20
connection handle for LDAP source =
/etc/postfix/relay_maps.cf</DIV>
<DIV><SPAN=20
class=3D104122410-06122004> </DIV>
<DIV>I =
think postfix gets=20
the "postmap: dict_ldap_lookup: Search returned nothing" part and =
handles it=20
with problems. It should return a 554 for this one but it returns 451. =
Maybe a=20
source code hack is required but I don't have the necessary=20
knowledge.</DIV>
<DIV><SPAN=20
class=3D104122410-06122004> </DIV>
<DIV>Can =
anybody=20
help?</DIV>
<DIV><SPAN=20
class=3D104122410-06122004> </DIV>
<DIV><SPAN=20
class=3D104122410-06122004>Kerem</DIV></BODY></HTML>

---------------------------------------------------------=
-------------------

Bu e-posta ve ilisikteki dosyalar =
sadece gonderilen birey ya da kurumun kullanimi icindir. Bu mesajda =
kullanilan ifadeler, kurumumuzun tum politikalarini temsil etmeyebilir. =
Bu nedenle sozkonusu e-posta bilgileri kurumumuza karsi kullanilamaz ve =
butunuyle kurumumuzu baglayici olamaz. Bu mesaji yanlislikla =
aldiysaniz, lutfen gondericiye bildiriniz ve sisteminizden siliniz. =
BASARI HOLDING hakkinda bilgi almak icin lutfen web sitemizi ziyaret =
ediniz. ( http://www.basari.com.tr ) Bu e-posta bilinen tum bilgisayar =

viruslerine karsi korunmaktadir.

This e-mail and any attached files are =
intended solely for the use of the individual or entity to whom they =
are addressed. The statements or expressions used in this message may =
not represent our organization policy and therefore cannot be binding =
for or used against BASARI HOLDING Inc. If you have received this =
message accidentally, please notify the sender immediately and delete =
it from your system. To get more information about BASARI HOLDING, =
please visit our web site. ( http://www.basari.com.tr ) This e-mail is =

protected against all known computer viruses.

------_=_NextPart_001_01C4DB7E.255869D0--

Kerem ERKAN

unread,

Dec 6, 2004, 7:49:03 AM12/6/04

to

--Apple-Mail-6--523931683
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-9;
format=flowed

It seems like I had to break things very dangerously and not in a=20
standards compliant way.

I have changed the 451 error in reject_dict_retry to 554 in=20
src.smtpd/smtpd_check.c file. Now my server gives a 554 Temporary=20
lookup failure instead of 451. I will probably change the Temporary=20
lookup failure to something like "User unknown" also.

So far I know that, with this dangerous hack, when some connection=20
error occurs between Exchange and Postfix, many legitimate mails will=20
be rejected, I will have to pray so good for this not to happen.

Can somebody look at the smtpd_check.c file and correct the problem?=20
This is a problem in Postfix and not in my setup because postmap -v -q=20=

returns zero exit code but Postfix still thinks there is a lookup=20
failure.

Best regards,

Kerem

On 06.Ara.2004, at 12:27, KEREM ERKAN wrote:

> I have done a postmap -v -q unknow...@basari.com.tr=20

> ldap:/etc/postfix/relay_maps.cf query and the last lines are:

> =A0

> postmap: dict_ldap_get_values[1]: Search found 0 match(es)
> postmap: dict_ldap_get_values[1]: Leaving dict_ldap_get_values
> postmap: dict_ldap_lookup: Search returned nothing

> postmap: dict_ldap_close: Closed connection handle for LDAP source=20
> /etc/postfix/relay_maps.cf
> =A0
> I think postfix gets the "postmap: dict_ldap_lookup: Search returned=20=

> nothing" part and handles it with problems. It should return a 554 for=20=

> this one but it returns 451. Maybe a source code hack is required but=20=

> I don't have the necessary knowledge.

> =A0
> Can anybody help?
> =A0
> Kerem

--Apple-Mail-6--523931683
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=ISO-8859-9

It seems like I had to break things very dangerously and not in a
standards compliant way.

I have changed the 451 error in reject_dict_retry to 554 in
src.smtpd/smtpd_check.c file. Now my server gives a 554 Temporary
lookup failure instead of 451. I will probably change the Temporary
lookup failure to something like "User unknown" also.

So far I know that, with this dangerous hack, when some connection
error occurs between Exchange and Postfix, many legitimate mails will
be rejected, I will have to pray so good for this not to happen.

Can somebody look at the smtpd_check.c file and correct the problem?
This is a problem in Postfix and not in my setup because postmap -v -q
returns zero exit code but Postfix still thinks there is a lookup
failure.

Best regards,

Kerem

On 06.Ara.2004, at 12:27, KEREM ERKAN wrote:

<excerpt><fontfamily><param>Arial</param><smaller>I have done a
postmap -v -q
<color><param>0000,0000,EEEE</param>unknow...@basari.com.tr</color>
ldap:/etc/postfix/relay_maps.cf query and the last lines =
are:</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>postmap:
dict_ldap_get_values[1]: Search found 0 match(es)</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>postmap:
dict_ldap_get_values[1]: Leaving =
dict_ldap_get_values</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>postmap: dict_ldap_lookup:
Search returned nothing</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>postmap: dict_ldap_close:
Closed connection handle for LDAP source =
/etc/postfix/relay_maps.cf</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>I think postfix gets the

"postmap: dict_ldap_lookup: Search returned nothing" part and handles
it with problems. It should return a 554 for this one but it returns
451. Maybe a source code hack is required but I don't have the

necessary knowledge.</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>Can anybody =
help?</smaller></fontfamily>

=A0

<fontfamily><param>Arial</param><smaller>Kerem

</smaller></fontfamily></excerpt>

--Apple-Mail-6--523931683--

Victor Duchovni

unread,

Dec 6, 2004, 8:41:30 AM12/6/04

to

On Mon, Dec 06, 2004 at 11:06:15AM +0200, KEREM ERKAN wrote:

> My postconf -n output:
>
> relay_recipient_maps = ldap:/etc/postfix/relay_maps.cf
> smtpd_recipient_restrictions = reject_unauth_destination

It is somewhat unusual for there to be no trusted clients that are
allowed to relay...

> smtpd_sender_restrictions = permit_mynetworks,
> reject_non_fqdn_sender,
> reject_unknown_sender_domain,
> check_sender_access hash:/etc/postfix/access,
> check_sender_access regexp:/etc/postfix/sender_header_checks

Why is there something here called "sender_header_checks"? I hope
you understand that access(5) does not look at headers...

> My relay_maps.cf file:
>
> server_host = ldap://xxx.xxx.xxx.xxx:390
> search_base = cn=Recipients,ou=DOMAIN,o=DOMAIN
> query_filter = (|(mail=%s) (otherMailbox=smtp*%s))
> result_attribute = mail
> version = 3
> bind = yes
> bind_dn = cn=an_exchange_admin_user,cn=Recipients,ou=DOMAIN,o=DOMAIN
> bind_pw = password

Your query filter is broken. Lose that "*" immediately, it should be a ":",
with the wild-card in place you will get incorrect results and occasional
query timeouts:

smtp*b...@example.com

matches:

smtp:foo...@example.com

so you will accept any localpart which ends in a valid local part and all
queries have to scan the entire table looking for a match.

--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>

Kerem ERKAN

unread,

Dec 6, 2004, 9:03:04 AM12/6/04

to

On 06.Ara.2004, at 15:41, Victor Duchovni wrote:

> On Mon, Dec 06, 2004 at 11:06:15AM +0200, KEREM ERKAN wrote:
>
>> My postconf -n output:
>>
>> relay_recipient_maps = ldap:/etc/postfix/relay_maps.cf
>> smtpd_recipient_restrictions = reject_unauth_destination
>
> It is somewhat unusual for there to be no trusted clients that are
> allowed to relay...

We have no trusted clients because this is only an inbound mail relay,
it does not send mail outbound. So we don't want anyone to relay from
this machine (insider or outsider).

>
>> smtpd_sender_restrictions = permit_mynetworks,
>> reject_non_fqdn_sender,
>> reject_unknown_sender_domain,
>> check_sender_access hash:/etc/postfix/access,
>> check_sender_access regexp:/etc/postfix/sender_header_checks
>
> Why is there something here called "sender_header_checks"? I hope
> you understand that access(5) does not look at headers...
>

sender_header_checks checks if there are unknown characters in the
domain part. For example we don't want to get mail from
some_spammer@[1.2.3.4] but postfix accepts this mail. I need mail from
a properly configured mail server, I don't want to clean up any
misconfigured server's mess.

>
>> My relay_maps.cf file:
>>
>> server_host = ldap://xxx.xxx.xxx.xxx:390
>> search_base = cn=Recipients,ou=DOMAIN,o=DOMAIN
>> query_filter = (|(mail=%s) (otherMailbox=smtp*%s))
>> result_attribute = mail
>> version = 3
>> bind = yes
>> bind_dn = cn=an_exchange_admin_user,cn=Recipients,ou=DOMAIN,o=DOMAIN
>> bind_pw = password
>
> Your query filter is broken. Lose that "*" immediately, it should be a
> ":",
> with the wild-card in place you will get incorrect results and
> occasional
> query timeouts:
>

The query filter is not broken, because Exchange keeps mail addresses
differently. For example:

My username is cn=username,
My mail address is: mail=user.name@domain
If I have another mail address, it is kept as:
otherMailbox= smtp$other.address@domain

So if a mail comes to other.address@domain and I only check the "mail"
attribute from LDAP, postfix will not be able to find this mail address
in its query, so it will reject legitimate mail. But only with querying
otherMailbox=smtp*%s, I can get this mail address from LDAP.

This filter works very fast, I did not see any legitimate mail being
rejected so far. I may change the "*" to $, but it is absolutely not
":" :-)) The problem about 451 error still continues, and I still
think this is -hopefully- some Postfix bug not an Exchange LDAP bug (If
it is Exchange which is the problem, I will have to wait forever for
the problem to be resolved by Micro$oft).

I hope this will help you resolve my problems.

Cheers,

Kerem

Victor Duchovni

unread,

Dec 6, 2004, 9:13:12 AM12/6/04

to

On Mon, Dec 06, 2004 at 04:02:41PM +0200, Kerem ERKAN wrote:

> > > server_host = ldap://xxx.xxx.xxx.xxx:390
> > > search_base = cn=Recipients,ou=DOMAIN,o=DOMAIN
> > > query_filter = (|(mail=%s) (otherMailbox=smtp*%s))
> > > result_attribute = mail
> > > version = 3
> > > bind = yes
> > > bind_dn = cn=an_exchange_admin_user,cn=Recipients,ou=DOMAIN,o=DOMAIN
> > > bind_pw = password
> >
> > Your query filter is broken. Lose that "*" immediately, it should be a ":",
> > with the wild-card in place you will get incorrect results and occasional
> > query timeouts:
>
> The query filter is not broken, because Exchange keeps mail addresses
> differently.
>

It is broken and I have told you why. You are looking at the wrong
attributes. Use *only*:

query_filter = proxyAddresses = smtp:%s

If you have wild-card characters in your filter, it is broken. You
are not ready to use Postfix with LDAP until this point is clear, take
the time to understand it.

Kerem ERKAN

unread,

Dec 6, 2004, 9:14:02 AM12/6/04

to

Well, this is it.

It should be a $ as I said in my earlier mail. You have pointed me in
the right way. When I did change the query from smtp*%s to smtp$%s,
postfix started to reject mails with "550 User unknown in relay
recipient table". So this fixes my problem, thanks.

But there is still a problem though. The query with * worked perfectly
with postmap and both searches with * and $ return exactly the same
verbose output with postmap. But the query with * does not work with
postfix itself while the one with $ works with no problems.

So postmap misleads administrators as queries including * have no
problems with postmap and serious problems with postfix.

I hope this will be a very small contribution from me.

Cheers,

Kerem

On 06.Ara.2004, at 15:41, Victor Duchovni wrote:

Victor Duchovni

unread,

Dec 6, 2004, 9:26:13 AM12/6/04

to

On Mon, Dec 06, 2004 at 04:13:23PM +0200, Kerem ERKAN wrote:

> But there is still a problem though. The query with * worked perfectly
> with postmap and both searches with * and $ return exactly the same
> verbose output with postmap. But the query with * does not work with
> postfix itself while the one with $ works with no problems.
>
> So postmap misleads administrators as queries including * have no
> problems with postmap and serious problems with postfix.
>
> I hope this will be a very small contribution from me.

There is nothing misleading going on. You put a wild-card into your
query definition, queries with wild-cards can take a long time. LDAP
servers and filesystems have caches, and their response time is load
dependent. All you are observing is that the same (poorly defined)
query will sometimes complete in under 10 seconds, and sometimes not.

If you are using Exchange 2000 or 2003 (with AD), you should be using
"proxyAddresses = smtp:%s" as your query filter. If you are using
Exchange 5.x or 4.x, this may still be true or "proxyAddresses" may
be a new feature of Exchange 2000, in which case you should find out
what the right query is for your version of Exchange, but don't guess,
empirical answers are often wrong: "it appears to work" != "it is right".

Kerem ERKAN

unread,

Dec 6, 2004, 9:43:19 AM12/6/04

to

Well, I think we cannot agree here.

Definitely my query was poorly written, but postmap -v -q returned exit=20=

status 0 lightning fast, where postfix had problems. We don't have=20
thousands of users here, we only have 450-500 users, so a query which=20
only has a * in it, returns every people in the directory in a few=20
seconds. So I don't agree in a timeout situation.

Also that query only returns "Temporary lookup failure" for unknown=20
users, it always returns the proper value for known users. So if the=20
only problem was the query, it should also return some known users with=20=

a temporary failure, am I wrong?

For Exchange 5.5, proxyAddresses value is otherMailbox. And it is not=20
smtp:%s, it is smtp$%s. So the right query filter will be (|(mail=3D%s)=20=

(otherMailbox=3Dsmtp$%s)) which will return the right value always.

When postmap -v -q returned 0 exit status for my query, I did not think=20=

that it was a problem about my query. Only after changing * to $ with=20
your suggestion, the query started to work correctly on postfix. So I=20
think that postmap -v -q also should return a temporary lookup failure=20=

for a query which was written poorly. That's my point.

Thanks for helping me out, I am sorry to disturb the list with such a=20
small problem.

Regards,

Kerem

On 06.Ara.2004, at 16:25, Victor Duchovni wrote:

> There is nothing misleading going on. You put a wild-card into your
> query definition, queries with wild-cards can take a long time. LDAP
> servers and filesystems have caches, and their response time is load
> dependent. All you are observing is that the same (poorly defined)
> query will sometimes complete in under 10 seconds, and sometimes not.
>
> If you are using Exchange 2000 or 2003 (with AD), you should be using

> "proxyAddresses =3D smtp:%s" as your query filter. If you are using

> Exchange 5.x or 4.x, this may still be true or "proxyAddresses" may
> be a new feature of Exchange 2000, in which case you should find out
> what the right query is for your version of Exchange, but don't guess,

> empirical answers are often wrong: "it appears to work" !=3D "it is=20
> right".

------------------------------------------------
Kerem ERKAN
A=F0 ve G=FCvenlik Y=F6neticisi
Bili=FEim Teknolojileri
Ba=FEar=FD Holding A.=DE.

(312) 4095000 / 5552

Wietse Venema

unread,

Dec 6, 2004, 9:53:31 AM12/6/04

to

It seems that postmap/postalias don't report DICT_ERR_RETRY conditions.

Wietse

Victor Duchovni

unread,

Dec 6, 2004, 10:12:13 AM12/6/04

to

On Mon, Dec 06, 2004 at 04:42:53PM +0200, Kerem ERKAN wrote:

> For Exchange 5.5, proxyAddresses value is otherMailbox. And it is not

> smtp:%s, it is smtp$%s. So the right query filter will be (|(mail=%s)
> (otherMailbox=smtp$%s)) which will return the right value always.

Does "otherMailbox" only list the values that are not listed in "mail",
or does it also list the primary SMTP address allowing the query to
be simplified further...

If all goes well Postfix 2.2 will have a unified query feature set for
LDAP, MySQL and Postgres and (new feature) $variable will be interpreted
as a Postfix parameter substitution in the query definition, for example:

query_filter = mail=%u@$mydomain

this will likely create an incompatibility with "smtp$%s", which may need
to become smtp$$%s ("$$" will expand to a single '$' character).

> When postmap -v -q returned 0 exit status for my query, I did not think

> that it was a problem about my query. Only after changing * to $ with

> your suggestion, the query started to work correctly on postfix. So I

> think that postmap -v -q also should return a temporary lookup failure

> for a query which was written poorly. That's my point.
>

The queries were timing out. Search your old logs (adjust log file name
appropriately):

egrep ': warning: dict_ldap_lookup: Search error' \
/var/log/maillog.1

you will see the timeout messages. There is NO difference between the
postmap(1) LDAP query code and the smtpd(8) LDAP query code, it is the
same code. If the query fails in one case and not the other, the reason
is load on the Exchange server, and/or the specific choice of lookup key.
LDAP servers tend to cache query results, making the same query repeatedly
will often avoid a timeout on a second query.

Command-line tests can not *prove* the correctness of a filter: "it
appears to work" does not imply "it is right". One may be able to prove
that a filter is wrong: "it does not work" implies "it is not right".

We can end this thread, as soon as you accept that Postfix is already
doing the right thing :-) (Hint: time to end the thread).

Kerem ERKAN

unread,

Dec 6, 2004, 9:58:19 AM12/6/04

to

That's what I am trying to explain :-)

Thanks,

Kerem

Victor Duchovni

unread,

Dec 6, 2004, 10:17:23 AM12/6/04

to

On Mon, Dec 06, 2004 at 04:57:55PM +0200, Kerem ERKAN wrote:

> On 06.Ara.2004, at 16:53, Wietse Venema wrote:
>
> >It seems that postmap/postalias don't report DICT_ERR_RETRY conditions.
>

> That's what I am trying to explain :-)
>

No, that is not the problem. Had the lookups timed out in postmap, the
failure reason would have been printed to standard error, for example,
when I create a .cf file with a broken search base:

postmap: warning: dict_ldap_lookup: Search base not found: 'o=Foo Bar': 32: No such object

Victor Duchovni

unread,

Dec 6, 2004, 10:48:28 AM12/6/04

to

On Mon, Dec 06, 2004 at 05:27:57PM +0200, Kerem ERKAN wrote:

> > egrep ': warning: dict_ldap_lookup: Search error' \
> > /var/log/maillog.1
> >
>

> Well, I searched, the errors are not timeouts, but they are "Search
> error 11: Administrative limit exceeded." errors. This should be
> something with exchange.

This is a row count limit in Exchange. The queries are matching too many
records. With a dictionary attack on short strings:

a...@example.com
b...@example.com
...

The query will find all addresses with localparts ending in "a", "b", ...
and the result-set will be too large. If you try *exactly* the same
query with postmap(1) you will get the same result.

> Still I wish you could test the problem here yourself, it may still be
> a problem (if I make a query with postmap and filter with otherMailbox=*,
> postmap gives me the same error that is logged above. But postmap with
> otherMailbox=smtp*%s does not give the same error while smtpd gives it.
> That is strange.)
>

There is nothing to test, the query code (a simple call to dict_get)
is the same in both cases. Your evidence is incomplete, because you
did not look at and report the log messages, did not perform tests
with the same input keys.

Yes postmap(1) does not spefically report DICT_ERR_RETRY error returns
from dict_get(), but the LDAP lookup code reports all errors. A similar
observation applies to the MySQL lookup code, ...

if (!(mysql_query(host->db, query))) {
if ((res = mysql_store_result(host->db)) == 0) {
msg_warn("mysql query failed: %s", mysql_error(host->db));
plmysql_down_host(host);
} else {
if (msg_verbose)
msg_info("dict_mysql: successful query from host %s", host->hostname);
event_request_timer(dict_mysql_event, (char *) host, IDLE_CONN_INTV);
break;
}
} else {
msg_warn("mysql query failed: %s", mysql_error(host->db));
plmysql_down_host(host);
}

so reporting the error again in postmap(1) is not strictly required. All
IPC based lookup mechanisms report detailed errors, while the simple
indexed file dictionaries never set DICT_ERR_RETRY... (rather they fail
with msg_fatal).