Anwendungsprotokolle

Im Internet gibt es Computer, die Dienste anbieten, genannt Server und Computer, die diese Dienste in Anspruch nehmen, genannt Clients. Beispielsweise bieten die Server von YouTube den Dienst an, auf dort gespeicherte Videos zuzugreifen oder selbst welche hochzuladen. Einige Netzwerkdienste und die von ihnen verwendeten Anwendungsprotokolle wollen wir hier näher betrachten.

World Wide Web

Das World Wide Web (WWW) ist der Teil des Internets, mit dem wohl die meisten vertraut sind und dem wir bereits im Kapitel Informationsdarstellung im Internet begegnet sind: Es besteht aus Websites aus der ganzen Welt, die durch Hyperlinks untereinander verknüpft sind. Websites werden auf weltweit verteilten Webservern vorrätig gehalten (“gehostet”) und können mit Webbrowsern wie Apple Safari, Google Chrome, Microsoft Edge oder Mozilla Firefox abgerufen werden. Übertragen werden sie mit dem Hypertext Transfer Protocol (HTTP).

HTTP

Ein Client und ein Server, die über HTTP miteinander kommunizieren, tauschen Nachrichten aus, die Anfrage (engl. request, vom Client an den Server) und Antwort (engl. response, vom Server an den Client) genannt werden. Dabei behandelt der Server jede Anfrage völlig isoliert, so als hätte der Client noch nie zuvor eine geschickt und würde nie wieder eine schicken. Protokolle, die sich so verhalten, nennt man zustandslos.

Um trotzdem eine Art von Zustand zu simulieren, werden so genannte Cookies verwendet. Cookies sind kleine Textschnipsel, die mit jeder Anfrage und Antwort ausgetauscht und auf dem Client (z. B. im Datenspeicher des Webbrowsers) zwischengespeichert werden. Mittels Cookies kann der Server beispielsweise verschiedene IDs an Clients vergeben, sie so unterscheiden und serverseitig individuelle Informationen für die Clients speichern. Ein Analogon ist etwa eine Auftragsnummer, die man bei der Bestellung erhält, bei der Bezahlung angeben und bei jeder Reklamation bereithalten muss – wobei man sich natürlich auch jedes Mal mit Namen und Adresse identifizieren kann, was den Vorgang aber unnötig verkompliziert.

Anfragen

In HTTP kann der Client u. a. folgende Anfragen stellen

Anfrage	Erläuterung
`GET`	Dient dazu, eine Ressource vom Server abzufragen. Mit `GET` können auch Parameter an den Server übertragen werden, die dann in der URL sichtbar werden. `GET`-Anfragen sollten nicht dazu genutzt werden, Daten zur Speicherung oder Weiterverarbeitung an den Server zu übertragen
`POST`	Dient dazu, Daten zur weiteren Verarbeitung an den Server zu senden. Diese Daten werden nicht in der URL sichtbar, weswegen diese Methode z.B. zum Versand von Login-Daten bevorzugt verwendet werden sollte. `POST`-Anfragen sollten auch genutzt werden, um Ressourcen auf dem Server zu ändern.
`HEAD`	Dient ebenfalls zum Datenabruf, allerdings wird nicht der Inhalt einer Web-Ressource, sondern nur Metadaten, die sog. Header abgerufen. Damit kann z.B. geprüft werden, ob eine im Cache zwischengespeicherte Seite noch gültig ist.
`PUT`	Dient dazu, eine Ressource auf den Server hochzuladen, wobei die übergebenen Anfragedaten unter der angegebenen URL gespeichert werden. Anders als `POST` sollen `PUT`-Anfragen einfach nur Dateien ablegen, statt ggf. komplexere Änderungen anzustoßen.
`PATCH`	Dient dazu, ein bestehendes Dokument zu ändern, ohne es wie bei einer `PUT`-Anfrage vollständig zu ersetzen.
`DELETE`	Dient dazu, eine Ressource auf dem Server zu löschen

Die meisten Anfragen sind GET- und POST-Anfragen. Eine Analyse von 2017 ergab, dass rund 77% der HTTP-Anfragen GET- und weitere 20% POST-Anfragen sind. Oft wird POST pauschal für alle Anfragen verwendet, die Daten auf dem Server ändern (also Daten hinzufügen, verändern oder löschen), während GET für rein lesende Anfragen verwendet wird.

