Freshmail.de - E-Mail Geschichte und Funktionsweise

Geschichte
Funktionsweise

SMTP Statuscodes
Die wichtigsten RFCs im Zusammenhang mit E-Mail

Geschichte

Als Erfinder der E-Mail kann man Ray Tomlinson aufführen, der bereits 1971 erste Tests mit E-Mail durchführte. Ende 1971 waren auf dem Betriebssystem TENEX zwei Programme mit dem Namen SNDMSG/READMAIL verfügbar, die dazu dienten, Nachrichten zwischen Benutzern auf der gleichen Maschine auszutauschen: Eine Art lokales E-Mail, welches immer nur auf eine Maschine und deren angemeldete Benutzer beschränkt war. Tomlinson verband das SNDMSG Programm mit dem Programm "CPYNET", welches zum kopieren von Dateien über das Netzwerk gedacht war. Tomlinson hatte auch das Problem der Adressierung zu lösen und entschied sich für das Konstrukt "Benutzer AUF Maschine". Er wählte für das "AUF", das "@" Symbol. Die erste E-Mail wurde dann jedoch noch nicht im Internet versendet, denn so wie wir es heute kennen, existierte das Netz noch nicht. Der Versand ging von einer Testmaschine zu einer anderen, die sich im gleichen Raum befanden. Angeblich war "QWERTYUIOP" der Inhalt dieser ersten Mail. Tomlinson modifizierte das Programm dahingehend, dass es mit ARPANET funktionierte.

Nach bereits ca. zwei Jahren wurde E-Mail von einer Reihe von Netzwerkteilnehmern als Mittel zur Kommunikation miteinander genutzt und war sogar die Technologie, die im frühen Netz am meisten genutzt wurde (1975 soll E-Mail bereits 75% des damaligen ARPANET Traffics ausgemacht haben).
Die Nachrichten wurden direkt an die Maschine gesendet, die auch dem Empfänger zugeordnet war. Eine Zwischenlagerung, wie es mit POP und IMAP funktioniert, gab es noch nicht (Es gab einfach keine Verwendung dafür, denn hauseigene Internetanschlüsse existierten noch nicht).

1972 wurden zwei zusätzliche Kommandos in das damalige FTP Programm integriert: MAIL und MLFL. E-Mail wurde bis in die 80er über das FTP Protokoll versendet. Im Prinzip wurde eine Kopie einer Nachricht via FTP auf eine entfernte Maschine übertragen. Ein eigenes Protokoll für E-Mail gab es noch nicht.
Mit fortschreitender Nutzung wurde dann jedoch das SMTP Protokoll entwickelt, welches maßgebliche Vorteile gegenüber dem FTP Protokoll hatte:

• Effizienz
• Es musste für eine Reihe von Empfängern auf einer anderen Maschine lediglich eine Nachricht versendet werden. Nicht mehr eine Sendung pro Empfänger.

1982 verfasste Jonathan B. Postel das RFC #821 zu SMTP.
E-Mail wurde zu einem täglich genutzten Werkzeug, welches jedoch noch wenig Komfort bot. Der damalige Direktor der ARPA, Steve Lukasik, bat um eine Reihe von Verbesserungen an E-Mail. Auf eine Anfrage hin nahm Lawrence Roberts eine Reihe von Verbesserungen vor und implementierte diese in ein Programm namens RD. RD war tatsächlich eher eine Sammlung von Macros für den TENEX Texteditor TECO.
RD konnte immerhin schon E-Mails sortieren, löschen, lesen und speichern und das sogar nach den Wünschen des Benutzers sortiert. Die Idee und die Notwendigkeit entstand aus der Not, die empfangenen E-Mails irgendwie verwalten zu müssen. Bis dahin hatten sich viele Leute eigene Lösungen gebaut. Ein regelrechtes Programm zum Managen der eingegangenen E-Mails, gab es nicht.
Barry Wessler wiederrum fügte noch weitere Verbesserungen hinzu und nannte das Programm NRD.
Parallel dazu machte sich Marty Yonke an ein rewrite von SNDMSG und NRD und fasste deren Funktionalitäten in einem eigenständigen Programm namens WRD zusammen. Das Programm bot zudem eine leicht verständliche Hilfe für Benutzer mithilfe eines eigenen integrierten Hilfesystems.
WRD wurde später in BANANARD umbenannt und erfuhr noch weitere Änderungen, u.a. durch John Vittal, der Funktionen wie Weiterleiten implementierte und das Programm auch gleich in MSG umbenannte. MSG war das erste E-Mail Programm, welches von der Grundfunktionalität der heutigen E-Mail Software entspricht.

