[Postfixbuch-users] Postfix mit SMTP-AUTH klappt nicht.

[Patrick Ben Koetter]

* Marcus Frings <iam-est-hora-surgere at despammed.com>:
> > Hmmm, gefällt mir nicht, das gleich so komplex zu machen. Hast Du es mal ohne
> > den smtpd im chroot zu haben und mit sasldb an der default location probiert?
> 
> Es klappt auch, wenn smtpd im chroot läuft und dann die sasldb2 in
> /var/spool/postfix/etc benutzt. Mehr dazu siehe unten.

Gut.

> >> Ich gebe zu, dass mir die ganze Geschichte mit REALM nicht ganz klar
> >> ist, deshalb habe ich testweise drei User auf unterschiedliche Arten
> >> angelegt:
> 
> >> 1) saslpasswd2 -c -u `postconf -h myhostname` -a smtpauth test1
> 
> > Nee...
> 
> Warum nee? Wegen des "-a"-Parameters?
> 

Ja. Der Service wäre ein von der IANA (IIRC legt sie das fest, aber Nagel mich
nicht darauf fest...) festgelegter Service-Name. Für SMTP eben "smtp" und
nicht "smtpauth".


> >> 2) saslpasswd2 -c -u `postconf -h myhostname` test2
> 
> > Hmmm, das ist ja in Deinem Fall NULL
> 
> Was meinst Du mit NULL?

Mein Fehler. Ich hatte "smtpd_sasl_local_domain" gelesen und nicht
"myhostname". $myhostname ergibt natürlich einen Wert. Für
$smtpd_sasl_local_domain hattest Du explizit NULL angegeben.


> Sagen wir mal, $myhostname in main.cf sei "mein.example.net". Dann
> ergibt obiges Kommando laut sasldlistusers2 folgende Ausgabe:
> 
> test2 at mein.example.net: userPassword

Ja.


> >> 3) saslpasswd2 -c test3
> 
> > Das wird sein, was der HOSTNAME Deines Servers ist.
> 
> Und sasldblistusers2 ergibt dann hier:
> 
> test3 at mein: userPassword

Hmmm, dann ist HOSTNAME nur die kurzversion Deines FQDN? Oder ist kein FQDN
gesetzt?


> >> Nach erneutem Einlesen der Konfiguration mache ich remote ein telnet auf
> >> den Mailserver und nach Senden des EHLO bekomme ich:
> 
> >> ,----
> >> | 250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
> >> | 250-AUTH=LOGIN PLAIN DIGEST-MD5 CRAM-MD5
> >> `----
> 
> >> Scheint also schon einmal zu funktionieren.
> 
> > Kann auch nur zufällig eine Liste aller vier installierten Mechanismen sein.
> > Nimm einen Mech in /etc/postfix/sasl/smtpd.conf raus und wenn Du recht hast,
> > dann fehlt der nach einem Reload bei einem telnet.
> 
> Ja, wenn ich etwas rausnehme und die Konfiguration neu einlese, fehlt das
> auch nach einem telnet. Soweit also alles in Ordnung.

Perfekt. Können wir also als Fehlerquelle ausschliessen.


> >> ,----[ mail.info ]
> >> | postfix/smtpd[31516]: smtpd_sasl_authenticate: sasl_method PLAIN, init_response $BASE64-PASSWORT
> >> | postfix/smtpd[31516]: smtpd_sasl_authenticate: decoded initial response test2
> 
> > Hier fehlt ein @ und ein REALM...
> > Setz als REALM mal das ein, was Du durch ein sasldblistusers2 als "domain"
> > erhältst und achte beim erstellen des BASE64 Strings darauf, das @ zu escapen.
> 
> Okay, habe ich jetzt gemacht (Eintrag 2 oben) und so klappt es auch:
> 
> perl -MMIME::Base64 -e 'print encode_base64("test2\@mein.example.net\0test2\@mein.example.net\0passwort");'
> 
> Mit dem generierten String kann ich mich mittels AUTH PLAIN anmelden und

Sehr gut!


> bekomme auch ein "235 Authentication successful", und zwar unabhängig
> davon, ob ich "smtpd_sasl_local_domain = $myhostname" oder
> "smtpd_sasl_local_domain =" verwende. Soll das tatsächlich so sein
> (Konfiguration habe ich natürlich zwischenzeitlich neu eingelesen)?

Das liegt daran, dass Postfix den $smtpd_sasl_local_domain nur dann anhängt
wenn der client keinen domainpart gesendet hat. In beiden Fällen hast Du aber
den domainpart mit Deinem Teststring gesendet und so kam
$smtpd_sasl_local_domain nie zur Anwendung...

> Und mit
> 
> perl -MMIME::Base64 -e 'print encode_base64("test3\@mein\0test3\@mein\0passwort");'
> (das entspricht ja Eintrag 3 von oben)
> 
> und
> 
> perl -MMIME::Base64 -e 'print encode_base64("test3\0test3\0passwort");'
> 
> funktioniert es wie vorher nicht. Aber das scheint ja auch okay zu sein,
> wenn ich Dich richtig verstanden habe.

Ja, es ist richtig, dass das so nicht klappt.


> > Die Frage ist, ob $myhostname == HOSTNAME ist...
> 
> ,----
> | postconf -h myhostname
> | mein.example.net
> | 
> | echo $HOSTNAME
> | mein
> `----

