Simple Mail Transfer Protocol - Technische Fakultät · Protokoll X.400, welches einige größere Firmen (CCITT) 1984 entwickelten, durchsetzen, da sich das genannte Protokoll mit

Handout_Internetprotokolle WS 02/03 1 Birgit Severin & Achim Schmitz

Simple Mail Transfer Protocol (SMTP) Birgit Severin

Achim Schmitz


Simple Mail Transfer Protocol (SMTP) Birgit Severin

Achim Schmitz

Gliederung 1 Simple Mail Transfer Protocol 1.1 Einleitung 1.2 E-Mail-Systeme 1.3 Entwicklung 1.4 Die E-Mail-Adresse 1.5 Simple Mail Transfer Protocol

1.5.1 Nachrichtenformat (RFC822) 1.5.2 Das Protokoll (RFC 821) 1.5.3 SMTP-Befehle 1.5.4 Reply codes 1.5.5 Relay 1.5.6 MX-Records

1.6 Weiterentwicklung 1.6.1 ESMTP-SMTP Service Extensions 1.6.2 MIME


1.1 Einleitung Das Simple Mail Transfer Protocol (SMTP) ist das verbreiteste und meistgenutzte Protokoll für den Versand von electronic mail („E-Mail“) im Internet. Mit dieser Ausarbeitung möchten wir zunächst einen allgemeinen Überblick über die Funktionsweise eines E-Mail-Systems geben und darauf folgend konkreter bzw. detaillierter auf SMTP eingehen. Dies beinhaltet einen kurzen Rückblick auf die Entstehung von SMTP, das primär auf die RFCs 821 und 822 basiert, die an Hand von einigen Beispielen vorgestellt werden sollen. 1.2 E-Mail-Systeme E-Mail-Systeme bestehen aus zwei Subsystemen:

a) Benutzeragenten (User Agents, UA) b) Nachrichtentransferagenten (Message Tranfer Agents, MTA)

Bei den Benutzeragenten handelt es sich normalerweise um lokale Programme, die dem Benutzer das Empfangen, Bearbeiten und Versenden von Nachrichten ermöglichen, während die Nachrichtentransferagenten in der Regel als Systemdienste im Hintergrund fungieren und für den korrekten Transport der Nachricht zum Empfänger zuständig sind. Ein E-Mail-System weist folgende Grundfunktionen auf:

��Composition steht für das Erstellen einer Nachricht, was je nach System mit einem simplen Texteditor (z.B. wordpad), auf der Kommandozeile oder innerhalb einer graphischen Oberfläche durchgeführt werden kann.

��Tranfer steht für den Transport einer Nachricht vom Absender zum Empfänger. Da

dies automatisch geschieht (auch ohne Einflussnahme durch den Absender !), muss das E-Mail-System Szenarien für Sonderfälle, wie z.B. bei einem „ Datenstau“ auf dem „Datenhighway“, beherrschen, damit keine Informationen verloren gehen. Die E-Mail könnte schließlich einen alternativen Weg („Viele Wege führen nach Rom“) nehmen bzw. in eine Warteschleife gesetzt werden bis eine korrekte Übertragung ermöglicht werden kann.

��Reporting hat die Aufgabe, den Absender über den Status seiner gesendeten Nachricht

zu informieren. Er könnte so z.B. vom E-Mail-System darüber informiert werden, ob seine Nachricht überhaupt sein Ziel erreicht hat (Eingangsbestätigung) bzw. bereits gelesen wurde (Lesebestätigung), oder ob sie aus irgendwelchen Gründen nicht gesendet werden konnte.

��Displaying zeigt dem Benutzer eingegangene Nachrichten an und ruft gegebenenfalls

externe Programme auf, die zur Darstellung des Nachrichteninhalts benötigt werden (z.B. Acrobat Reader für pdf-files).

��Disposition bestimmt, was mit der eingegangenen Nachricht geschieht. Der Benutzer

hat hier somit die Möglichkeit, die Nachricht zu speichern, zu löschen oder auf eine andere Art und Weise weiterzuverarbeiten.