Antworten

Jede Antwort eines Webservers beginnt mit einem dreistelligen Statuscode. Die erste Ziffer des Codes gibt dabei Aufschluss über die Art der Antwort:

Erste Ziffer	Art der Antwort
1__	Die Anfrage wird bearbeitet, dies wird aber noch einige Zeit dauern
2__	Die Anfrage wurde erfolgreich bearbeitet.
3__	Umleitung – die gewünschte Ressource liegt an einem anderen Ort.
4__	Die Anfrage ist fehlgeschlagen und es liegt (wahrscheinlich) am Client
5__	Die Anfrage ist fehlgeschlagen und es liegt (wahrscheinlich) am Server

Die häufigsten Statuscodes sind

Statuscode	Name	Erläuterung
100	Continue	Signalisiert dem Client, dass eine sehr lange Anfrage noch nicht abgewiesen wurde und der Client mit der Anfrage fortfahren darf.
102	Processing	Signalisiert dem Client, dass die Anfrage akzeptiert worden ist, aber die Bearbeitung bis zur Antwort noch einige Zeit benötigen wird. Dieser Statuscode wird verwendet, um Timeouts zu vermeiden.
200	OK	Die Anfrage war erfolgreich und das Ergebnis wird in der Antwort übertragen.
204	No Content	Die Anfrage war erfolgreich, die Antwort enthält aber bewusst keine Daten.
301/308	Moved Permanently/Permanent Redirect	Die angefragte Ressource ist dauerhaft an eine neue URL verschoben worden; der Client möge eine neue Anfrage stellen. Link-Shortener-Dienste wie bit.ly oder tinyurl.com reagieren auf Anfragen häufig mit einer `301`-Antwort.
302/303/307	Found/See Other/Temporary Redirect	Die angefragte Ressource ist temporär an eine neue URL verschoben worden.
400	Bad Request	Die Anfrage war fehlerhaft aufgebaut
401	Unauthorized	Der Client muss sich für diese Anfrage erst autorisieren.
403	Forbidden	Der Client hat keine Berechtigung, diese Ressource anzufragen
404	Not Found	Die angeforderte Ressource konnte nicht gefunden werden, etwa weil in der Adresse ein Tippfehler vorliegt oder ein Link auf eine inzwischen gelöschte Ressource verweist.
408	Request Timeout	Innerhalb des gegebenen Zeitfensters wurde vom Server keine vollständige Anfrage empfangen.
418	I’m A Teapot¹	Der Server ist eine Teekanne.
451²	Unavailable For Legal Reasons	Die gesuchte Ressource ist aus rechtlichen Gründen (z.B. Internetzensur) für den Client nicht verfügbar.
500	Internal Server Error	Dieser Statuscode wird allgemein bei Serverfehlern zurückgegeben.
502	Bad Gateway	Der Server hat zur Bearbeitung der Anfrage eine weitere Ressource angefragt, aber keine gültige Antwort erhalten.
503	Service Unavailable	Der Dienst steht nicht zur Verfügung, z.B. weil der Server überlastet ist.

Im Webbrowser kann man Anfragen und Antworten sichtbar machen, indem man die Entwicklerwerkzeuge öffnet (was in den meisten Browsern mit der Tastenkombination Umschalt+Strg+I bzw. Command+Option+I möglich ist) und den Reiter “Netzwerk” oder “Netzwerkanalyse” auswählt.

Das Entwicklerwerkzeug “Netzwerkanalyse” in Mozilla Firefox 106

Sobald man dann eine HTTP-Anfrage absendet, etwa indem man eine URL in die Adresszeile eingibt oder einen Link anklickt, werden diese und alle folgenden Anfragen mit den Antworten im Datenfenster aufgelistet.

Das Entwicklerwerkzeug “Netzwerkanalyse” zeigt einen Seitenaufruf auf inf-schule.de

Zu jeder Anfrage können in der Übersicht der Anfragetyp, der Statuscode, Zielrechner, abgefragte Ressource u.v.m. abgelesen werden

