Diskussion:Simple Mail Transfer Protocol

message: Bitte neue Diskussionsthemen als Abschnitt unten anhängen. -- Stefan506 13:39, 24. Sep 2005 (CEST)

message: 1XX: Mailserver hat die Anforderung akzeptiert, ist aber selbst noch nicht tätig geworden. Eine Bestätigungsmeldung ist erforderlich.
Was ist eine Bestätigungsmeldung  ? --84.143.116.111 19:16, 11. Feb. 2007 (CET)
replies: text: Es gibt diese mit der Zahl 1 beginnenden Statusmeldungen nicht, von denen der Artikel erzählt. --84.157.192.123 11:15, 7. Mai 2011 (CEST)
replies: text: Nicht mehr. Im aktuellen RFC 5321 sind die 1xy-Replies verschwunden ( Kapitel 4.2.1). Im Vorgänger RFC 2821 von 2001 gab es sie noch ( Kapitel 4.2.1). Dass alle SMTP-Server der Welt schon auf den neuen RFC umgestellt sind, wage ich zu bezweifeln. ;-) --AchimP 11:38, 7. Mai 2011 (CEST)

text: Achim, ich bin dir dankbar für den Hinweis, denn er lässt mir überlegen, was man wohl einst damit realisieren wollte. Kann man es erläutern und belegen, dass es zu einem Erkenntnisgewinn führt? Wohl kaum. In der Realität gibt es diese Statusmeldungen nicht. Sonst hätte die IETF, die beim SMTP keinen alten Zopf abschneidet, zumindest ein may und ein should dafür übrig gehabt. Aber die IETF hat in diesem Fall keine Zweifel. --84.157.192.123 17:10, 7. Mai 2011 (CEST)
thread_title:  Verständnissfrage 

message: Könnte auf den SSL- und TLS-Teil dieses Artikels mehr eingegangen werden? inwieweit läuft dieser ab? wie funktioniert SMTP per SSL und TLS (ich sag nur mal: wo kommen die Zertifikate und öffentlichen Schlüssel her)?
Hört die sicherheit durch verwenden von SSL und TLS nicht hinter dem SMTP-Server auf? mit ssl und tls verschlüssel ich ja nur den weg zwischeb mir und smtp server. was dann geschieht, steht in der macht des e-mail-anbieters. danke, --Abdull 19:03, 25. Jan 2005 (CET)
thread_title:  SMTP und SSL / TLS 

message: Warum soll das nicht eingesetzt werden???
Jeder freemailer hat das doch um nicht als open relay zum dienen!!
fragen tut gut 14:34, 28. Feb 2005 (CET)
replies: text: Weil die meisten einfach SMTP after POP verwenden. --217.91.169.64 11:52, 9. Apr. 2015 (CEST)
replies: text: "Die meisten" wage ich mal schwer zu bezweifeln, SMTP after POP ist extrem veraltet. --Zac67 (Diskussion) 13:03, 9. Apr. 2015 (CEST)
thread_title:  Einsatzhäufigkeit von SMTP-Auth 

message: Bei der angebildeten SMTP-Sitzung fehlen meiner Einschätzung nach die
<CRLF>s am Ende jeder Zeile des Client. Werden diese nicht mit geschickt,
macht der Server nix und wartet einfach weiter ab.
Telnet fügt dies zwar eigenständig beim Drücken der Eingabetaste ein, ein
Programmierer wird aber Probleme bekommen, wenn er eine SMTP-Sitzung ohne
die <CRLF>s versucht. Mtuxgu 10:54, 11. Jun 2006 (CEST)
replies: text: Siehe „Wikipedia ist keine Sammlung von Anleitungen“ --79.222.236.32 18:36, 2. Jul. 2023 (CEST)
thread_title:  Das Protokoll: Hinweis auf <CRLF> 