Die fünf zuvor erwähnten Funktionen stellen das Grundgerüst eines E-Mail-Systems dar. Neben diesen Grundfunktionen gibt es natürlich bei verschiedenen Systemen eine große Anzahl weiterer Funktionen, um E-Mail vielseitiger bzw. auch flexibler verwendbar zu machen. Diese sind heutzutage oft mit dem Ziel der maximalen Benutzerfreundlichkeit in „bunte Oberflächen“ (z.B. Outlook Express) eingebunden, so dass der User seine E-Mail simpel verwalten kann, ohne sich mit den „Grundfunktionen“ weiter auseinandersetzen zu müssen. Abbildung 1.1 enthält eine graphische Darstellung der grundlegenden Funktionsweisen eines E-Mail-Systems. Der User Agent stellt dem Benutzer über das „user interface“ die Funktionen des Systems zur Verfügung, damit dieser z.B. Nachrichten empfangen, lesen und verschicken kann. Ausgehende Nachrichten werden zunächst zwischengespeichert, bis sie erfolgreich an den Nachrichtentransferagenten (nachfolgend nur noch MTA genannt) bzw. „client“ übertragen worden sind. Der „client“ überträgt die Nachricht an den Server, wo sie in der Mailbox des Empfängers gespeichert wird.

Abbildung 1.1: Funktionsweise eines E-Mail-Systems 1.3 Entwicklung Mit der Einführung des Internets gab es die Möglichkeit, mit anderen Usern zu kommunizieren, ohne telefonieren oder körperlich anwesend sein zu müssen. Die Kommunikationsform der E-Mail kam der Industrie gerade recht. Gegenüber einem herkömmlichen Brief bietet sie zahlreiche Vorteile wie z.B. Schnelligkeit, relative Sicherheit bzw. Zuverlässigkeit und globale Erreichbarkeit, die unabhängig von der momentanen Anwesendheit des Users ist. Bei all diesen Vorteilen sollte jedoch ein entscheidener Nachteil zu dieser Zeit nicht verschwiegen werden: Zu Anfang existierten keine Standards, die den E-Mail-Verkehr regelten.


1982 entwickelten auf Grund dessen eine Gruppe von Studenten das in RFC 821 beschriebene Simple Mail Transfer Protocol, welches einen Standard für den Austausch zweier Nachrichten zwischen verschiedenen Rechnersystemen festlegt. Das dazugehörige Nachrichtenformat wurde in RFC 822 beschrieben. SMTP ist in seiner Funktionsweise sehr simpel angelegt und konnte sich gegenüber dem Protokoll X.400, welches einige größere Firmen (CCITT) 1984 entwickelten, durchsetzen, da sich das genannte Protokoll mit seinem Umfang und seiner Komplexität kaum zufrieden-stellend implementieren ließ und sich somit als benutzerunfreundlich erwies. 1.4 Die E-Mail-Adresse Bevor wir nun konkret auf das Nachrichtenformat (RFC 822) und das Protokoll (RFC 821) eingehen, möchten wir zunächst noch den Aufbau einer E-Mail-Adresse behandeln. Sicherlich hat sich die E-Mail-Adresse heutzutage zu einem standardisierten und allgemein bekannten Adresszusatz etabliert. Dennoch gibt es immer noch Missverständnisse, die wir mit der folgenden Erklärung aus der Welt räumen möchten.

E-Mail-Adressen aus dem Internet erkennt man sofort am markanten Symbol des Klammeraffens (im Englischen als At-Symbol bezeichnet, gespr.: Ätt), der unvermeidlich ist, um den lokalen Teil einer E-Mail-Adresse vom Domain-Namen zu trennen. Der Domain-Name entstammt dem Domain-Name-System des Internets. Es dient dazu, den im Internet angeschlossenen Rechnern Namen zu verleihen, damit man nicht immer die vierstelligen IP-Adressen eintippen muss. Im Rahmen des E-Mail-Systems wird der Domain-Name vordergründig genutzt, um die Zugehörigkeit eines Adressaten zu einer größeren Gruppe auszudrücken. Der angegebene Domain-Name dient vor allem dazu, einen passenden Mail-Server ausfindig zu machen, dem eine Nachricht zugeleitet werden kann. Vor dem Klammeraffen steht der eigentliche Adressat, der unter dem hier angegebenen Namen in der jeweiligen Domain bekannt sein muss, damit die Nachricht zugestellt werden kann. Die Postadresse sozusagen. Weil das Internet auch als Brücke zu anderen Mail-Systemen dienen soll, beispielsweise zu denen von AOL, MSN und anderen, wurde für die Kodierung dieser Empfängerkennung kein bestimmtes Format vorgegeben. Es kann ein Name, eine Ziffernfolge oder eine scheinbar sinnlose Buchstaben– und Zeichenkombination angegeben werden, solange der Mail-Server der angegebenen Domain als priorisierter Empfänger der Nachricht dieses Format und diese Information versteht und die Nachricht dadurch dem richtigen Postfach zustellen kann.

