Am 20.02.19 um 13:09 schrieb Markus Schönhaber:

Stefanie Leisestreichler, 20.2.2019 12:53 +0100:

...

Es fehlen bei der Rückmeldung des MX beim Connect jegliche Angaben wie AUTH-250 LOGIN, usw., obwohl ich die folgenden Sasl-Parameter benutze:

# SASL smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous # zeigt "250-AUTH=..." zusätzlich zu "250-AUTH ..." ohne =, bspw. für Outlook bis Version 2003: broken_sasl_auth_clients = yes smtpd_sasl_local_domain = example.de

Poste mal die Ausgabe von postconf -n auf der Postfix-Maschine. Das zeigt die tatsächlich verwendeten und vom Standard abweichenden Einstellungen.

Evtl. findest Du aber auch schon mit egrep '(warning|error|fatal|panic):' /Dein/Mail/Logfile einen Hinweis, was Sache ist.

Gerne. Anbei die Ausgabe von postconf -n. Ich hatte smtpd_tls_auth_only = yes schon auf no gesetzt, aber auch dann wird AUTH nicht angeboten. Das Log enthält zwar einen Error, aber nicht in Zusammenhang mit AUTH/SASL, sondern weil postmaster noch nicht korrekt umgeschrieben wird.

alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes canonical_classes = envelope_sender canonical_maps = hash:/etc/postfix/canonical compatibility_level = 2 delay_warning_time = 1h inet_interfaces = all inet_protocols = all mailbox_size_limit = 0 mydestination = intranet.example.de, pp-mail-2018.intranet.example.de, localhost, localhost.intranet.example.de myhostname = mx18.mxtest.example.de mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.177.0/24 myorigin = /etc/mailname notify_classes = bounce, 2bounce, delay, protocol, resource, software parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients readme_directory = no recipient_delimiter = + relayhost = remote_header_rewrite_domain = domain.invalid smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_banner = $myhostname smtpd_client_restrictions = reject_rbl_client ix.dnsbl.manitu.net smtpd_helo_required = no smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:60000 smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = example.de smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sender_restrictions = smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/mx18.example.de.HE_CombinedCert-20190125.crt smtpd_tls_key_file = /etc/ssl/private/mx18.example.de.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_use_tls = yes strict_rfc821_envelopes = no virtual_alias_maps = hash:/etc/postfix/virtual_mailboxes_aliases virtual_gid_maps = static:2222 virtual_mailbox_base = /var/spool/virtual_mailboxes virtual_mailbox_domains = mxtest.example.de, example.de virtual_mailbox_maps = hash:/etc/postfix/virtual_mailboxes_recipients virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_uid_maps = static:2222

* Stefanie Leisestreichler stefanie.leisestreichler@peter-speer.de:

Am 20.02.19 um 14:46 schrieb Patrick Ben Koetter:

...

Kann es sein, dass Du AUTH nur dann gestattest, wenn eine TLS-Session existiert? Das ist dann der Fall, wenn Du entweder smtpd_tls_auth_only gesetzt hast oder smtpd_tls_security_level=encrypt forderst.

Das war der entscheidende Hinweis: smtpd_tls_auth_only war gesetzt. Nach dem Setzen auf "no" kommt 250-AUTH PLAIN LOGIN und 250-AUTH=PLAIN LOGIN nach der erfolgreich ausgehandelten TLS-Session.

Ich habe jetzt meine Konfiguration jetzt in diesem Bereich so abgeändert, dass sie Deiner entspricht:

smtpd_tls_security_level=encrypt smtpd_tls_auth_only = no

Du kannst das "smtpd_tls_auth_only = no" in der config weglassen, denn das Verhalten ist default.

Eine Frage stellt sich mir hierbei: Das heisst doch implizit, dass niemand dort Mails einkippen kann, der nicht in der Lage ist eine TLS-Session aufzubauen, oder irre ich mich?

Wenn Du smtpd_tls_security_level=encrypt setzt, dann erzwingt der Postfix smtpd Server eine TLS-Session. Ohne TLS wird er nicht mit dem Client sprechen.

Weil die RFCs verbieten auf einem "publicly referenced MTA" (lies: MTA, welcher laut DNS der MX ist) TLS zu erzwingen, darf man seinen MX deshalb auf Port 25 nicht mit smtpd_tls_security_level=encrypt betreiben.

Für MUAs (lies: Outlook, Thunderbird etc.) richten Postmaster und -mistresses deshalb zusätzlich eine smtpd-Instanz auf Port 587 ein. Dort erzwingen wir TLS und *nur dort* bieten wir auch AUTH an. Und auch *nur dann* wenn eine TLS-Session etabliert wurde.

Der Grund hierfür ist: Nur die SASL Mechanismen PLAIN und LOGIN gestatten eine kryptierte Speicherung von Passworten, die es bei Diebstahl schwierig bis unmöglich machen, sie zu nutzen. Wer PLAIN und LOGIN einsetzt, holt sich damit aber den Nachteil an Bord, dass diese SASL-Mechanismen als base64 kodierter Plaintext (lies: ungeschützt) über den Ether gehen.

Um ein Abfangen der Identität (Login, Kennwort) bei der Übertragung zu verhindern, erzwingen wir deshalb TLS. Dann ist die Strecke zwischen MUA und MSA – so heißt ein MTA, der Submission auf Port 587 anbietet – verschlüsselt und PLAIN oder LOGIN können sicher genutzt werden.

Und: Wie wirkt sich das bspw. auf Scripts aus, die z.B. per "mail" aus $mynetworks getriggert werden. Können diese dann überhaupt noch dort abgeladen werden?

Diese Frage verstehe ich nicht ganz. Meinst Du damit Skripte, die aus Netzwerksicht aus $mynetworks kommend eine Mail bei Deinem Postfix Server abgeben wollen? Wenn sie (client) in $mynetworks sind und der Server eine Regel permit_mynetworks in einer der smtpd_*_restrictions hat, dann sollten die Skripte an interne Ziele senden und sogar an externe Ziele relayen dürfen. Eine AUTH ist dafür nicht erforderlich, weil sie durch permit_mynetworks autorisiert werden.

Herzlichen Dank an alle für die nette Hilfe.

Gerne.

HTH

p@rick

Am 20.02.19 um 16:54 schrieb Stefanie Leisestreichler:

Deine Hinweise werde ich 1:1 umsetzen: Port 25 unverschlüsselt, ohne Auth, Port 587 mit TLS und Auth.

Ich habe es jetzt so konfiguriert und alles läuft, wie von Dir vorgeschlagen. Dieser implizite Hinweis auf swaks war ebenfalls sehr hilfreich :-)

Wenn ich die Tipps von Alex noch umgesetzt habe, dann habe ich hoffentlich einen Server am Start, der sich sehen lassen kann da draussen...

Nochmal danke an alle, Euer Support ist einfach genial! Alleine hätte ich das nie geschafft.