
117471
21.02.2022
Postfix vs. ldap: bad search filter
Hallo,
ich bemühe mich gerade, mit einem postfix auf einem LDAP-Server nach E-Mail-Aliasen zu suchen.
Die LDAP-Abfrage auf dem postfix funktioniert grundsätzlich:
In der /etc/postfix/main.cf verweise ich auf die LDAP-Konfiguration...
...welche wie folgt aussieht:
Im Anschluss versuche ich, eine E-Mail zuzustellen:
Auf dem postfix bekomme ich (natürlich) eine aussagekräftige Fehlermeldung:
Kurzum: "Er" meckert über den query_filter. Nur - warum?
Der Filter stammt zugegebenermaßen 1:1 aus der manpage, deckt sich aber mit den Gegebenheiten. Da ich irgendwie so gar nichts zu dem paid_up Ausdruck finde, lasse ich diesen testweise weg:
Ergebnis der Änderung: Der LDAP-Server wird jetzt offenbar gar nicht mehr befragt:
Lange Rede, kurzer Sinn - ich gebe gerne zu, dass ich momentan hoffnungslos überfordert bin. Vielleicht mag mir ja jemand 'n Schubs in die richtige Richtung geben?
Gruß,
Jörg
ich bemühe mich gerade, mit einem postfix auf einem LDAP-Server nach E-Mail-Aliasen zu suchen.
Die LDAP-Abfrage auf dem postfix funktioniert grundsätzlich:
root@mail:/etc/postfix# ldapsearch -D "cn=readonly,ou=people,dc=meine-testdomain,dc=de" -w "yodasfunktioniert" -b "ou=people,dc=meine-testdomain,dc=de" -H ldap:{{comment_single_line_double_slash:0}}
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=meine-testdomain,dc=de> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# people, meine-testdomain.de
dn: ou=people,dc=meine-testdomain,dc=de
objectClass: organizationalUnit
objectClass: top
ou: people
# hs_jka, people, meine-testdomain.de
dn: uid=hs_jka,ou=people,dc=meine-testdomain,dc=de
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: CourierMailAccount
uid: hs_jka
cn: altmetaller
loginShell: /bin/bash
uidNumber: 10000
gidNumber: 10000
homeDirectory: /home/hs_jka
shadowMax: 99999
shadowMin: 1
shadowWarning: 7
shadowInactive: 7
sn: altmetaller
givenName:: SsO2cmc=
mail: hs_jka@meine-testdomain.de
mail: ichbin.altmetaller@meine-testdomain.de
mail: test@meine-testdomain.de
shadowLastChange: 18781
userPassword:: hierstehteinpassworthashichhoffeesistderrichtige=
disableimap: 0
disablepop3: 0
disablewebmail: 0
disableshared: 0
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
root@mail:/etc/postfix#
In der /etc/postfix/main.cf verweise ich auf die LDAP-Konfiguration...
root@mail:/etc/postfix# cat main.cf | grep alias_maps
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
root@mail:/etc/postfix#
...welche wie folgt aussieht:
server_host = ldap.dmz.tux-net
search_base = dc=meine-testdomain,dc=de
query_filter = (&(mail=%s)(paid_up=true))
bind_dn = cn=readonly,ou=people,dc=meine-testdomain,dc=de
bind_pw = yodasfunktioniert
Im Anschluss versuche ich, eine E-Mail zuzustellen:
jka@cleversophie:~$ swaks --to test@meine-testdomain.de --server mail.dmz.tux-net
=== Trying mail.dmz.tux-net:25...
=== Connected to mail.dmz.tux-net.
<- 220 mail.localdomain ESMTP Postfix (Debian/GNU)
-> EHLO cleversophie
<- 250-mail.localdomain
<- 250-PIPELINING
<- 250-SIZE 10240000
<- 250-VRFY
<- 250-ETRN
<- 250-STARTTLS
<- 250-AUTH DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN
<- 250-AUTH=DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN
<- 250-ENHANCEDSTATUSCODES
<- 250-8BITMIME
<- 250-DSN
<- 250-SMTPUTF8
<- 250 CHUNKING
-> MAIL FROM:<jka@cleversophie>
<- 250 2.1.0 Ok
-> RCPT TO:<test@meine-testdomain.de>
<** 550 5.1.1 <test@meine-testdomain.de>: Recipient address rejected: User unknown in local recipient table
-> QUIT
<- 221 2.0.0 Bye
=== Connection closed with remote host.
Auf dem postfix bekomme ich (natürlich) eine aussagekräftige Fehlermeldung:
Feb 21 07:55:43 mail postfix/smtpd[18167]: connect from cleversophie.lan.tux-net[192.168.71.80]
Feb 21 07:55:43 mail postfix/smtpd[18167]: warning: dict_ldap_lookup: Search error -7: Bad search filter
Feb 21 07:55:43 mail postfix/smtpd[18167]: warning: ldap:/etc/postfix/ldap-aliases.cf lookup error for "test@meine-testdomain.de"
Feb 21 07:55:43 mail postfix/smtpd[18167]: NOQUEUE: reject: RCPT from cleversophie.lan.tux-net[192.168.71.80]: 451 4.3.0 <test@meine-testdomain.de>: Temporary lookup failure; from=<jka@cleversophie> to=<test@meine-testdomain.de> proto=ESMTP helo=<cleversophie>
Feb 21 07:55:43 mail postfix/smtpd[18167]: disconnect from cleversophie.lan.tux-net[192.168.71.80] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4
Kurzum: "Er" meckert über den query_filter. Nur - warum?
Der Filter stammt zugegebenermaßen 1:1 aus der manpage, deckt sich aber mit den Gegebenheiten. Da ich irgendwie so gar nichts zu dem paid_up Ausdruck finde, lasse ich diesen testweise weg:
server_host = ldap.dmz.tux-net
search_base = dc=meine-testdomain,dc=de
query_filter = mail=%s
bind_dn = cn=readonly,ou=people,dc=meine-testdomain,dc=de
bind_pw = yodasfunktioniert
Ergebnis der Änderung: Der LDAP-Server wird jetzt offenbar gar nicht mehr befragt:
Feb 21 08:06:10 mail postfix/smtpd[19079]: connect from cleversophie.lan.tux-net[192.168.71.80]
Feb 21 08:06:10 mail postfix/smtpd[19079]: NOQUEUE: reject: RCPT from cleversophie.lan.tux-net[192.168.71.80]: 550 5.1.1 <test@meine-testdomain.de>: Recipient address rejected: User unknown in local recipient table; from=<jka@cleversophie> to=<test@meine-testdomain.de> proto=ESMTP helo=<cleversophie>
Feb 21 08:06:10 mail postfix/smtpd[19079]: disconnect from cleversophie.lan.tux-net[192.168.71.80] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4
Lange Rede, kurzer Sinn - ich gebe gerne zu, dass ich momentan hoffnungslos überfordert bin. Vielleicht mag mir ja jemand 'n Schubs in die richtige Richtung geben?
Gruß,
Jörg
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1967625539
Url: https://administrator.de/forum/postfix-vs-ldap-bad-search-filter-1967625539.html
Ausgedruckt am: 21.06.2025 um 02:06 Uhr
10 Kommentare
Neuester Kommentar
Fangen wir mal mit dem kleineren Problem an: Soweit ich weiß, müssen Queryfilter immer in Klammern stehen.
Beim Problem mit deinem paid_up bin ich mir schon etwas unsicherer, aber ich meine, es muss TRUE heißen. Zumindest ist LDAP manchmal Case-Sensitive.
PS: Seh ich richtig, dass es bei dir im LDAP kein Attribut namens paid_up gibt?
Beim Problem mit deinem paid_up bin ich mir schon etwas unsicherer, aber ich meine, es muss TRUE heißen. Zumindest ist LDAP manchmal Case-Sensitive.
PS: Seh ich richtig, dass es bei dir im LDAP kein Attribut namens paid_up gibt?