[email protected]

„Lokaler Teil“

„At-Symbol“

Domain-Name


1.5 Simple Mail Transfer Protocol 1.5.1 Nachrichtenformat (RFC 822) Das RFC 822 legt fest, dass eine E-Mail aus zwei Teilen bestehen muss, um die angestrebte Automatisierung zu erreichen, nämlich aus den Header-Feldern und dem Body. Typische Header –Felder sind „Date“ für das Absendedatum, „From“ für die Absenderadresse, „Subject“ als moderne Betreffzeile und nicht zu vergessen „To“ als Empfängeradresse. Die Automatisierung wird ermöglicht, da der MTA aus diesen und anderen noch vorhandenen Informationen eine Verpackung, Envelope (mit einem Umschlag eines Briefes vergleichbar, definiert in RFC 821), erstellt und so alle wichtigen Informationen den MTAs auf dem Weg zum Ziel zu präsentieren. Weiterhin schreiben die einzelnen MTAs, die die Mail weiterleiten, ihre Daten als jeweils neuen Header auf den „Envelope“ bzw. hängen die Informationen an die ursprüngliche Mail an, ohne deren Inhalt zu verändern. Im Envelope ist der eigentliche Inhalt der E-Mail, der sogenannte Body, verpackt. RFC 822 legt zudem fest, dass die E-Mail nur NVT-ASCII-Zeichen enthalten darf. Dieser Punkt stellt heutzutage eine Einschränkung dar, auf die wir noch später eingehen werden.

Umschläge und Nachrichten: (a) Postsystem, (b) E-Mail-System // NVT_ASCII Zeichensatz

Abbildung 1.2: Vergleich des Aufbaus von Brief und E-Mail

In der Abbildung „Vergleich des Aufbaus von Brief und E-Mail“ kann man die überraschend zahlreichen Gemeinsamkeiten einer E-Mail mit einem Brief erkennen.

Umschlag

Nachricht


1.5.2 Das Protokoll (RFC 821) Das Protokoll RFC 821 definiert einen Standard für den Austausch von E-Mails zwischen zwei MTA’s. Auf Grund zahlreicher Weiterentwicklungen stellt SMTP auch heute trotz seines Alters noch einen Standard dar. Im folgenden Abschnitt soll zunächst das Funktionsprinzip der ursprünglichen Version erklärt werden. Der Versand einer E-Mail erfolgt in der Regel transparent für den Benutzer, d.h. dieser arbeitet mit einem User Agent zum Empfangen, Lesen und Versenden von E-Mail. Der eigentliche Transport findet automatisch ohne Einfluss des Benutzers statt.

Abbildung 1.3: E-Mail mit SMTP Das Schaubild 1.3 „E-Mail mit SMTP“ zeigt eine schematische Darstellung des Nachrichtentransportes. Die Nachricht wird mit einem User Agent erstellt und an einen MTA übertragen. Dieser hat im folgenden die Aufgabe, die Nachricht über das Internet an den MTA des Empfängers weiterzuleiten, das abhängig von den beteiligten Systemen auf mehr oder minder direktem Weg geschehen kann. Dieses Verfahren ist textbasiert, d.h. die Kommunikation zwischen zwei MTAs ist für uns Menschen direkt „lesbar“ und nachvollziehbar. Es wird wie bereits in der eigentlichen Nachricht NVT-ASCII verwendet. Zunächst baut der MTA des Absenders (nachfolgend „Client“ genannt) eine TCP-Verbindung zu Port 25 des Empfänger-MTAs (Server) auf. Der Client kann dann Befehle an den Server senden, worauf dieser jeweils mit einem dreistelligen „Reply code“ und einem optionalen Textstring antwortet. Im Gegensatz zu anderen Internet-Protokollen (z.B. FTP) ist die Menge der Befehle bei SMTP eher gering.


1.5.3 SMTP-Befehle RFC 821 fordert für eine gültige Implementation des Protokolls nur acht Befehle (minimaler Befehlssatz), von denen nur fünf für den E-Mail-Versand essentiell sind (siehe blaue Formatierung !).