Zoom auf einen Ausschnitt der Liste der Anfragen und Antworten

Mit einem Klick auf eine Anfrage können noch mehr Details dazu betrachtet werden, z.B. die gesendeten Header von Anfrage und Antwort oder die übertragenen Cookies.

Details zu einer Anfrage zum oben abgebildeten Seitenaufruf

DNS

Das Domain Name System (DNS) sorgt dafür, dass Anfragen, die an Domainnamen wie uni-kiel.de oder iqsh.oncampus.de gerichtet sind, auch beim richtigen Rechner ankommen, z. B. verbirgt sich hinter dem Domainnamen uni-kiel.de der Webserver mit der IP-Adresse 134.245.13.22. Diesen Prozess bezeichnet man als Namensauflösung. Die dafür notwendigen Daten, die Resource Records sind weltweit auf vielen sogenannten Nameservern verteilt gespeichert.

Domain-Namen

Die Domainnamen sind rückwärts zu lesen und die dazugehörigen Informationen sind in einer Baumstruktur organisiert:

flowchart TD root --- de & com & org & sh de --- uni-kiel & oncampus com --- google uni-kiel --- informatik & klassalt & praesidium & bwl informatik --- ddi & theorie & zs & se & rtsys zs --- git oncampus --- iqsh sh --- nah google --- mail & maps & images & video

Der Domainname iqsh.oncampus.de ist folgendermaßen zu lesen: de ist die Top-Level-Domain (TLD) und gibt an, dass die Domain in Deutschland registriert ist. Andere Top-Level-Domains sind etwa at für Österreich, sh für St. Helena oder edu für Bildungseinrichtungen. oncampus ist die Domain und gibt an, dass diese Webseite auf einem Computer des E-Learning-Anbieters oncampus liegt. iqsh ist eine Subdomain und identifiziert genau denjenigen unter den Computern von oncampus, auf dem die Seite liegt. Subdomains sind ebenfalls hierarchisch organisiert und schlüsseln die Organisation der Server genauer auf. Beispielsweise ist die Webanwendung GitLab der Arbeitsgruppe Zuverlässige Systeme am Institut für Informatik der Uni Kiel über die Domain git.zs.informatik.uni-kiel.de erreichbar. Eine so zusammengesetzte Namensangabe wird als Fully Qualified Domain Name (FQDN) bezeichnet.

Resource Records

Zu einem Domainnamen können die verschiedensten Informationen bei einem DNS-Server hinterlegt sein. Diese Informationen werden in so genannten Resource Records gespeichert, die jeweils einen bestimmten Typ haben und dort öffentlich zugänglich sind. Einige dieser Typen sind:

Typ	Information
`A`	Gibt die IPv4-Adresse zu einer Domain an
`AAAA`	Gibt die IPv6-Adresse zu einer Domain an
`CNAME`	Gibt den eigentlichen Domainnamen an, der sich hinter einer Alias-Domain verbirgt.
`MX`	Gibt den Mailserver an, der für eine bestimmte Domain zuständig ist
`NS`	Gibt den Nameserver an, der für die Subdomains einer Domain zuständig ist
`SOA`	Gibt den Start of Authority an, d.h. die Stelle, die alle Informationen zu einer Domain ursprünglich verwaltet.
`SRV`	Gibt an, welche IP-basierten Dienste innerhalb einer Domain angeboten werden.
`TXT`	Kann beliebige Informationen zur Domain in Textform speichern

Mit Kommandozeilenwerkzeugen wie nslookup (für Windows) oder dig/dog (für Linux) können diese Resource Records abgefragt werden.

Verschiedene DNS-Abfragen mit dem Werkzeug dog

DNS-Abfragen

Jede Anfrage an einen Domainnamen muss zuerst in eine IP-Adresse übersetzt werden. Diese Anfrage geht theoretisch zunächst an einen der 13 weltweit verteilten Root-Nameserver, welche die Adressauflösung an der Wurzel des Adressbaums erledigen und in der Regel nur eine Liste der DNS-Server zurückliefern, die für die nächsttiefere Domain zuständig sind (die sogenannten autoritativen Nameserver) und die Anfrage dann weiterverarbeiten.