Da fehlt das result_attribute
Er muss ja wissen welches Attribut er zurückgeben soll, und das ist per Default nicht "mail" sondern "maildrop"
http://www.postfix.org/ldap_table.5.html
Handbuch lesen hilft manchmal wirklich 😉
result_attribute = mail
http://www.postfix.org/ldap_table.5.html
result_attribute (default: maildrop)
The attribute(s) Postfix will read from any directory entries returned by the lookup, to be resolved to an email address.
The attribute(s) Postfix will read from any directory entries returned by the lookup, to be resolved to an email address.
Handbuch lesen hilft manchmal wirklich 😉

Zitat von @117471:
Wenn ich mehrere mail Attribute habe, sollte ich also maildrop zusätzlich im Schema etablieren?
Nein, du hast ja schon eins. Es gibt nicht mehrere Attribute mit dem selben Namen, das verbietet schon das AD Schema, du meinst du hast ein Multi-Valued Feld eingerichtet in dem mehrere Werte stehen. Das sollte postfix i.d.R. auflösen.Wenn ich mehrere mail Attribute habe, sollte ich also maildrop zusätzlich im Schema etablieren?
Was liefere ich deiner Erfahrung nach am Besten zurück? Den Usernamen? Den Pfad zur inbox? Eine E-Mail-Adresse, die auf dem Mailer lokal existiert?
Die Mailadresse des Users.
Allerdings bekomme ich die Felder nicht im LDAP Account Manager (LAM) zu Gesicht. Was mich augenscheinlich daran hindert, diese zu befüllen.
Wie gesagt am Schema rumspielen brauchst du nicht, du kannst ja wie oben geschrieben die Attribute selbst welche zurückgeliefert werden.btw. Attribute muss man objectClasses zuordnen sonst erscheinen sie in den entsprechenden Objekten nicht.

Zitat von @117471:
Hallo,
Die Attribute sind der objectClass courierMailAlias zugeordnet.
Dann musst du auch ein Objekt dieser Klasse erzeugen wen du sie sehen willst. Wenn die Attribute nicht der user Klasse zugeordnet sind wirst du sie bei User Objekten nie zu Gesicht bekommen.Hallo,
Zitat von @1915348599:
btw. Attribute muss man objectClasses zuordnen sonst erscheinen sie in den entsprechenden Objekten nicht.
btw. Attribute muss man objectClasses zuordnen sonst erscheinen sie in den entsprechenden Objekten nicht.
Die Attribute sind der objectClass courierMailAlias zugeordnet.
Wie gesagt - es geht "augenscheinlich" nur noch darum, diese objectClass auch sichtbar zu machen. Diese sehe ich weder im LDAP Account Manager, noch im ldapadmin (das ist so 'n Windows-Tool).
Gruß,
Jörg
Übrigens: Danke für euer beider Geduld. Ich möchte mich da wirklich reinfuchsen
Gruß,
Jörg
Übrigens: Danke für euer beider Geduld. Ich möchte mich da wirklich reinfuchsen
Aber wie gesagt eine Schema-Erweiterung brauchst du für deinen Fall (deine Usprüngliche Frage) hier absolut nicht!!