117471

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:

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
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilen

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

tikayevent
Lösung tikayevent 21.02.2022 aktualisiert um 09:45:45 Uhr
Goto Top
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?
117471
Lösung 117471 21.02.2022 um 11:17:08 Uhr
Goto Top
Hallo,

Zitat von @tikayevent:

Fangen wir mal mit dem kleineren Problem an: Soweit ich weiß, müssen Queryfilter immer in Klammern stehen.

PS: Seh ich richtig, dass es bei dir im LDAP kein Attribut namens paid_up gibt?

Ja, meine Güte - klar! Der sucht nach einem Attribut mit dem Namen! Und ich google mir schon den Wolf weil ich dachte, dass das irgendeine exotische Option ist face-smile

Ergo:

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

Hier habe ich dann aber weiterhin das Problem, dass kein Lookup erfolgt (oder!) dass der Lookup fehlschlägt:

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.

In der mail.info auf dem Server:

Feb 21 10:09:54 mail postfix/smtpd[20029]: connect from cleversophie.lan.tux-net[192.168.71.80]
Feb 21 10:09:54 mail postfix/smtpd[20029]: 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 10:09:54 mail postfix/smtpd[20029]: disconnect from cleversophie.lan.tux-net[192.168.71.80] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4

Wie grenze ich das jetzt weiter ein?

Gruß,
Jörg
1915348599
1915348599 21.02.2022 aktualisiert um 11:40:24 Uhr
Goto Top
Da fehlt das result_attribute
result_attribute = mail
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
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.

Handbuch lesen hilft manchmal wirklich 😉
117471
Lösung 117471 21.02.2022 um 11:47:59 Uhr
Goto Top
Hallo,

lieben Dank! face-smile

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?

Liebe Grüße,
Jörg
1915348599
Lösung 1915348599 21.02.2022 aktualisiert um 11:55:02 Uhr
Goto Top
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.
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.
117471
Lösung 117471 21.02.2022 um 13:54:00 Uhr
Goto Top
Hallo,

Nein, du hast ja schon eins.

Danke für eure Geduld. Ich glaube, wir nähern uns so langsam der Zielgeraden... face-smile

Ich habe seinerzeit tatsächlich ein passendes Schema eingespielt, nämlich dieses hier:

root@ldap:~# cat courier.ldif
dn: cn=courier,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: courier
#
# OID prefix: 1.3.6.1.4.1.10018
#
# Attributes: 1.3.6.1.4.1.10018.1.1
#
# Depends on: nis.schema, which depends on cosine.schema
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.1 NAME 'mailbox'  
  DESC 'The absolute path to the mailbox for a mail account in a non-default location'  
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.2 NAME 'quota'  
  DESC 'A string that represents the quota on a mailbox'  
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.3 NAME 'clearPassword'  
  DESC 'A separate text that stores the mail account password in clear text'  
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.4 NAME 'maildrop'  
  DESC 'RFC822 Mailbox - mail alias'  
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.5 NAME 'mailsource'  
  DESC 'Message source'  
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.6 NAME 'virtualdomain'  
  DESC 'A mail domain that is mapped to a single mail account'  
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.7 NAME 'virtualdomainuser'  
  DESC 'Mailbox that receives mail for a mail domain'  
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.8 NAME 'defaultdelivery'  
  DESC 'Default mail delivery instructions'  
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.9 NAME 'disableimap'  
  DESC 'Set this attribute to 1 to disable IMAP access'  
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.10 NAME 'disablepop3'  
  DESC 'Set this attribute to 1 to disable POP3 access'  
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.11 NAME 'disablewebmail'  
  DESC 'Set this attribute to 1 to disable IMAP access'  
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.12 NAME 'sharedgroup'  
  DESC 'Virtual shared group'  
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.13 NAME 'disableshared'  
  DESC 'Set this attribute to 1 to disable shared mailbox usage'  
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.10018.1.1.14 NAME 'mailhost'  
  DESC 'Host to which incoming POP/IMAP connections should be proxied'  
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
#
#
# Objects: 1.3.6.1.4.1.10018.1.2
#
olcObjectClasses: ( 1.3.6.1.4.1.10018.1.2.1 NAME 'CourierMailAccount'  
  DESC 'Mail account object as used by the Courier mail server'  
  SUP top AUXILIARY
  MUST ( mail $ homeDirectory )
  MAY ( uidNumber $ gidNumber $ mailbox $ uid $ cn $ gecos $ description $ loginShell $ quota $ userPassword $ clearPassword $ defaultdelivery $ disableimap $ disablepop3 $ disablewebmail $ sharedgroup $ disableshared $ mailhost ) )
olcObjectClasses: ( 1.3.6.1.4.1.10018.1.2.2 NAME 'CourierMailAlias'  
  DESC 'Mail aliasing/forwarding entry'  
  SUP top AUXILIARY
  MUST ( mail $ maildrop )
  MAY ( mailsource $ description ) )
olcObjectClasses: ( 1.3.6.1.4.1.10018.1.2.3 NAME 'CourierDomainAlias'  
  DESC 'Domain mail aliasing/forwarding entry'  
  SUP top AUXILIARY
  MUST ( virtualdomain $ virtualdomainuser )
  MAY ( mailsource $ description ) )
root@ldap:~#

Allerdings bekomme ich die Felder nicht im LDAP Account Manager (LAM) zu Gesicht. Was mich augenscheinlich daran hindert, diese zu befüllen.

Unter /usr/share/ldap-account-manager/lib/modules sehe zwei dazu passende Module:
  • courierMailAccount
  • courierMailAlias

Nun - das erstgenannte Modul kann ich im LDAP Account Manager hinzufügen Das Zweite lässt sich jedoch nicht hinzufügen (...und findet, z.B. im LDAP Account Manager - Manual keine Erwähnung?!?).

Liebe Grüße,
Jörg
1915348599
Lösung 1915348599 21.02.2022 aktualisiert um 13:59:21 Uhr
Goto Top
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.
117471
Lösung 117471 21.02.2022 um 14:14:37 Uhr
Goto Top
Hallo,

Zitat von @1915348599:

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 face-smile
1915348599
1915348599 21.02.2022 aktualisiert um 14:51:18 Uhr
Goto Top
Zitat von @117471:

Hallo,

Zitat von @1915348599:

btw. Attribute muss man objectClasses zuordnen sonst erscheinen sie in den entsprechenden Objekten nicht.

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.
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 face-smile

Aber wie gesagt eine Schema-Erweiterung brauchst du für deinen Fall (deine Usprüngliche Frage) hier absolut nicht!!
117471
117471 21.02.2022 aktualisiert um 16:44:18 Uhr
Goto Top
Hallo,

es handelt sich tatsächlich um einen Fehler im LDAP Account Manager. Ich habe phpldapadmin installiert und damit bekomme ich zumindest schon mal das Feld zu Gesicht (indem ich dem Benutzer einen courierMailAlias "Child Entry" hinzufüge).

Vielen Dank noch einmal für eure Geduld @1915348599 und @tikayevent

Liebe Grüße,
Jörg

Übrigens: Ob ich mir dem Einspielen des o.A. Courier-Schemas etwas kaputtgespielt habe, entzieht sich immer noch meiner Kenntnis... face-wink face-sad