Wenn ein DNS-Server die Informationen zur angefragten Domain vorrätig hält, wird die gesuchte IP-Adresse direkt zurückgegeben, ansonsten wird die Anfrage entweder iterativ oder rekursiv weitergeleitet.

Iterative Namensauflösung

Iterative Namensauflösung bedeutet, dass der DNS-Server an den Client eine Liste von anderen DNS-Servern weiterleitet, die Genaueres zur gesuchten Domain wissen könnten.

Eine iterative Namensauflösung für die Adresse iqsh.oncampus.de könnte etwa so ablaufen:

sequenceDiagram participant A as Client participant B as b.root-servers.net participant C as z.nic.de participant D as dns-3.dfn.de A->>+B: iqsh.oncampus.de IN A note over A, B: Client fordert IP-Adresse (A) vom Root-Server B->>-A: de 172800 NS IN a.nic.de,
de 172800 NS IN f.nic.de,
de 172800 NS IN l.de.net,
de 172800 NS IN n.de.net,
de 172800 NS IN s.de.net,
de 172800 NS IN z.nic.de note over A, B: Root-Server liefert eine Liste der DNS-Server,
die für .de zuständig sind A->>+C: iqsh.oncampus.de IN A note over A, C: Client fordert IP-Adresse (A) von einem dieser Server,
hier z.nic.de C->>-A: oncampus.de 86400 NS IN dns-1.dfn.de,
oncampus.de 86400 NS IN dns-3.dfn.de,
oncampus.de 86400 NS IN dns.fh-luebeck.de note over A, C: z.nic.de liefert eine Liste der DNS-Server,
die für .oncampus.de zuständig sind. A->>+D: iqsh.oncampus.de IN A note over A, D: Client fordert IP-Adresse (A) von dns-3.dfn.de D->>-A: iqsh.oncampus.de 86400 A IN 193.175.122.162 note over A, D: dns-3.dfn.de liefert die IP-Adresse von iqsh.oncampus.de an den Client

Rekursive Namensauflösung

Rekursive Namensauflösung bedeutet, dass der DNS-Server die Anfrage an einen anderen DNS-Server weiterleitet, wartet, bis er von diesem ein Ergebnis bekommt (das wiederum rekursiv weitergeleitet worden sein könnte) und dieses an den Client zurückliefert.

Eine rekursive Namensauflösung für die Adresse iqsh.oncampus.de könnte etwa so ablaufen:

sequenceDiagram participant A as Client participant B as b.root-servers.net participant C as z.nic.de participant D as dns-3.dfn.de A->>+B: iqsh.oncampus.de IN A note over A, B: Client fordert IP-Adresse (A) vom Root-Server B->>+C: iqsh.oncampus.de IN A note over B, C: Root-Server leitet die Anfrage weiter
an einen DNS-Server, der für die Domain
.de zuständig ist, hier z.nic.de. C->>+D: iqsh.oncampus.de IN A note over C, D: z.nic.de leitet die Anfrage weiter
an einen DNS-Server, der für die Domain
.oncampus.de zuständig ist, hier dns-3.dfn.de D->>-C: iqsh.oncampus.de
86400 A IN 193.175.122.162 note over C, D: dns-3.dfn.de liefert die IP-Adresse
von iqsh.oncampus.de an z.nic.de C->>-B: iqsh.oncampus.de
86400 A IN 193.175.122.162 note over B, C: z.nic.de liefert die IP-Adresse
von iqsh.oncampus.de an den Root-Server B->>-A: iqsh.oncampus.de
86400 A IN 193.175.122.162 note over A, B: Root-Server liefert die IP-Adresse an den Client

Der Nachteil von rekursiver Namensauflösung ist, dass die Server am Anfang dieser Abfragekette – vor allem also die Root-Server – die Anfragen über einen längeren Zeitraum zwischenspeichern und die Antworten der anderen Nameserver abwarten müssen.

Vorteile der rekursiven Namensauflösung sind, dass die DNS-Client-Software simpler gehalten werden kann und dass alle DNS-Server auf dem Weg der Abfrage die IP-Adresse ebenfalls erhalten und gegebenenfalls für folgende DNS-Abfragen zwischenspeichern können.

