- Details
Das im Januar 2018 veröffentlichte RFC 8314 "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access" beschreibt die Verwendung von TLS bei E-Mail-Abruf und -Einlieferung in modernen E-Mail-Systemen. E-Mail-Abruf und -Einlieferung durch Mail User Agents (MUAs) bei Mail Access Servern und Mail Submission Servern sollen demnach nur noch über TLS-verschlüsselte Verbindungen (TLS Version 1.2 oder höher) erfolgen.
Neu, beachtens- und begrüßenswert ist, dass jetzt "Implicit TLS" die favorisierte Methode für die Transport-Verschlüsselung bei Abruf und Einlieferung von Mails durch MUAs ist, während vorhergehende Regelungen noch STARTTLS empfahlen. Folgerichtig wurde der bereits vielerorts für Secure Submission verwendete Port 465 im Dezember 2017 auf den Dienst Submissions offiziell registriert. RFC 8314 ist auch ein Update für die Spezifikationen von POP3 (RFC 1939), IMAP (RFC 3501) und Submission (RFCs 6409 und 5068).
Mit STARTTLS stellt ein Client zunächst eine unverschlüsselte Verbindung auf dem (in der Regel Standard-)Klartext-Port des gewünschten Dienstes mit einem Server her und kann anschließend durch das Kommando STARTTLS (STLS bei POP3) eine TLS-Session initiieren ("Explicit TLS"). Im Unterschied dazu wird bei "Implicit TLS" direkt nach dem TCP Handshake ein TLS-verschlüsselter Kanal zwischen Client und Server aufgebaut.
Authentifizierungs-Daten sollen bei beiden Methoden erst dann über die Leitung gehen, wenn die Verbindung verschlüsselt ist. Für SMTP, IMAP und POP3 sind denn auch jeweils Methoden (siehe unten) definiert, genau dies vom Client zu fordern, will man keinen Klartext-Verkehr erlauben. Doch sind diese natürlich im Gegensatz zur impliziten TLS-Verschlüsselung auf dedizierten TLS Ports bereits protokollbedingt anfällig für Implementierungs-Schwächen auf Client-Seite und Man-in-the-middle-Angriffe.