Postfix schlägt bei eingehendem SMTP von Remote-MTAs für die lokale Zustellung fehl

Postfix schlägt bei eingehendem SMTP von Remote-MTAs für die lokale Zustellung fehl

Ich übertrage MTA auf neuere Server mit Ubuntu 20.04 LTS. SMTPS funktioniert gut und ermöglicht es Clients, nach der Authentifizierung E-Mails zu senden. Beim Senden von E-Mails von Remote-MTAs zur lokalen Zustellung schlägt Postfix jedoch aufgrund von fehl fatal: no SASL authentication mechanisms.

Dec 28 12:22:03 smtp postfix/smtpd[63402]: connect from unknown[1.2.3.4]
Dec 28 12:22:03 smtp postfix/smtpd[63402]: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
Dec 28 12:22:03 smtp postfix/smtpd[63402]: fatal: no SASL authentication mechanisms
Dec 28 12:22:04 smtp postfix/master[63342]: warning: process /usr/lib/postfix/sbin/smtpd pid 63402 exit status 1
Dec 28 12:22:04 smtp postfix/master[63342]: warning: /usr/lib/postfix/sbin/smtpd: bad command startup -- throttling

Es gibt hier bereits Fragen zu ähnlichen Themen. Aber dieses Mal ist es anders:

  • SASL funktioniert einwandfrei und authentifiziert sich über saslauthd gegenüber dem LDAP-Verzeichnis. Es fehlt also keine Plugin-Installation für SASL.
  • Die Authentifizierung funktioniert gut, wenn eine Verbindung über SMTPS hergestellt wird. Sie schlägt nur am regulären SMTP-Port 25 fehl.

Beim Testen der SMTP-Konnektivität mit netcat wird die Verbindung geschlossen, bevor die HELO-Zeichenfolge des Servers gesendet wird. Ich habe also herausgefunden, dass dies damit smtpd_client_restrictionszusammenhängt/etc/postfix/main.cf:

smtpd_client_restrictions =
        permit_sasl_authenticated
        # postgrey:
        check_policy_service inet:localhost:10023

Dies ist erforderlich, um zu verhindern, dass ausgehende E-Mails von authentifizierten Absendern dem Greylisting unterliegen.

Im Namen von/etc/postfix/main.cfSASL ist wie folgt konfiguriert:

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous,noplaintext
smtpd_sasl_tls_security_options = noanonymous
broken_sasl_auth_clients = yes

Die Zeilen 2 und 3 sind hier erforderlich, um Klartext-Logins in unverschlüsseltem SMTP zu verhindern, akzeptieren dies aber, nachdem der Client TLS über STARTTLS gestartet hat oder falls der Client eine Verbindung über SMTPS herstellt. Ich sehe, dass das STARTTLS-Szenario weggelassen werden könnte, um die gesamte Authentifizierung über TLS-verschlüsseltes SMTPS zu erzwingen, und ich könnte SASL über master.cf nur für SMTPS aktivieren. Aber bestehende Benutzer sollten ihr Setup überhaupt nicht anpassen.

Antwort1

Soweit ich das beurteilen kann, liegt das Problem an

smtpd_sasl_security_options = noanonymous,noplaintext

in Kombination mit SASL-Authentifizierung gegenüber LDAP-Verzeichnis über saslauthd. Dies führt dazu, dass PLAIN und LOGIN die einzigen verfügbaren Anmeldemethoden sind. Aus noplaintextdiesem Grund sind beide deaktiviert. Ich möchte, dass Postfix keine Authentifizierung anbietet, wenn keine SASL-Methoden verfügbar sind.

Für TestzweckeIch war in der LageFixDies können Sie tun, indem Sie eine weitere Login-Methode in/etc/postfix/sasl2/smtpd.conf:

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN CRAM-MD5

Auf diese Weise akzeptierte SMTP eingehende Verbindungen über SMTP für Remote-MTAs.Dies ist jedoch keine Lösungim Moment gibt es eine Login-Methode, die tatsächliche Clients zur Authentifizierung wählen würden, obwohl nicht damit zu rechnen ist, dass sie jemals erfolgreich sein wird. Siehehttp://www.postfix.org/SASL_README.htmlfür weitere Informationen zum Einrichten von Cyrus SASL für die Verwendung mit saslauthd.

Also suchte ich weiter und stieß auf eine weitere Option, die ich offensichtlich falsch gelesen hatte und deshalb beim Übertragen der Konfiguration übersprungen hatte: smtpd_tls_auth_only. Diese boolesche Option steuert, ob TLS für die Authentifizierung erforderlich ist. Sie ist nostandardmäßig gesetzt, wodurch die SASL-Authentifizierung für unverschlüsseltes SMTP eingerichtet wird. Nachdem ich diese Option yesinmain.cfDatei-SMTP funktioniert wieder einwandfrei.

Antwort2

Ich habe festgestellt, dass die Lösung darin besteht, diese Zeile in der Datei master.cf zu kommentieren

-o smtpd_tls_auth_only=yes

verwandte Informationen