DNS-Protokoll

DNS bezeichnet desweiteren auch das Anwendungsprotokoll, das beschreibt, wie ein Client mit einem DNS-Server kommuniziert, um die IP-Adresse zu einem Domainnamen zu ermitteln. Die Kommunikation besteht aus Anfragen (DNS Query) und Antworten (DNS Reply).

Eine DNS Query beinhaltet einen oder mehrere Domainnamen, deren IP-Adressen ermittelt werden sollen. Daneben werden in der Nachricht Optionen angegeben, z. B. ob eine rekursive Namensauflösung gewünscht ist oder nicht.
Eine DNS Reply beinhaltet die Anfragen und Antworten für jede Anfrage, in denen u. a. die ermittelten IP-Adressen der Domainnamen angegeben sind (oder die IP-Adressen der nächsten verantwortlichen DNS-Server, wenn der Name noch nicht vollständig aufgelöst wurde).

Zur Übertragung von DNS-Nachrichten über die Transportschicht werden sowohl TCP als auch UDP auf dem Standardport 53 genutzt.

DHCP

Das Dynamic Host Configuration Protocol DHCP dient dazu, Computern, die einem Netzwerk neu beitreten, automatisch eine IP-Adresse zuzuweisen. Das geschieht zum Beispiel (in der Regel), wenn man sich im heimischen WLAN einloggt oder auf dem Handy die mobile Datennutzung aktiviert. Damit dies gelingt, muss im lokalen Netzwerk ein DHCP-Server aktiviert sein, in heimischen Netzwerken ist dies überwiegend Teil des Funktionsumfangs des WLAN-Routers.

Da der suchende Computer weder eine eigene IP-Adresse hat noch die des DHCP-Servers kennt, werden alle Anfragen und Antworten an die Broadcast-Adresse 255.255.255.255 gesende. Das bedeutet, dass diese Datenpakete bei allen Rechnern im lokalen Netz ankommen. In jeder Anfrage und jeder Antwort wird die MAC-Adresse des suchenden Rechners mitgeschickt; dadurch kann dieser Rechner erkennen, welche Nachrichten an ihn gesendet sind.

Die Zuweisung einer IP-Adresse durch DHCP verläuft regelhaft in fünf Schritten:

DHCPDISCOVER. Der Client sendet eine DHCPDISCOVER-Anfrage mit seiner MAC-Adresse an die Broadcast-IP-Adresse 255.255.255.255. Als Absenderadresse gibt der Client die Netzwerk-Adresse 0.0.0.0 an.
DHCPOFFER. Der DHCP-Server reagiert auf die Anfrage und bietet dem Client eine IP-Adresse aus seinem Adressbereich an. Zusätzlich übermittelt der DHCP-Server noch weitere Informationen wie die verwendete Subnetzmaske, die IP-Adresse des Standardgateways oder des zu verwendenden DNS-Servers. Da der Client noch keine IP-Adresse hat, wird auch dieses Angebot an die 255.255.255.255 geschickt.
ARP REQUEST. Um sicherzugehen, dass die angebotene IP-Adresse nicht schon anderweitig vergeben ist (vielleicht hat ein anderer Nutzer seinen Computer händisch konfiguriert?), schickt der Client einen ARP REQUEST an alle Geräte.
Nun gibt es zwei Möglichkeiten:
1. DGHCPDECLINE, falls der ARP REQUEST beantwortet wird, denn dann ist die angebotene IP-Adresse schon vergeben. In diesem Fall schickt der Client einen DHCPDECLINE an den Server und beginnt das ganze Prozedere von Schritt 1. Der Server merkt sich, dass diese IP-Adresse schon belegt ist, und wird diese in Zukunft nicht mehr anbieten.
2. DHCPREQUEST, falls der ARP REQUEST ungehört verhallt, denn dann ist die angebotene IP-Adresse noch frei. Der Client schick nun einen DHCPREQUEST und bittet den DHCP-Server darum, die angebotene IP-Adresse nutzen zu dürfen.
Der Server kann darauf auf zweierlei Arten reagieren:
1. DHCPACK bestätigt die Anfrage, der Client übernimmt die IP-Adresse.
2. DHCPNAK lehnt die Anfrage ab, der Client muss den ganzen Prozess von vorn mit einem DHCPDISCOVER beginnen.

