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

[Marcus Frings]

* Patrick Ben Koetter <p at state-of-mind.de> wrote:
> * Marcus Frings <iam-est-hora-surgere at despammed.com>:

> 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".

Ah, okay! Danke für die Erklärung.

>> >> 3) saslpasswd2 -c test3
>> Und sasldblistusers2 ergibt dann hier:
>> test3 at mein: userPassword

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

Nun ja, "hostname" liefert hier wirklich nur den Hostnamen und nicht den
FQDN. Das ist aber IMHO auch richtig so:

,----
| [01:07]mein:/home/marcus# hostname 
| mein
| [01:07]mein:/home/marcus# hostname --fqdn
| mein.example.net
`----

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

Aha, das habe ich nun auch verstanden! :-)

>> > 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... ;)
> 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...

Ja, nun klappt es auch. Ich habe nun in der main.cf
"smtpd_sasl_local_domain = mein" (also wirklich nur host und nicht
host.domain.tld) gesetzt und einfach wie oben noch einmal einen weiteren
Testuser angelegt: 

saslpasswd2 -c marcustest

sasldblistusers2 gibt dann "marcustest at mein: userPassword" aus.
Danach habe ich nur den Usernamen+Passwort nach BASE64 umgewandelt:

perl -MMIME::Base64 -e 'print encode_base64("marcustest\0marcustest\0ein_test_passwort1");

Und dann diesen String im telnet-Dialog bei AUTH PLAIN
eingesetzt. Ergebnis: 235 Authentication successful ----> Sehr schön;
genauso, wie ich es gern hätte! :-)

>> ,----[ 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 [...]

> 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..."

Deine Erklärung im zweiten Absatz in der Boxquote oben hat mich wirklich
schwer auf's Glatteis geführt und ist, so wie ich das jetzt nun verstehe,
auch sachlich falsch oder zumindest schwer missverständlich, oder?

In meinem Beispiel oben gebe ich im BASE64-Teil ja gerade eben keinen
REALM mit, aber ich darf den Parameter mit "smtpd_sasl_local_domain ="
dennoch nicht leer gesetzt lassen, und zwar gerade weil bei
sasldblistusers2 ein REALM ausgegeben ("marcustest at MEIN") und somit auch
von sasldb erwartet wird. Mit "smtpd_sasl_local_domain = mein"
funktioniert es ja nun, auch wenn ich keinen REALM mitliefere.

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

Ja, klappt hervorragend. Ich habe gerade eine Testmail hier verschickt
(mein lokaler Postfix hat schon meinen neuen Relayhost, dem wir gerade
SMTP-AUTH beigebracht haben, verwendet) und ich sehe im dortigen Log:

,----
| postfix/smtpd[7044]: A4BC318068:
| client=p5089E120.dip.t-dialin.net[80.137.225.32], sasl_method=DIGEST-MD5,
| sasl_username=USER at REALM 
`----

Sehr schön, er wählt also aus den vier angebotenen Mechs digest-md5 aus
und ich kann beruhigt schlafen, weil Username+Passwort nicht im Klartext
übertragen werden.

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

Okay, verstanden.

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

Wie ist denn so die gängige Praxis in diesem speziellen Fall bei
größeren Mailservern im Internet? /Ich persönlich/ bin ja schon einmal
auf der sicheren Seite, weil mein lokaler postfix mit meinem neuen
Relayhost digest-md5 spricht und ich selbst somit schon einmal
prinzipiell kein TLS bräuchte. Die Kiste soll aber später auch Relayhost
für einige User sein und ich weiß nicht, welche MUAs die verwenden
werden und inwieweit die cram-md5 oder digest-md5 können (ich kenne
natürlich die Tabelle mit den MUAs aus Eurem Buch). Ich denke, ich werde
dem Relayhost ohnehin noch TLS beibringen, aber soll ich die User
wirklich auf "Ohne TLS kein AUTH PLAIN" festnageln?

Mir ist schon prinzipiell klar, dass bei "AUTH PLAIN" TLS extrem
sinnvoll wäre, aber andererseits möchte ich für meine zukünftigen User
auch möglichst massenkompatibel :-) sein.

Mal ganz davon abgesehen, dass bei meinem Uni-Relayhost auch jahrelang
kein verschlüsselter SMTP-Dialog angeboten wurde. :-(

>> 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". ;)

Okay, summa summarum möchte ich mich ganz herzlich für Deine Hilfe und
die vielen ausführlichen Erklärungen bedanken. Nun habe ich mein
SMTP-Relay ja doch noch ans Laufen bekommen. :-)

Gruß,
Marcus
-- 
"Ich hab BIND Code gelesen. Und es war schrecklich. Ich hab tinydns Code
gelesen. Und es war schrecklich. Man sollte Paul Vixie und DJB mal DNS
erklaeren. Akademisch betrachtet ist tinydns minderwertig. Aber es funktioniert
halt. Angeblich." Thomas Ogrisegg in <b1mqec$14o900$3 at ID-103452.news.dfncis.de>