1975 wurde ein Projekt angestartet mit dem Ziel, das MSG Programm auch auf dem Unix Betriebssystem verfügbar zu machen.
Das Design übernahm kein geringerer als Dave Crocker. An der Implementierung waren Steve Tepper und Bill Crosby beteiligt.
Das Ergebnis war eher ernüchternd. Das Programm bot zwar eine Reihe von Funktionen und war multiuserfähig, aber es war auch sehr langsam. Ein Folgeprojekt implementierte die vorhandenen Funktionen neu - und zwar diesmal modular: Für einige Befehle und Funktionsteile wurden eigenständige Programme geschrieben. Das Ergebnis war MH und war lange Zeit das Standard-E-Mail Programm unter Unix.

1977 erstellten David H. Crocker, John J. Vittal Kenneth T. Pogran und D. Austin Henderson das RFC #733 mit dem Inhalt "STANDARD FOR THE FORMAT OF ARPA NETWORK TEXT MESSAGES(1)". Eine Reihe verteilter Informationen zu E-Mail und wie sie auszusehen hat und zusätzliche, eigene Ideen wurden nun erstmals in einem einzigen Dokument zusammengefasst.
RFC #733 wurde 1982 nochmals von David Crocker überarbeitet und als RFC #822 publiziert. RFC #822 wurde auch als Standard zur Schreibweise von Domainnamen angenommen.

1978 plante die U.S. AMC (Army Materiel Command) eine Software, die es Netzwerkteilnehmern mit temporären Anschlüssen ermöglicht und die nicht direkt am ARPA angeschlossen waren, E-Mail zu nutzen. Ab dem Zeitpunkt sprach man von E-Mail Relays. Das erste Relay dieser Art war an der University of Delaware in Betrieb und ermöglichte E-Mail für einige AMC Sites. Das war das Ergebnis einer 6 monatigen Arbeit Crockers. Da es noch keine TCP/IP Netze gab, lag eine Herausforderung darin, Protokoll-Links zu schreiben, um Daten zwischen den Netzen erfolgreich auszutauschen.

Anfang der 80er wurde E-Mail über UUCP (Unix-to-Unix-Copy-Protocol) versendet. Eric Allman brachte einen Teil verschiedener E-Mail Programme und Transport Services zusammen zu einer komplexen E-Mail Transport- und Speicher-, bzw. Verwaltungslösung. Aufgrund der reichlichen Erfahrung die Allman mit seiner Arbeit sammeln konnte, entwickelte er sendmail, einen echten SMTP Server.

Als sich das Internet so gestaltete, wie wir es heute kennen, kamen eine ganze Reihe weiterer Mailserver auf. Heute ist E-Mail noch immer das Internetkommunikationsmittel Nr. 1.


Weitere Links zur E-Mail Geschichte:

• E-Mail Systeme im ARPA Netzwerk: RFC #808
• Die Evolution der ARPANET E-Mail Systeme.

Funktionsweise

Wie eine E-Mail ihr Ziel erreicht