Bingo! Da liegt Dein Problem. Lösung kommt weiter unten... ;)


> Das ist doch richtig, oder? Zumindest hat das ja mit dem AUTH PLAIN mit
> Eintrag 2 so oben geklappt.
> 
> Okay, mit "test2 at mein.example.net" als User klappt es also, aber wie
> kann ich postfix/sasl nun so konfigurieren, dass ich keinen REALM
> brauche und lediglich den ganz normalen Usernamen + Passwort bei der
> Authentifizierung verwende?

Du musst als $smtpd_sasl_local_domain den Wert setzen, der in der sasldb als
"-u"-Wert eingetragen wurde. Dann sollte es klappen, wenn die clients "nur"
den localpart senden. Postfix wird dann $smtpd_sasl_local_domain als
domainpart mit anhängen...


> ,----[ http://postfix.state-of-mind.de/patrick.koetter/smtpauth/sasldb_configuration.html ]
> | If you set smtpd_sasl_local_domain = $myhostname, then you will always
> | have to submit the REALM that equals $myhostname when you pass the
> | username to SASL.
> | 
> | If you don't want to pass a REALM, then you must leave this parameter
> | empty, but still you need to set it:
> | 
> | smtpd_sasl_local_domain =
> `----

Mißverständlich. Zeit, dass ich endlich mal dazu komme, es zu überarbeiten...


> Wenn ich diesen Wert leer lasse, sollte der Spaß doch ganz ohne REALM
> funktionieren, aber warum klappt es bei mir nicht wenn ich dann
> lediglich
> 
> perl -MMIME::Base64 -e 'print encode_base64("test3\0test3\0passwort");'
> 
> nehme?

Nee, weil sasldb eben einen eingetragen hat und erwartet, dass der auch
benutzt wird. Frei nach dem Motto: "Welchen User meinst Du denn? test at mein
oder test at mein.example.net? In meiner DB sind beide..."


> Und dann vorerst noch eine abschließende Frage: Mein lokaler postfix
> soll natürlich mein.example.net als SMTP-Relay mit Authentifizierung
> nutzen. Welchen Mechanismus nimmt der lokale postfix als Default?

Den stärksten und er wird keine plaintext und keine anonymous Mechs benutzen.
Kannst Du selber mit postconf rausfinden.

$ /usr/sbin/postconf -d smtp_sasl_security_options
smtp_sasl_security_options = noplaintext, noanonymous


> Ich habe hier lokal 
> 
> "smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth"
> 
> Nimmt er damit dann automatisch PLAIN oder wovon ist das abhängig? Ich
> werde postfix ohnehin noch TLS beibringen, damit PLAIN eben doch nicht
> im Klartext übertragen wird.

Die SASL library ist für die Wahl des Mechs zuständig. Sie wird immer den
besten (read: sichersten) Mech wählen. Wenn Du CRAM-MD5 und/oder DIGEST-MD5
anbietest, wird sie diese PLAIN oder LOGIN vorziehen.


> Wenn ich dann dem postfix auf mein.example.net TLS beibringe und
> folgendes aktiviere
> 
> ,----
> | smtpd_use_tls = yes
> | # smtpd_tls_auth_only = yes
> `----
> 
> verwendet mein lokaler Postfix dann automatisch Verschlüsselung bei der
> Übertragung von User+Passwort?

Nein. smtpd_tls_auth_only legt fest, dass der SMTP-Server (!) AUTH nur dann
anbietet, wenn der SMTP client eine TLS-Session etabliert hat.

Wenn du PLAIN und LOGIN nur unter TLS anbieten willst, dann mach folgendes im
SMTP-Server:

smtpd_sasl_security_options = noplaintext, noanonymous
smtpd_tls_sasl_security_options = noanonymous

So werden plaintext Mechanismen nur bei TLS gestattet...


> Durch Auskommentieren von "# smtpd_tls_auth_only = yes" kann ich das
> zwar erzwingen und Klartextübertragung generell verbieten, aber IIRC
> stand geschrieben, dass das Probleme verursachen kann und nicht immer
> empfohlen wird.

Es ist nicht elegant, sagen wir es mal so. Damit bestrafst Du alle Clients,
die bessere Mechanismen wie Shared-Secret- oder Kerberos-Mechanismen
beherrschen. Ich würde es wie oben mit den ..._security_options beschrieben
machen. So müssen nur die Clients, die maue Mechanismen können, gezwungen
"höher zu springen". ;)

p at rick

-- 
Das Postfix-Buch
<http://www.postfix-buch.com>
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>