Diskussion:SMTPS
deprecated?[Quelltext bearbeiten]
Im englischsprachigen Wikipedia-Artikel steht "SMTPS [...] is a deprecated method for ", d. h. SMTPS wird als veraltet dargestellt. Wird SMTPS denn überhaupt noch entwickelt/gepflegt? Sollte dieser Hinweis auch in den deutschsprachigen Artikel? --Tonk (Diskussion) 12:47, 14. Aug. 2018 (CEST)
- Stimmt so nicht, da RFC 8314 implizites TLS (wie SMTPS) gegenüber STARTTLS bevorzugt. Im Englischen Artikel scheint es auch nicht mehr zu stehen und ich habe es hier jetzt auch mal ergänzt. --Exploide (Diskussion) 19:49, 11. Feb. 2019 (CET)
- Danke für den Hinweis. --Tonk (Diskussion) 14:47, 21. Feb. 2019 (CET)
Vor- und Nachteile / Quellen[Quelltext bearbeiten]
Ich schlage vor, eine Quelle anzugeben zu dem Satz
"Von der Verwendung des SMTPS- wird zugunsten des neueren STARTTLS-Verfahrens, welches keinen eigenen Port benötigt, abgeraten."
Wer rät ab ?
Denn STARTTLS hat auch einige Nachteile, wie man auf der STARTTLS-Seite nachlesen kann. Vielleicht sollte man hier bei der Bewertung zwischen der Verbindung zweier SMTP-Server (MTAs) und der Kommunikation zwischen Email-Client (MUA) und Server (MTA) unterscheiden ? STARTTLS würde ich bei der MTA-MTA Kommunikation bevorzugen, da so auf den Standardports automatisch eine Verschlüsselung aktiviert werden kann, sogar Internet-weit. SMTPS eher bei Client-MTA Verbindungen, da es hier kein großes Problem ist, am Client (MUA) einen anderen Port anzugeben. Das ist aber meine persönliche Einschätzung.
Die Sicherheit ist bei SMTPS offensichtlich höher.
Siehe auch Wikipedia:Auskunft/Archiv/2007/Apr#SMTP-.C3.BCber-TLS-Varianten.
--Ralfk 09:29, 13. Jun. 2007 (CEST)
- Die Bemerkung zum Abraten schrieb ich aus dem Kopf, die Quelle hatte ich zu dem Zeitpunkt im RFC 3207 gesucht und nicht gefunden. Jetzt fiel mir wieder ein, daß das was ich meinte in RFC 2595, Abschnitt 7 steht. Es behandelt allerdings nicht smtps, sollte aber auch darauf anwendbar sein. Wobei Du Recht hast, POP3 und IMAP werden im Gegensatz zu SMTP nicht zwischen Servern verwendet.
- Die im STARTTLS angesprochene Ausfilterung des Keywords durch manche Firewall und auch Angreifer findet durchaus statt bzw. ist möglich. Wenn aber der User den MUA anweist nur TLS zu verwenden und dies nicht zur Verfügung steht ist das auch leicht detektierbar und der User kann benachrichtigt werden. Das erfolgt einen Schritt später in der Kommunikation, Sicherheit kostet das aber mMn nicht. --jailbird 11:18, 13. Jun. 2007 (CEST)
Du hast Recht. Wenn der Server kein TLS unterstützt, melden gute MUAs das, wenn am MUA TLS fest eingestellt ist. Hab ich soeben mal mit Mozilla Thunderbird und kmail getestet. Trotzdem: vielleicht sind Ratschläge, wann man was nutzen sollte, nicht so gut aufgehoben in der Wikipedia ? --Ralfk 14:51, 14. Jun. 2007 (CEST)
- Ich bin auch generel dagegen die Wikipedia in einen Ratgeber zu verwandeln. Wenn es aber – wie für POP und IMAP – den Rat gibt (noch dazu im RFC, also nicht ganz unmaßgeblich), sollten wir das hier auch erwähnen. Da es nun diese Bemerkung aber anscheinend nicht ausdrücklich für SMTP gibt, ist es für mich aber auch OK den Teil umzuschreiben. Wobei ich die Entfernung des Ports 465 aus der Liste der well-known-ports durchaus immer noch als Hinweis der IANA sehe, in Richtung STARTTLS zu gehen. --jailbird 15:55, 14. Jun. 2007 (CEST)
Ich sehe das persönlich nicht so kritisch, ob Du den "Abraten"-Text so drin lässt oder nicht. Es könnte sich aber vielleicht noch irgendwann ein "Wikipedia-Hardliner" kritisch dazu äußern. Dann können wir die Diskussion ja weiter führen. Den Hinweis auf Port 465 halte ich aber für wichtig, das ist richtig. --Ralfk 10:56, 15. Jun. 2007 (CEST)
- Wie passt Port 587 in dieses Weltbild? Dass „Message Submission sich aber nie weitreichend durchsetzen konnte“ ist wo nachvollziehbar oder belegt? --84.157.235.173 22:53, 22. Sep. 2015 (CEST)
- Message Submission auf Port 587 ist ausgewachsener Internet-Standard.[1] Weitreichender gehts garnicht. --84.157.192.69 18:44, 29. Feb. 2016 (CET)
- Im Dezember 2017 wurde der Port 465 wieder "offiziell" für "Message Submission over TLS" registriert (d.h. smtps) und mit RFC8314 wird implizites TLS gegenüber STARTTLS bevorzugt. Im Prinzip hat sich damit der halbe Artikel um 180 Grad gedreht. --Istalix 14:53, 28. Feb. 2018 (CET)
Irreleitend[Quelltext bearbeiten]
Der Artikel ist irreleitend. Vor allem der Ausschnitt: "ermöglicht dadurch Authentifizierung der Kommunikationspartner sowie Integrität und Vertraulichkeit der übertragenen Nachrichten." Welche Kommunikationsparnter? Gemeint ist lediglich die Kommunikation zwischen den einzelnen Mailservern und Mailrelays. Auf keinen Fall wird aber eine Ende-zu-Ende-Sicherheit erreicht. Die Kommunikationspartner auf der Anwendungsschicht sind weder authentifiziert, noch ist die Integrität gewahrt. Auf keinen Fall ist das eine sichere Kommunikationsmöglichkeit für E-Mails. (nicht signierter Beitrag von 138.246.2.202 (Diskussion) 16:07, 7. Feb. 2014 (CET))
- Was etwas ermöglicht, garantiert eben nicht alles. Aber warum soll denn jetzt die „Ende-zu-Ende-Sicherheit“ auf der „Anwendungsebene“ „durch SMTPS nicht erreichbar“ sein? Verhindert SMTPS sie etwa? Das SMTP von SMTPS ist auf der „Anwendungsebene“. Eigentlich ist beides für eine direkte Verbindung zwischen Absender und Adressat gedacht. Wer Mailrelays ins Spiel bringt oder sie beim Adressat vermutet und denen nicht trauen kann, muss eben mehr tun. Ohne SMTPS werden zumindest die Header unverschlüsselt übertragen! SMTPS ist die Grundlage für Integrität und Vertraulichkeit. --84.157.235.173 22:53, 22. Sep. 2015 (CEST)
Defekte Weblinks[Quelltext bearbeiten]
| Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt. |
|---|
|
- http://www.imc.org/ietf-apps-tls/mail-archive/msg00077.html
- Vielleicht ist eine archivierte Version geeignet: archive.org
- http://www.imc.org/ietf-tls/mail-archive/msg00771.html
- Im Jahr 2012 bereits defekt gewesen.