Die Schreibweise von E-Mail Adressen ist weithin bekannt.
Sie lautet: benutzer@zielsystem oder auch etwas technischer: benutzer@server. Beides zusammen definiert eine eindeutige (E-Mail)Adresse eines Internetteilnehmers.Benutzer ist eine Kennung die sich der Betreffende überlicherweise selbst aussucht und möglicherweise ist das sein Name. Zielsystem verrät, wo der Benutzer zu finden ist, auf welchem System der Benutzer sein E-Mail Konto hat.

Um eine Mail zu verfassen, könnte man folgendes tun:

to: test@freshmail.de subject: Testnachricht Hier steht der Text.

Im Prinzip ist das als Information für ein E-Mail Programm ausreichend.

Wenn Sie diese Mail nun versenden wollen, fügt Ihr E-Mail Programm wahrscheinlich weitere Informationen in einen E-Mail Header ein. Das kann Datum und Uhrzeit sein, Version des E-Mail Programms, das Betriebssystem usw..

Das E-Mail Programm muss die Mail nun einem MTA, dem eigentlichen Mailsystem übergeben. Das System kann lokal laufen oder aber auf einer entfernten Maschine, wie es für die Nutzung im Allgemeinen üblich ist (die wenigsten nennen einen eigenen Internetserver in ihren 4 Wänden ihr Eigen).

Ist die Mail korrekt formatiert und die Mailadresse gültig, so nimmt sie der Mailserver(MTA) an und die Aufgabe des lokalen E-Mail Programms ist getan. Alles weitere übernimmt zunächst der Mailserver, der nun versucht eine Verbindung zum Zielsystem herzustellen.
Heute ist SMTP als Transportprotokoll für E-Mail üblich. Und SMTP hat strenge Vorgaben, wie ein solcher Transport auszusehen hat: SMTP verlangt, dass eine Mail in 2 Teilen versendet wird. Der erste Teil ist der sog. Envelope, was sich als Umschlag übersetzen lässt. Der Mailenvelope ist mit dem Briefumschlag eines normalen Briefes zu vergleichen. Er enthält Zieladresse und die Adresse des Absenders.
Dies ist nötig, um im Falle eines Fehlers den Absender darüber zu informieren, was genau nicht funktioniert hat.

Wurde die Mail am Zielsystem akzeptiert, wird die Nachricht in das Postfach der betreffenden Person einsortiert und der Benutzer kann sich die Mail abholen.

E-Mail Header

Envelope vs. Header

Es ist ein weit verbreiteter Irrtum, dass der Envelope gleichzeitig der E-Mail Header ist.
Der Envelope wird automatisch erstellt. Manchmal wird er 1:1 aus dem Header erstellt. Das kann der Fall sein, wenn es einen Absender gibt und genau einen Empfänger.
Das es allerdings nicht immer so ist, sieht man z.B. an Spam E-Mails und solchen, die ein Bcc- oder Cc-Feld enthalten.
Sehen Sie sich folgende E-Mail an:

From: test@example.com To: test@freshmail.de Bcc: nocheintest@irgendeineanderedomain.org Subject: Hi! Hier steht der Text.

Bei keinem der beidem Empfänger erscheint das Bcc-Feld. Der Client oder Server generieren vielmehr zwei neue E-Mails:

From: test@example.com To: test@freshmail.de Subject: Hi! Hier steht der Text.

und

From: test@example.com To: nocheintest@irgendeineanderedomain.org Subject: Hi! Hier steht der Text.

Wenn Client oder Server mit dem Zielserver sprechen, nutzen sie das Kommando MAIL für den Envelope Absender und RCPT für den Envelope Empfänger.

SMTP Status- und Fehlercodes

Die meisten Statusmeldungen kommen zusätzlich mit einer Meldung vom Mailsystem, die aussagt, was genau nun passiert ist.
So eine Liste kann nie schaden, vor allem weil man manche Fehler eher selten zu sehen bekommt. Weitere Infos dazu in RFC2821 für SMTP und RFC1893 und RFC2034 für ESMTP.

Bestätigungen