Zur Übertragung von DHCP-Nachrichten über die Transportschicht wird UDP auf den Ports 67 (für den Server) und 68 (für den Client) genutzt.

Mailprotokolle

Für den Versand und Abruf von E-Mails kommen drei Protokolle zum Einsatz:

das Post Office Protocol, das in Version 3 (POP3) zum Abruf von E-Mails verwendet wird
das Interactive Mail Access Protocol (IMAP), das ebenfalls dem E-Mail-Abruf dient
das Simple Mail Transfer Protocol (SMTP) zum Versand von E-Mails

POP3

POP3 ist ein einfaches Protokoll zum Abruf von E-Mails von Mail-Servern. Typischerweise lauscht POP3 auf dem TCP-Port 110. Da POP3 normalerweise keine verschlüsselte Datenübertragung vorsieht, gibt es auch die SSL-verschlüsselte Variante POP3S, die auf Port 995 lauscht.

sequenceDiagram participant A as Client participant B as Server A->>B: stellt Verbindung her B->>A: +OK Willkommen bei mustermail.de note over A, B: Server sendet +OK zur Bestätigung oder -ERR bei Fehlern sowie ergänzende Erklärungen A->>B: USER max.mustermann B->>A: +OK Passwort bitte? A->>B: PASS s00p3rs1ch3r3sPA$$W0RT note over A, B: Nutzernamen und Passwörter werden prinzipiell unverschlüsselt übertragen.
Es gibt aber auch Erweiterungen für POP3, um das Passwort oder die gesamte Kommunikation verschlüsselt zu übertragen. B->>A: +OK Passwort passt. A->>B: STAT note over A, B: Client fragt mit STAT ab, wie viele ungelesene Nachrichten vorliegen B->>A: +OK 2 892 note over A, B: lies 2 ungelesene Nachrichten, die zusammen 892 Byte lang sind A->>B: LIST B->>A: +OK 2 ungelesene Nachrichten (892 Byte)
1 196
2 696
. note over A, B: die einzelnen Mails werden durchnummeriert aufgezählt, ihre Größe wird dabei mit angegeben.
Längere Antworten des Servers werden mit einem Punkt in einer Extrazeile beendet. A->>B: RETR 1 note over A, B: Client ruft E-Mail Nr. 1 ab B->>A: +OK Hier ist Mail Nr. 1
From: erika.mustermann@mustermail.de
To: max.mustermann@mustermail.de
... A->>B: RETR 2 B->>A: +OK Hier ist Mail Nr. 2... A->>B: DELE 1 B->>A: +OK Mail 1 zum Löschen markiert note over A, B: Es gibt keine Möglichkeit in POP3, gelesene E-Mails auf dem Server zu hinterlassen.
Entweder lädt man sich die Mail herunter und löscht die Kopie auf dem Server
oder die Kopie auf dem Server bleibt ungelöscht und wird bei jedem folgenden E-Mail-Abruf als ungelesen angezeigt. A->>B: DELE 2 B->>A: +OK Mail 2 zum Löschen markiert A->>B: QUIT note over A, B: Gelesene Mails werden nur gelöscht, wenn die Verbindung sauber mit QUIT beendet wird. B->>A: +OK Auf Wiedersehen

Gegenüber IMAP, das ebenfalls zum Mail-Abruf genutzt wird, bietet POP3 den Nachteil, dass es nur ein Postfach für eingehende E-Mails gibt und diese nach dem Abruf vom Server gelöscht werden müssen. Mehrere E-Mail-Clients zu synchronisieren, wird dadurch enorm erschwert.

IMAP

Im Gegensatz zum POP, an dem die Entwicklung zum Erliegen gekommen ist, hat sich IMAP als Standard zum E-Mail-Abruf etabliert. IMAP ermöglicht es, E-Mails auf dem Server in Ordnern zu sortieren und mittels Flags zusätzliche Informationen zu einer E-Mail zu speichern.

