SMTPS

SMTPS im TCP/IP-Protokollstapel:

Anwendung	SMTP
Transport	SSL/TLS
	TCP
Internet	IP (IPv4, IPv6)
Netzzugang	Ethernet	Token Bus	Token Ring	FDDI	…

SMTPS (Simple Mail Transfer Protocol Secure) bezeichnet ein Verfahren zur Absicherung der Kommunikation beim E-Mail-Transport via SMTP über SSL/TLS und ermöglicht dadurch Authentifizierung der Kommunikationspartner auf Transportebene sowie Integrität und Vertraulichkeit der übertragenen Nachrichten. Eine Ende-zu-Ende-Sicherheit wird dadurch allerdings nicht erreicht, da alle Mailserver und Mailrelays die E-Mail im Klartext verarbeiten (müssen). Eine Sicherheit der E-Mail auf Anwendungsebene ist durch SMTPS nicht erreichbar.

SMTPS ist kein eigenes Protokoll und auch keine Erweiterung von SMTP, da es vollkommen transparent und unabhängig von diesem auf der Transportschicht arbeitet.

Das bedeutet, dass die Verbindung, über die SMTP abgewickelt wird, softwaremäßig mit den Verfahren SSL oder TLS abgesichert wird. Dies geschieht direkt beim Verbindungsaufbau, noch bevor irgendwelche Maildaten ausgetauscht werden. Da also die Verwendung der Sicherungsschicht nicht verhandelt wird, sind SMTPS-Dienste in der Regel auf einem eigenen TCP-Port erreichbar.

Ursprünglich hatte die Internet Assigned Numbers Authority Anfang 1997 den Port 465 für SMTPS registriert. Ende 1998 wurde dies (vorübergehend) widerrufen, als STARTTLS spezifiziert wurde. Mit STARTTLS kann derselbe Port ohne TLS und mit TLS genutzt werden. Für SMTP wurde das als besonders wichtig erachtet, weil Clients über dieses Protokoll auch fremde Server ansprechen, von denen sie nicht wissen können, ob sie einen separaten Port für TLS bieten. Im Jahr 2001 wurde Port 465 für URL Rendezvous vergeben, das zu Source Specific Multicast für Audio und Video gehört. Im Jahr 2018 änderte sich die Empfehlung abermals. RFC 8314 empfiehlt seitdem SMTPS mit implizitem TLS auf Port 465 gegenüber STARTTLS und gänzlich unverschlüsseltem SMTP zu bevorzugen.

Einzelnachweise

1. Re: Regularizing Port Numbers for SSL. (Nicht mehr online verfügbar.) Internet Mail Consortium, 30. April 1997, ehemals im Original; abgerufen am 25. September 2009 (englisch).@1@2Vorlage:Toter Link/www.imc.org (Seite nicht mehr abrufbar. Suche in Webarchiven.)  Info: Der Link wurde automatisch als defekt markiert. Bitte prüfe den Link gemäß Anleitung und entferne dann diesen Hinweis. 
2. Paul Hoffman: (Nicht mehr online verfügbar.) Internet Mail Consortium, 12. November 1998, archiviert vom Original am 31. März 2009; abgerufen am 22. Januar 2015 (englisch). 
3. Paul Hoffman: (Nicht mehr online verfügbar.) Internet Mail Consortium, 1. Juni 1997, archiviert vom Original am 19. August 2009; abgerufen am 22. Januar 2015 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.imc.org 
4. (Nicht mehr online verfügbar.) Internet Assigned Numbers Authority, 4. Juni 2001, archiviert vom Original am 4. Juni 2001; abgerufen am 23. Juli 2017 (englisch). 
5. (Nicht mehr online verfügbar.) Internet Assigned Numbers Authority, 25. Juli 2001, archiviert vom Original am 13. August 2001; abgerufen am 23. Juli 2017 (englisch). 
6. Source Specific Multicast with IGMPv3, IGMP v3lite, and URD. Cisco Systems, abgerufen am 23. Juli 2017 (englisch). 
7. Chris Newman, Keith Moore: RFC 8314 – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. (englisch).