Postfix smtps und Submission Confusion


13

Ich habe Postfix so eingerichtet, dass E-Mail-Clients Port 465 (smtps) für ausgehende E-Mails verwenden. Ich verstehe den Unterschied zwischen smtps (Port 465) und Submission (Port 587) nicht wirklich

Was ist die beste Vorgehensweise beim Konfigurieren von Postfix für Clients zum sicheren Senden von E-Mails? Verwenden Sie einfach smtps? Oder verwenden Sie sowohl Submission als auch Smtps?

Antworten:


21

Port 465 wurde für durch SSL gesicherte SMTP-Verbindungen verwendet. Die Verwendung dieses Ports für SMTP wurde jedoch mit der Verfügbarkeit von STARTTLS als veraltet eingestuft: "Den smtps-TCP-Port widerrufen" In diesen Tagen sollten Sie Port 465 nicht mehr für SMTPS verwenden. Verwenden Sie stattdessen Port 25, um E-Mails für Ihre Domain von anderen Servern zu empfangen, oder Port 587, um E-Mails von Clients zu empfangen, die E-Mails über Ihren Server an andere Domains und damit an andere Server senden müssen.

Als zusätzliche Anmerkung ist Port 587 jedoch für die Übermittlung von E-Mails vorgesehen - und die Übermittlung von E-Mails dient dazu, die Nachricht zu ändern und / oder eine Authentifizierung bereitzustellen:

  • Authentifizierung für Clients anbieten und verlangen, die versuchen, E-Mails zu versenden
  • Bereitstellung von Sicherheitsmechanismen, um das Versenden unerwünschter Massenmails (Spam) oder infizierter Mails (Viren usw.) zu verhindern
  • Ändern Sie die E-Mail an die Anforderungen einer Organisation (Umschreiben des Ab-Teils usw.).

Die Übermittlung an Port 587 soll STARTTLS unterstützen und kann daher verschlüsselt werden. Siehe auch RFC # 6409 .


Vielen Dank für Ihre Antwort, ich habe die Übermittlung erfolgreich mit Postfix eingerichtet und die Dinge sind mir jetzt viel klarer. :-)
Aditya K

Gern geschehen =)
Liquidation

1
Der Datenverkehr auf dem 465-Port ist vollständig verschlüsselt. Bei Verwendung von starttls kann der Client eine sichere Übertragung eingeben und das Senden von Daten ohne Verschlüsselung beenden. serverfault.com/q/523804/201912
QkiZ

2

TL; DR

Die neue Empfehlung ist, vorerst sowohl Submissions / Smtps als auch Submission mit STARTTLS zu unterstützen und das später auslaufende, sobald es nicht mehr verwendet wird. (Die gleichen Empfehlungen gelten auch für POP3 vs POP3S und IMAP vs IMAPS.)

Einzelheiten

Die Best Practice hat sich mit RFC 8314 Abschnitt 3.3 geändert :

Wenn eine TCP-Verbindung für den Dienst "Submissions" (Standardport 465) hergestellt wird, beginnt sofort ein TLS-Handshake. […]

Der STARTTLS-Mechanismus für Port 587 ist aufgrund der Situation mit Port 465 (siehe Abschnitt 7.3) relativ weit verbreitet. Dies unterscheidet sich von IMAP- und POP-Diensten, bei denen Implicit TLS auf Servern häufiger bereitgestellt wird als STARTTLS. Es ist wünschenswert, die von der MUA-Software verwendeten Kernprotokolle im Laufe der Zeit auf Implicit TLS zu migrieren, um die Konsistenz sowie die in Anhang A erläuterten zusätzlichen Gründe zu gewährleisten . Um die Verwendung der Verschlüsselung für die Übermittlung zu maximieren, ist es jedoch wünschenswert, beide Mechanismen für die Übermittlung von Nachrichten über TLS für einen Übergangszeitraum von mehreren Jahren zu unterstützen. Infolgedessen MÜSSEN Clients und Server für diesen Übergangszeitraum sowohl STARTTLS auf Port 587 als auch Implizites TLS auf Port 465 implementieren. Beachten Sie, dass es keinen signifikanten Unterschied zwischen den Sicherheitseigenschaften von STARTTLS an Port 587 und Implicit TLS an Port 465 gibt, wenn die Implementierungen korrekt sind und sowohl der Client als auch der Server so konfiguriert sind, dass eine erfolgreiche Aushandlung von TLS vor dem Senden von Nachrichten erforderlich ist.

Der zitierte Anhang A geht dann auf die Entscheidung ein, implizites TLS für alle SMTP-, POP3- und IMAP-Anwendungen zu bevorzugen, da dies die Hauptpunkte sind

  1. Wir wollen sowieso nur verschlüsselte Verbindungen überall haben, daher ist es sinnlos, eine abwärtskompatible Version all dieser Protokolle beizubehalten, wenn in der Praxis die Kompatibilität nicht verwendet wird
  2. Die STARTTLS-Verhandlungsphase wurde aufgrund identischer Probleme in mehreren Implementierungen ausgenutzt
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.