Flag	Information
`\Seen`	E-Mail wurde gelesen
`\Answered`	E-Mail wurde beantwortet
`\Flagged`	E-Mail wurde als dringend markiert
`\Deleted`	E-Mail wurde zum Löschen vorgemerkt
`\Draft`	E-Mail ist noch im Entwurfsstadium

Diese Flags erleichtern es enorm, E-Mails über mehrere Geräte abzurufen, weil die Mails auf dem Server verbleiben können und durch die Flags auf allen Clients angezeigt werden kann, ob die Mails bereits gelesen und bearbeitet worden sind.

Die Kommunikation verläuft vom Herstellen bis zum Schließen in mehreren Zuständen:

IMAP hat hierbei drei Möglichkeiten, auf einen Verbindungsaufbau zu reagieren:

OK ist der Standardfall; dann muss der Nutzer sich zunächst auf irgendeine Art und Weise authentifizieren
Eine PREAUTH-Begrüßung ist in Situationen sinnvoll, wenn der Nutzer sich bereits anderweitig authentifiziert hat; dann kann dieser Schritt entfallen
Wenn der Client sich aus welchem Grund auch immer nicht mit dem Server verbinden soll, kann dieser die Verbindung mit einer BYE-“Begrüßung” von vornherein ablehnen.

SMTP

SMTP dient anders als POP und IMAP dem Versand von E-Mails und lauscht auf dem Port 25. Praktisch kann SMTP an vielen Schulen ausprobiert werden, da die Schulverwaltungssoftware IServ einen unverschlüsselten SMTP-Server zur Verfügung stellt, der zumindest eingehende E-Mails zu autorisierten Accounts akzeptiert.

Der Versand einer E-Mail mit SMTP läuft folgendermaßen ab:

sequenceDiagram participant A as Client participant B as Server A->>B: stellt Verbindung her B->>A: 220 Willkommen bei mustermail.de A->>B: HELO max.mustermann B->>A: 250 Hallo max.mustermann A->>B: MAIL FROM: max.mustermann@mustermail.de B->>A: 250 OK A->>B: RCPT TO: erika.gabler@mustermail.de B->>A: 250 OK A->>B: DATA B->>A: 354 Schick mir den Inhalt der Mail,
beende diese mit einem . auf einer Extra-Zeile. note over A, B: Die Daten der E-Mail können sehr umfangreich sein,
sodass es für den Client Sinn ergibt, diese in mehreren Anfragen abzusenden.
Der Server akzeptiert schweigend alle Nachrichten des Clients,
bis ihm ein einzelner Punkt in einer Zeile gesendet wird.
Dies ist das Signal für das Ende der Nachricht. A->>+B: From: Max Mustermann A->>B: To: Erika Gabler A->>B: Subject: Urkunden sind abgeschickt! A->>B: Erika, mein Mausepups! A->>B: Ich habe unsere Geburtsurkunden ans Standesamt geschickt! A->>B: Unserer Hochzeit steht nichts mehr im Wege! A->>B: Bald bist du auch eine Mustermann! A->>B: In Liebe, A->>B: Dein Maxibär A->>B: . note over A, B: Dieser . signalisiert dem Server das Ende der Nachricht, deswegen sendet er eine bestätigende Antwort. B->>-A: 250 Die Mail wird versendet A->>B: QUIT B->>A: 221 Auf Wiedersehen

In SMTP ist eine Authentifizierung und Autorisierung des Nutzers standardmäßig nicht vorgesehen. Deswegen bergen öffentlich zugängliche unverschlüsselte SMTP-Server ein enorm hohes Risiko für Missbrauch und Spam. Die meisten SMTP-Server sind darum nur durch verschlüsselte Schichten erreichbar, die eine Authentifizierung mit TLS erzwingen.

Dieser Statuscode stammt aus der scherzhaften HTTP-Erweiterung HTCPCP (Hyper Text Coffee Pot Control Protocol), das der Steuerung von Kaffeemaschinen dienen soll. Siehe RFC 2324: Hyper Text Coffee Pot Protocol (HTCPCP) ↩︎
Der Statusode 451 ist eine Anspielung auf den dystopischen Roman “Fahrenheit 451” von Ray Bradbury. ↩︎