��HELLO <Hostname> - eine Art Begrüßung („Hello“), in welcher der Client dem Server seine Identität in Form des FQDN (fully qualified domain name) mitteilt

��MAIL FROM: <Adresse> - Einleitung der Übertragung einer Nachricht, enthält die

Adresse des Absenders als Parameter

��RCPT TO: <Adresse> - Festlegung der Empfänger-Adresse(n)

��DATA – Einleitung der Übertragung des eigentlichen Nachrichteninhaltes

��QUIT – Beendet die Verbindung

��RSET – Zurücksetzung der Verbindung; bereits eingegebene Daten werden verworfen (Reset)

��VRFY <Adresse> - Überprüft, ob eine bestimmte Adresse dem Server als gültiger

Empfänger bekannt ist (Verify)

��NOOP – Löst nur eine kurze Antwort des Servers aus; keine weitere Wirkung (No Operation)

U.a. folgende Befehle sind optional und daher nicht essentiell in jeder SMTP-Implementation vorhanden:

��EXPN <Adresse> - Auflösung einer Mailing-Liste ��HELP <Befehl> - Ruft Informationen zu dem als Parameter angegebenen Befehl auf

��TURN – Vertauschung der Client-Server-Rollen: Ermöglicht den Versand von

Nachrichten in die andere Richtung ohne erneuten Verbindungsaufbau


1.5.4 Reply codes Wie bereits erwähnt, reagiert der Server mit einem sogenannten Reply code, einer dreistelligen Zahl und einem für den Menschen lesbaren Textstring (optional). Die Reply codes sind in verschiedene Kategorien und Unterkategorien eingeteilt. Übersetzungstabelle für Reply codes

Als Beispiel sei hier der Code „220“ gezeigt: 1. Zahl (2): signalisiert client Befehl fehlerlos ausgeführt 2. Zahl (2): signalisiert client Verbindung ist hergestellt 3. Zahl (0): signalisiert client alles „OK“, weitere Befehle möglich Einige Beispiele für Reply codes mit dem jeweils zugehörigen Textstring: 220 „domain“ Service ready 450 Requested mail action not taken: mailbox unavailable 553 Requested action not taken: mailbox name not allowed 554 Transaction failed

1yz Positiver Beginn eines Befehls. Weitere Eingabe erforderlich2yz Positive Beendigung eines Befehls. Weitere Befehle möglich3yz Positiver Zwischenzustand. Weitere Eingaben müssen folgen4yz Transientes Problem. Befehl nicht ausgeführt. Eingabe wiederholen5yz Definitives Problem. Befehl nicht wiederholenx0z Syntax eines Befehlsx1z Allgemeine Informationx2z Verbindungszustandx3z Nicht spezifiziertx4z Nicht spezifiziertx5z Statusmeldungxyz z = Weitere Unterteilung / Nummerierung der Meldung


Ein einfaches Beispiel eines Mail-Versands mit dem SMTP-Protokoll. Bemerkung: Die den Zeilen vorangestellten Kürzel für Server bzw. Client und die zusätzlichen Leerzeichen zwischen den einzelnen Befehlen wurden nur zum besseren Verständnis hinzugefügt. (S: Server, C: Client) S: 220 Beta.GOV Simple Mail Transfer Service Ready C: Helo Alpha.EDU S: 220 Beta.GOV C: Mail From:<[email protected]> S: 250 OK C: RCPT TO:<[email protected]> S: 250 OK C: RCPT TO:<[email protected]> S: 550 No such user here C: RCPT TO:<[email protected]> S: 250 OK C: DATA S: 354 Start mail input; end with <CR><LF>.<CR><LF> C: ...sends body of mail message... C: ...continues for as many lines as message contains... C: <CR><LF>.<CR><LF> S: 250 OK C: QUIT S: 221 Beta.GOV Service closing transmission channel Erklärung: In diesem Beispiel sendet der Benutzer Smith vom Host Alpha.EDU eine Mail an die drei Empfänger Jones, Green und Brown am Host Beta.GOV. Dazu baut der SMTP-Client von ALPHA.EDU zunächst eine TCP-Verbindung zu Port 25 von Beta.GOV auf. Der Server liefert zunächst eine Statusmeldung, in der er sich identifiziert und seine Bereitschaft zur Annahme von E-Mails bestätigt. Der Client identifiziert sich ebenfalls.