• 211 System Status, Hilfesystem
• 214 Hilfesystem
• 220 Bereit
• 221 Dienst schließt Übertragungskanal
• 250 Angeforderte Mail Aktion ok. Aktion abgeschlossen
• 251 Mailbox nicht lokal, E-Mail wird weitergeleitet

Aufforderungen

• 354 Maileingabe. Beenden mit [CRLF].[CRLF]

Temporäre Fehler

• 421 Dienst nicht bereit, schließe Übertragungskanal
• 450 Angeforderte Mail Aktion nicht ausgeführt: Mailbox nicht erreichbar
• 451 Angeforderte Aktion abgebrochen: Lokaler Verarbeitungsfehler
• 452 Angeforderte Aktion nicht ausgeführt: Speicherfehler (zu wenig)

Fatale Fehler

• 500 Syntax Fehler, Befehl unbekannt (Auch bei überlangen Kommandos)
• 501 Syntax Fehler. Parameter und/oder Argumente
• 502 Befehl nicht implementiert
• 503 Unbrauchbare Befehlsabfolge
• 504 Befehlsparameter nicht implementiert
• 550 Angeforderte Aktion nicht ausgeführt
• 551 Benutzer nicht lokal. Weiterleitung wird versucht
• 552 Angeforderte Aktion. Speicherfehler
• 553 Angeforderte Aktion nicht ausgeführt: Mailbox nicht erlaubt
• 554 Übertragung nicht erfolgreich

Die wichtigsten E-Mail-relevanten RFCs

SMTP

RFC 2821 Simple Mail Transfer Protocol (SMTP)

RFC 1123 Requirements for Internet hosts - application and support

RFC 974 Mail routing and the domain system (MX records)

RFC 1869 SMTP Service Extensions

RFC 1870 SMTP Service Extension for Message Size Declaration

RFC 1652 SMTP Service Extension for 8bit-MIMEtransport

RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages

RFC 1845 SMTP Service Extension for Checkpoint/Restart

RFC 1846 SMTP 521 Reply Code

RFC 2920 SMTP Service Extension for Command Pipelining

RFC 1985 SMTP Service Extension for Remote Message Queue Starting (ETRN)

RFC 2645 On-Demand Mail Relay (ODMR) SMTP with Dynamic IP Addresses

RFC 2852 Deliver By SMTP Service Extension

RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes

RFC 3464 An Extensible Message Format for Delivery Status Notifications (DSNs)

RFC 3463 Enhanced Mail System Status Codes

RFC 3461 SMTP Service Extension for Delivery Status Notifications

RFC 3462 Multipart/Report Content Type for the Reporting of Mail System Administrative Messages

RFC 3656 Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol

RFC 3848 ESMTP and LMTP Transmission Types Registration

RFC 3865 No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension

RFC 3885 SMTP Service Extension for Message Tracking

RFC 3886 An Extensible Message Format for Message Tracking Responses

RFC 3887 Message Tracking Query Protocol

RFC 3888 Message Tracking Model and Requirements

RFC 3974 SMTP Operational Experience in Mixed IPv4/v6 Environments

RFC 4409 Message Submission for Mail

RFC 4468 Message Submission BURL Extension

RFC 4954 SMTP Service Extension for Authentication

RFC 4405 SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message

RFC 4865 SMTP Submission Service Extension for Future Message Release

RFC 4407 Purported Responsible Address in E-Mail Messages

RFC 5248 A Registry for SMTP Enhanced Mail System Status Codes

RFC 2442 Batch SMTP Media Type

RFC 1047 Duplicate messages and SMTP

RFC 1090 SMTP on X.25

Bezüglich Spam und Authentizität

RFC 2505 Anti-Spam Recommendations for SMTP MTAs

RFC 4871 DomainKeys Identified Mail (DKIM) Signatures

RFC 4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS

RFC 4406 Sender ID: Authenticating E-Mail

RFC 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1