message: Hallo,
mir ist bei der Literaturquelle von RFC 2821 aufgefallen, 
dass nur RFC 821 und RFC 1869 
als technisch überholt (obsolete) angegeben wurden, nicht aber RFC 974.
Generell fehlt der Literaturhinweis auf RFC 974 (MAIL ROUTING AND THE DOMAIN SYSTEM).
Gibt es einen speziellen Grund dafür?
Freundliche Grüsse,
Heinrich Elsigan, Tue, 02 Jan 2007 17:34:06 +0100
: „Obsoleted by RFC 2821“ --79.222.236.32 18:36, 2. Jul. 2023 (CEST)
thread_title:  Fehlt bei Literatur RFC 974? 

message: Der "SMTP – das (un)sichere E-Mail-Protokoll? – Artikel auf IT-Defender.com" Link ist defekt. (nicht signierter Beitrag von 91.14.146.146 (Diskussion | Beiträge) 20:58, 13. Mär. 2010 (CET)
thread_title:  Links 

message: "SMTP begann als reines ASCII-Protokoll, so dass damit keine Binärdateien übertragen werden konnten. Erst Standards wie MIME (Multipurpose Internet Mail Extensions) schufen diese Möglichkeit durch ein Kodieren der Binärdateien in ASCII."
Sollte hier nicht ein Verweis auf uucode rein.. denn Mime kam doch viel später, oder ?
--84.130.242.226 23:58, 21. Jun. 2014 (CEST)
replies: text: MIME kam einiges später, ist allerdings ein Mail-Standard, während uucode 'einfach so' verwendet wurde – wenn man es genau nimmt, transportiert die Mail damit keine Binärdaten, sondern die Binärdaten werden vorher (vom Benutzer) auf 7 Bit kodiert. Ein passender Hinweis auf uucode würde allerdings bestimmt nicht schaden. Zac67 (Diskussion) 00:12, 22. Jun. 2014 (CEST)
thread_title:  Binärdateien 

message: Ein einfacher Ansatzpunkt für eine Verbesserung des Protokolls ist seit langem bekannt, wurde aber nie umgesetzt.
Bereits bei der Anmeldung des Clients am Server, nach der Nennung des Client-Namens, könnte der Server den DNS-Namen abfragen und mit der IP des Clients vergleichen.
Existiert der Name nicht, oder stimmen die IP-Adressen nicht überein, handelt es sich sehr wahrscheinlich um einen Versuch, ein Mail mit einer gefälschten Adresse abzugeben, sozusagen gleich an der Tür des Empfängers. Eine Option, um eine solche DNS-Abfrage des Servers auf Wunsch des Kunden dazwischen zu schalten, würde bei der Vermeidung von SPAM Wunder wirken. Es würden praktisch nur noch Mails von Mailausgangsservern übernommen werden.
Um die Sicherheit weiter zu erhöhen könnte der Empfängerserver den Absenderserver zudem anfragen, ob er ihm gerade ein Mail schickt. Das wäre dann ein zusätzlicher Vorgang mit einem eigenen Protokoll, der vom Versender der Mail nicht bemerkt würde, wenn es sich nicht um den Absenderserver handelt. So liesse sich wiederum eine relativ sichere Dokumentenübermittlung erreichen.
Nicht bestätigte Adressen und Übermittlungen wären somit ungültig und könnten dem Bereich der Dokumentenfälschung zugeordnet werden. 
: Das mag sein oder nicht, aber diese Seite ist zur Diskussion über den Artikel selbst, nicht zur Diskussion über SMTP allgemein: Hilfe:Diskussionsseiten, Wikipedia:Keine Theoriefindung --09:08, 4. Aug. 2019 (CEST)
thread_title:  unsicheres Protokoll 

message: Wo findet man, wie „Abholung von E-Mails eventuell über mehrere Stationen“ funktionieren soll? --79.222.236.32 18:36, 2. Jul. 2023 (CEST)
replies: text: "Abholung" (pull) ist nicht korrekt, "Übertragung" (push) trifft es eher. --Matthäus Wander 17:24, 19. Jul. 2023 (CEST)
thread_title:  Einsatzgebiet