Der Client leitet nun mit dem Mail-Befehl die Übergabe der Nachricht ein, übermittelt Sender und Empfänger sowie den eigentlichen Nachrichteninhalt und beendet schließlich die Verbindung. Bei der Angabe des Empfängers [email protected] reagiert der Server mit einer Fehlermeldung, erkennbar an dem Reply code 550 und der Meldung „No such user here“: Dem System ist kein Benutzer bekannt, dementsprechend wird die Annahme verweigert. Das Protokoll legt nicht fest, wie der Client auf solche Fehlermeldungen zu reagieren hat. Die sinnvollste und auch übliche Methode ist es aber, wie hier im Beispiel, den Vorgang nicht vollständig abzubrechen, sondern mit den anderen gültigen Empfängern fortzufahren. Nun folgt ein “echtes”, unverändertes Beispiel für eine SMTP-Session.

Zunächst habe ich, aschmitz, mit Hilfe des Programms „putty“ über SSH eine Verbindung zum Universitäts-Server hergestellt. SSH bedeutet „Secure Shell“. Das Programm putty setzt moderne Verschlüsselungs- und Authentisierungsverfahren für den Remotezugriff auf einen Rechner ein, d.h., es wird eine sichere Verbindung via Termialprogramm , z.B. eine Rechner-zu-Rechner-Verbindung via Telefonleitung, generiert. Schließlich wird wieder eine Verbindung zum Port 25 vom SMTP-Server hergestellt (Name des Servers: „momotombo“). Dieser meldet sich mit dem Reply code 220 und identifiziert sich im dazugehörigen Textstring. Es folgt die „Begrüßung“ bzw. Identifizierung des Clients (hier: „popocatepetl“), woraufhin der Server erneut mit einer Statusmeldung antwortet. In diesem Fall habe ich, aschmitz, eine E-Mail an den user dsieger geschickt und anschließend die Verbindung beendet.


1.5.5 Relay Unter Relay bzw. Relaying versteht man die Zwischenspeicherung von E-Mails auf einem Server, der nicht selbst der Empfänger-MTA ist, sondern die Nachricht an diesen weiterleitet.

Abbildung 1.4: Schema eines Relay-Systems

one organization

one organization


Dieses Konzept bietet einige Vorteile:

��Erhöhte Ausfallsicherheit ��Besserer Netzwerkaufbau (in Bezug auf Sicherheitsaspekten)

Ursprünglich galt im Internet ein gewisses „Jeder hilft jedem“-Prinzip, d.h. MTAs nahmen in der Regel auch E-Mails von ihnen unbekannten Absendern an ihnen unbekannte Empfänger an. Mit zunehmenden User-Zahlen des Internets entstanden aber immer öfters Probleme, wenn diese Prozedur z.B. zum massenhaften Vesand von „Spam“ mißbraucht wurde. Um diesen Mißbrauch zu verhindern, ist heute das Relay normalerweise stark eingeschränkt. Viele Relay-Systeme nehmen nur E-Mails an, wenn der Empfänger ein lokaler, bekannter User ist. Oft wird auch der Mailversand auf bestimmte IP-Adressräume eingeschränkt und die Adressen bekannter „Spammer“ gesperrt. 1.5.6 MX-Records Bislang sind wir davon ausgegangen, dass der Empfänger-MTA direkt mit dem Internet verbunden ist und sein Domainname mit dem Domainteil der E-Mail-Adressen übereinstimmt. Der MX-Record (Mail Exchange Record) ist ein spezieller DNS-Eintrag, der die Konfiguration von E-Mail-Systemen vereinfacht, indem dem Domainteil einer E-Mail-Adresse ein bestimmter Mail-Server zugewiesen wird. Dies ermöglicht den Versand von Nachrichten an Systeme ohne direkte Internet- Anbindung, oder auch die Festlegung von alternativen Servern für den Fall, dass der reguläre Empfangs-MTA nicht zur Verfügung steht. Beispiel: Abfrage des MX-Record von techfak.uni-bielefeld.de


Von besonderer Bedeutung sind hier die zwei Zeilen mit den „MX preferences“-Einträgen: Hier wird bestimmt, welche Rechner für die Entgegennahme von E-Mails an Adressaten innerhalb der Domain techfak.uni-bielefeld.de zuständig sind. Die Einträge weisen zwei Werte auf:

a) Mail Exchanger gibt den zu verwendenen Rechner an. b) Preference ist eine Prioritätsangabe.

Sendene MTAs versuchen zunächst immer die Nachrichten dem MTA mit dem niedrigsten Wert zu übergeben; erst wenn dieser nicht erreichbar ist, wird der Rechner mit dem nächsthöheren Wert benutzt. 1.6 Weiterentwicklung 1.6.1 ESMTP – SMTP Service Extensions Das Protokoll wurde bereits 1982 veröffentlicht und seitdem ständig weiterentwickelt. Die Erweiterungen werden als „SMTP Service Extensions“ bezeichnet. Man spricht auch von ESMTP (Extended SMTP). Die entsprechenden Erweiterungen werden wie das ursprüngliche Protokoll selbst in RFCs beschrieben und bei der IANA (Internet Assigned Numbers Authority) registriert. Eine Besonderheit besteht darin, dass alle Erweiterungen abwärtskompatibel sind und somit alle bestehenden Implementationen nicht beeinflusst werden. In der Praxis verhält sich ESMTP daher analog zu SMTP. Es werden jedoch weitere Funktionen unterstützt. Wie im nachfolgenden Beispiel gezeigt, macht der Server die Unterstützung von ESMTP zu Anfang der Session bekannt. Der Client begrüßt den Server nun mit einem „EHLO“ (für „Extended Hello“), woraufhin dieser eine mehrzeilige Antwort zur Bekanntmachung der verfügbaren Funktionen liefert. 220 momotombo.Techfak.Uni-Bielefeld.DE ESMTP Sendmail 8.9.1/8.9.1/ Techfak/pk+ro20010702; Wed, 5 Feb 2003 12:46:43 +0100 (MET) EHLO localhost 250-momotombo.Techfak.Uni-Bielefeld.DE Hello pd9E04337.dip.t-dialin.net [217.224.67.55] , pleased to meet you 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 8388608 250-DSN 250-ONEX 250-ETRN 250-XUSR 250-HELP


Die einzelnen Zeilen beginnen mit dem Reply code 250, darauf folgt ein Keyword (mit optionalem Parameter) zur Beschreibung der Funktion. EXPN steht so z.B. für die Unterstützung des Expand-Befehls zur Auflösung von Mailing-Listen und SIZE 8388608 gibt die maximal erlaubte Größe anzunehmender E-Mails an (hier ist die Dateigröße in Byte der Parameter). Neben dem Protokoll wurde aber auch das Nachrichtenformat weiterentwickelt, da es in seiner ursprünglichen Form, wie in RFC 822 beschrieben, einige Einschränkungen enthält:

��Es werden nur Textnachrichten unterstützt. ��Es ist nur ein Zeichensatz definiert (7-Bit US-ASCII). ��Die Zeilen sind auf maximal 1000 Zeichen beschränkt.

1.6.2 MIME Die fundamentalen Ziele der Weiterentwicklung des Nachrichtenformats bestanden aus folgenden Punkten:

��Unterstützung anderer Zeichensätze (Nachricht & Header-Felder) ��Andere Formate für den Body der Nachricht (z.B. Audio- und Videodateien)

bzw. mehrere Formate innerhalb einer E-Mail

Diese Eigenschaften wurden durch den MIME-Standard (Multipurpose Internet Mail Extensions, RFCs 2045-2049) realisiert. Die Funktionsweise möchten wir im folgenden nur kurz „anreißen“: Es werden allgemein zusätzliche Header-Felder für die Speicherung der benötigten MIME-Informationen benutzt, während die entsprechenden Inhalte in eine ASCII-Darstellung umgerechnet werden. Diese können schließlich vom Empfänger wieder in die ursprüngliche Form tranferiert werden. Der Umweg über die ASCII-Darstellung vergrößert zwar etwas den Umfang der Nachricht, dafür wird aber die Kompatibilität mit älteren Implementationen des Protokolls gewahrt. Zudem müssen nur die Benutzeragenten an die Veränderungen angepasst werden. Hiermit sind wir auch am Ende unseres „Handouts“ angelangt und hoffen, dass wir mit unserer Ausarbeitung etwas „Licht in den dunklen SMTP-Tunnel“ bringen konnten. Kontakt: [email protected] [email protected] Mit freundlichen Grüßen


Birgit Severin Achim Schmitz

Documents

Simple Mail Transfer Protocol - Technische Fakultät · Protokoll X.400, welches einige größere Firmen (CCITT) 1984 entwickelten, durchsetzen, da sich das genannte Protokoll mit