FAQ - News und Mail mit Hilfe von Telnet kontrollieren

Einführung

Wenn es Probleme in der Kommunikation zwischen Server und Client gibt, kann man versuchen, mit Telnet auf den jeweiligen Server zuzugreifen. Wie das geht, soll im Folgenden gezeigt werden (mit Beschränkung auf die wichtigsten Möglichkeiten).

Die Bildschirmausgabe kann kopiert und zum Beispiel in Newspostings veröffentlicht werden und so bei der Fehlersuche behilflich sein.

Wesentlich besser ist im Übrigen das Tool PuTTY, auf das hier aber nicht eingegangen wird (das Vorgehen ist auch im Wesentlichen dasselbe). PuTTY kann auch direkt mit verschlüsselten Verbindungen umgehen, bei Telnet muss dazu STunnel dazwischen geschaltet werden. PuTTY kann unter http://www.chiark.greenend.org.uk/~sgtatham/putty/ heruntergeladen werden.

Eine weitere, sehr viel einfachere (und deutschsprachige) Alternative ist TT von Th. Gohel (herunterzuladen unter http://www.pbhq.de/filebase/fdb141.html#TT.ZIP).

Bei den folgenden Beispielen sind Nutzereingaben blaugrün gefärbt und mit „> “ markiert, Serverausgaben sind dunkelblau dargestellt mit davorgesetztem „< “ (Markierungen in Anlehnung an das Hamsterlog).

Gehe direkt zu:

News mit Telnet
Mail abholen mit Telnet – IMAP
Mail abholen mit Telnet – POP3
Mail versenden mit Telnet

Allgemeines

Telnet ist über die Kommandozeile zugängig. Entweder man öffnet die DOS-Konsole („Start“ → „Programme“ → „Zubehör“ → „Eingabeaufforderung“ [bzw. bei Windows 9x „Start“ → „Programme“ → „MS-DOS-Eingabeaufforderung“]), oder man geht gleich über „Start“ → „Ausführen…“ und gibt dort folgendes ein:

telnet <Server> <Port>

Wichtig: Die Parameter ‚<Server>‘ und ‚<Port>‘ werden hier nicht, wie sonst oft üblich, durch einen Doppelpunkt, sondern durch Leerzeichen getrennt.

<Server>:Ersetzen durch Name oder IP-Nummer des Rechners, der angesprochen werden soll. Der Hamster ist meist auf demselben Rechner installiert, an dem man sitzt. Bei Kommunikation mit seinem Nager kann man dann ‚localhost‘ oder ‚127.0.0.1‘ für ‚<Server>‘ setzen (hier und im Folgenden natürlich immer ohne Anführungszeichen).

<Port>:Ersetzen durch Portnummer. Wenn sie von der jeweiligen Standardportnummer abweicht, sollte das bei der Einrichtung bekannt gegeben worden sein. Für die Standardportnummern gibt es auch Portbezeichnungen, die man hier ebenso verwenden kann. Welche Bezeichnung welchem Port zugeordnet ist (z. B. ‚smtp‘ statt ‚25‘ oder ‚nntp‘ statt ‚119‘), entnimmt Windows einer Datei namens „services“ (ohne Extension), die bei neueren Windowsversionen in „%Windir%\System32\Drivers\etc\“ zu finden ist, bei älteren im Windows-Hauptverzeichnis.

Die folgende Serverantwort kann sehr verschieden aussehen. Für die Kommunikation untereinander ist aber – mit einigen Ausnahmen – nur die Zeichenkette am Anfang wichtig (meist dreistellige Zahlen), der sehr oft folgende Text ist nur für menschliche Leser gedacht.

Das weitere Vorgehen hängt von dieser Serverantwort ab und davon, was man überprüfen will: Meldet sich beispielsweise statt des erwarteten Servers ein anderes Programm, muss man in dieser Richtung weitersehen.

Ansonsten: Je nachdem, wo es Probleme gibt, siehe unten weiter unter „News mit Telnet“, unter „Mail abholen mit Telnet – IMAP“ bzw. „Mail abholen mit Telnet – POP3“ oder aber unter „Mail versenden mit Telnet“.

Wie oben bereits erwähnt, handelt es sich hier jeweils nur um einen Überblick. Ausführliche Informationen findet man direkt im jeweiligen RFC bzw. in den jeweiligen RFCs, die z. B. unter https://www.rfc-editor.org/rfc-index.html oder https://www.rfc-editor.org/rfc-index.html abgerufen werden können.

Alle folgenden Eingaben, insbesondere die Anmeldung, sollte man immer einigermaßen zügig hintereinander machen. Sonst kommt es leicht zu einem Timeout, und die Verbindung wird vom Server beendet.

Es ist übrigens egal, ob man die Kommandos in Groß- oder Kleinschreibung eingibt. Server, die nur eine Schreibvariante akzeptieren, sind fehlkonfiguriert. Wenn man aber bei einer Schreibweise ausschließlich Fehlermeldungen erhält, kann man es auch einmal mit der anderen Variante probieren.

Damit man im Telnet-Fenster die eigenen Nutzereingaben sehen kann, muss man bei Windows 9x das lokale Echo aktivieren über das Menü „Terminal“ → „Einstellungen“ → „[x] Lokales Echo“. Bei Windows-NT-Versionen muss man dafür unter Umständen einmalig etwas anders vorgehen, als oben beschrieben: Nur ‚telnet‘ eingeben, die Anzeige ändert sich zu ‚Microsoft Telnet> ‘; dort eingeben: ‚set local_echo‘ und nach Betätigung der Return-Taste entweder mit ‚open <Server> <Port>‘ fortfahren oder mit ‚quit‘ den Telnet-Client beenden.

Die Korrektur der Eingaben funktioniert bei allen Windows-Versionen nicht – auch wenn nach einem Korrekturversuch im Telnet-Fenster der richtige Befehl angezeigt wird, antwortet der Server mit einer Fehlermeldung (bei PuTTY funktioniert das Löschen dagegen).

Bei Windows 9x kann zusätzlich der Inhalt des Telnet-Fensters nicht gescrollt werden. Will man nachträglich die vorher gemachten Eingaben und Antworten darauf sehen (um sie z. B. in ein Newsposting einzufügen), empfiehlt sich ein Log. Dieses kann mit „Terminal“ → „Protokoll starten…“ erstellt werden; zum Abschluss dann auf „Terminal“ → „Protokoll beenden“ gehen (bei TT wird dagegen zwangsweise eine Logdatei erstellt).

Ein paar Worte zum hier verwendeten Namen ‚pausbacke.hamster.localhost‘: Dieses ist ein für die Beispiele ausgedachter Name (ebenso wie es einen Hamster in einer solchen Version wohl nie geben wird). Bei Hamstern, die nicht nur innerhalb eines LAN erreichbar sind bzw. nicht auf Rechnern arbeiten, die per Telefon an das Internet angebunden sind, muss der Name ein „Fully Qualified Domain Name“ (FQDN) sein (Forderung in SMTP, s. u.); der Eintrag erfolgt über das Menü „Einstellungen“ → „Lokale Server“ → „Allgemeines“ → „FQDN für spezielle Header, Peering etc.“ (siehe unbedingt auch Hilfe dazu und zum „FQDN für Message-ID“).

News mit Telnet

Das zugrundeliegende Protokoll ist NNTP, der Standardport ist 119. Zur Verbindungsaufnahme also eingeben:

> telnet pausbacke.hamster.localhost 119

Wenn nichts kaputt ist, sieht die Antwort etwa so aus:

< 200 NNTP-Server Classic Hamster Version 42.0 (Build
  42.0.8.15) (post ok) on pausbacke.hamster.localhost says: Hi!

Meldet sich jetzt nicht der erwartete Newsserver, kann man hier aufhören weiterzulesen und in Abhängigkeit von der Antwort an anderer Stelle nach Lösungen suchen.

Zur Bedeutung der dreistelligen Zahlen (Statuscodes):

1xx	Informative Mitteilung
2xx	Kommando in Ordnung
3xx	Kommando bis jetzt in Ordnung, erwarte weitere Eingaben
4xx	Kommando korrekt, konnte aber aus verschiedenen Gründen nicht ausgeführt werden
5xx	Kommando inkorrekt oder nicht implementiert, oder schwerer Programmfehler aufgetreten

Genaueres s. unter „Servermeldungen bzw. Protokoll-Antwortcodes“ bzw. im RFC 977. Nur soviel: Oben steht als erstes eine '200' – d. h., dass man auf diesem Server posten darf. Ein Server, der nur Lesezugang gewährt, würde eine '201' melden.

Übersicht über unten aufgeführte Kommandos:

HELP	Hilfe ausgeben lassen
AUTHINFO USER & AUTHINFO PASS	Authentifizierung
MODE READER	Sich als Newsclient ausgeben
LIST / LIST ACTIVE / LIST NEWSGROUPS	Anzeige der auf dem Server vorhandenen Newsgroups und Zusatzinformationen
NEWGROUPS	Anfrage nach neuen Gruppen
GROUP	Wechseln in eine Gruppe
XOVER	Übersicht über Artikel einer Gruppe
ARTICLE	Anzeige eines einzelnen Artikels
HEAD	Anzeige einzelner Header
BODY	Anzeige einzelner Textbodys
POST	Absetzen eines Postings, auch Absetzen eines Cancels & Absetzen eines Supersedes
QUIT	Ordnungsgemäßes Verlassen

Bei Eingabe von HELP erhält man meist eine Anzeige, welche Kommandos der Server unterstützt. (Das funktioniert gewöhnlich ohne Authentifizierung. Siehe sonst folgenden Punkt ‚AUTHINFO …‘.)

> help
< 100 Implemented commands follow:
< […]

Das Kommando muss von allen Servern unterstützt werden, die ausgegebene Liste kann aber auch leer sein!

Zur Authentifizierung dienen die Kommandos AUTHINFO USER und AUTHINFO PASS, s. folgendes Bsp.; ‚<User>‘ durch den Benutzernamen ersetzen und ‚<Pass>‘ durch das Passwort.

Achtung: Das Passwort ist im Klartext zu sehen und sollte bei einer Veröffentlichung des Dialogs anonymisiert werden (z. B. durch Sterne).

> authinfo user <User>
< 381 More authentication information required
> authinfo pass <Pass>
< 281 Authentication accepted

Alles gut, wir sind schon drin (Das war ja einfach!).

Bei manchen Servern ist es von Vorteil, durch Eingabe des Kommandos MODE READER mitzuteilen, dass man ein Client ist. Bei den meisten ist das aber die Voreinstellung.

> mode reader
< 200 You are already in this mode. Ignored.

Hier hätte man es also auch weglassen können.

Eingabe von LIST oder LIST ACTIVE liefert eine Anzeige der auf dem Server vorhandenen Newsgroups (pro Zeile eine), zum Format s. u.

Achtung: Das sind bei vielen Servern Zehntausende von Gruppen!

> list
< 215 list of newsgroups follows

‚list active <Gruppenmuster>‘ liefert ebenfalls eine Anzeige der auf dem Server vorhandenen Newsgroups (wieder pro Zeile eine), aber auf die in ‚<Gruppenmuster>‘ angegebene(n) Gruppe(n) eingeschränkt. Als Wildcards erlaubt sind ‚*‘ und ‚?‘ (und weitere, siehe in RFC 2980). Lässt man ‚<Gruppenmuster>‘ weg, hat man dasselbe Ergebnis wie oben!

> list active hamster.de.t*
< 215 list of newsgroups follows
< hamster.de.talk 54321 12345 y
< hamster.de.tools 9876 6789 y
< .

Verallgemeinert sieht jede Zeile so aus:

‚<Newsgroup> c b x‘, wobei ‚c‘ für die höchste vorhandene Artikelnummer steht, ‚b‘ für die niedrigste und ‚x‘ für einen der Buchstaben y, n oder m, was wiederum bedeutet ‚Posten erlaubt‘ (y) bzw. ‚nicht erlaubt‘ (n) oder ‚moderierte Gruppe‘ (m).

Bei einer leeren Liste würde nur der Punkt als Antwort erscheinen.

Das Kommando ‚LIST NEWSGROUPS <Gruppenmuster>‘, liefert für die auf dem Server existierende(n) und in ‚<Gruppenmuster>‘ angegebene(n) Gruppe(n) den (die) Gruppennamen und eine evtl. vorhandene Kurzbeschreibung. Hier sind dieselben Wildcards wie oben erlaubt. Achtung: Lässt man ‚<Gruppenmuster>‘ weg, bekommt man alle existierenden Gruppen aufgelistet!

> list newsgroups hamster.de.t*
< 215 information follows
< hamster.de.talk Gespraeche mit und ohne Hamster.
< hamster.de.tools Zusatztools fuer den Hamster.
< .

Eine leere Liste liefert wieder nur den Punkt.

Mit dem Kommando NEWGROUPS kann man erfahren, ob seit einem bestimmten Datum neue Gruppen angelegt wurden. Das Kommando muss man dazu in folgender Form eingeben: ‚newgroups <JJMMTT HHMMSS>‘ mit JJ = Jahr, MM = Monat, TT = Tag , HH = Stunde, MM = Minute, SS = Sekunde (alles zweistellig).

> newgroups 050523 233205
< 231 list of new newsgroups follows
< gruppe.gibt.es 32 23 y
< .

Hier gibt es seit dem 23. Mai 2005, 23:32:05, nur eine neue Gruppe. Das Format der Antwort ist dasselbe wie oben bei LIST. Eine leere Liste liefert wieder nur den Punkt.

Eingabe von ‚GROUP <Newsgroup>‘ wechselt in die mit ‚<Newsgroup>‘ angegebene Gruppe, sofern vorhanden. Die Serverantwort liefert dabei noch einige Informationen:

> group gruppe.gibt.es
< 211 5 23 32 gruppe.gibt.es

Verallgemeinert sieht die Serverantwort so aus:

‚<Statuscode> a b c <Newsgroup>‘. Dabei steht ‚a‘ für die Anzahl der Artikel in der Gruppe, ‚b‘ für die niedrigste vorhandene Artikelnummer, ‚c‘ für die höchste.

Wenn man sich die Differenz von ‚b‘ und ‚c‘ im Beispiel ansieht, sollte man erwarten, dass 10 Artikel vorhanden sind. Der Server meldet aber, dass er nur 5 Artikel besitzt. Die Erklärung für diesen scheinbaren Widerspruch ist, dass einzelne Artikel bereits wieder nachträglich gelöscht wurden (hier genau 5), zum Beispiel durch einen Cancel. Die Folge ist, dass keine fortlaufende und ununterbrochene Numerierung mehr existiert und es bei Anforderung einiger Artikel nach Nummer (s. u. bei ‚ARTICLE‘) Fehlermeldungen geben würde. (Nur fehlkonfigurierte Server füllen die Löcher in der Numerierung wieder auf.)

Mit dem Kommando ‚XOVER <Bereich>‘, erhält man eine Übersicht der mit ‚<Bereich>‘ angegebenen Artikel in der zuvor ausgewählten Gruppe. Diese Übersicht enthält beim Hamster die Headerfelder „Subject:“, „From:“, „Date:“, „Message-ID:“, „References:“ (nur, wenn nötig), „Bytes:“, „Lines:“ und „Xref:“, und zwar in dieser Reihenfolge ohne, dass die Bezeichnungen dieser Headerfelder dabei stehen (Ausnahme Xref). ‚<Bereich>‘ kann ‚niedrigereNummer-höhereNummer‘ oder eine einzelne Artikelnummer enthalten.

Welche Headerfelder in der Übersicht ausgegeben werden und in welcher Reihenfolge, kann man bei den meisten Servern durch Eingabe von ‚LIST OVERVIEW.FMT‘ erfahren.

> list overview.fmt
< 215 information follows
< Subject:
< […]
< Xref:full
< .
> group local.test
< 211 66 33 99 local.test
> xover 42
< 224 Overview information follows
< 42 Testposting <user@example.net> Tue, 20 Apr 2004 20:04:04 +0200
  <message-id.des.postings.nr.4711@mid.example.net>
  <message-id.des.referenzierten.postings@mid.example.net>
  123 5 Xref: pausbacke.hamster.localhost local.test:42
< .

Auch bei diesem Befehl markiert der allein stehende Punkt das Ende der Ausgabe.

Sollte man das GROUP-Kommando zuvor noch nicht ausgeführt haben, gibt es eine Fehlermeldung wie diese:

< 412 No news group selected

Entweder kann man in der Gruppe, in der man sich gerade befindet, einen Artikel über seine Nummer aufrufen oder unabhängig davon, welche Gruppe gerade eingestellt ist, jeden Artikel über seine Message-ID.

Will man statt des gesamten Artikels nur die Headerzeilen bzw. den Body erhalten, gibt man statt ARTICLE jeweils entweder HEAD oder BODY ein. Die drei Kommandos funktionieren auf identische Weise.

Variante 1: ‚article <nummer>‘

> group gruppe.gibt.es
< 211 5 23 32 gruppe.gibt.es
> article 23
< 220 23 <message-id_des_artikels23_in_gruppe.gibt.es@mid.example.net> article
< […]
< .

Der allein stehende Punkt ist hier die Markierung für das Artikelende. Wie die Serverausgabe zeigt, steht bei der Antwort nach dem Statuscode immer zunächst die Artikelnummer, dann die Message-ID.

Sollte man bei dieser Variante das GROUP-Kommando zuvor noch nicht ausgeführt haben, gibt es eine Fehlermeldung wie diese:

< 412 no newsgroup has been selected

Variante 2: ‚article <message-id>‘

> article <message-id.eines.artikels.irgendwo.auf.dem.Newsserver@mid.example.net>
< 220 42 <message-id.eines.artikels.irgendwo.auf.dem.Newsserver@mid.example.net> article
< […]
< .

Zum Absetzen eines Postings – per Telnet am besten nur in Testgruppen – muss man zunächst das Kommando POST eingeben, nach der Serverantwort dann auf eigenen Zeilen mindestens „From:“, „Subject:“ und „Newsgroups:“ angeben, anschließend eine Leerzeile einfügen, dann den Text und am Ende einen Punkt auf einer eigenen Zeile eingeben (jede Zeile mit <Return> abschließen). Es ist nicht nötig, zuvor das GROUP-Kommando auszuführen.

> post
< 340 OK, recommended ID <vorgeschlagene.message-id@mid.example.net>
> from: <user@example.net>
> subject: Testposting
> newsgroups: local.test
> [Leerzeile]
> Nur'n Test.
> .
< 240 article posted ok

Um einen Artikel zu canceln (genau genommen: um die Newsserver zu bitten, ob sie so nett sein könnten, den Artikel zu löschen), muss außer den oben genannten noch ein weiteres Headerfeld „Control:“ mit folgendem Inhalt angegeben werden: ‚control: cancel <Message-ID_DesZuCancelndenPostings>‘.

Entweder im „From:“ oder in einem zusätzlichen Headerfeld „Sender:“ muss dieselbe E-Mail-Adresse verwendet werden, die in dem zu cancelnden Posting im „From:“ bzw., sofern vorhanden, im „Sender:“ stand.

> post
< 340 OK, recommended ID <vorgeschlagene.message-id.fuer.cancel@mid.example.net>
> from: <alternative-adresse@example.net>
> sender: <user@example.net>
> subject: cmsg <message-id.des.zu.cancelnden.postings@mid.example.net>
> control: cancel <message-id.des.zu.cancelnden.postings@mid.example.net>
> newsgroups: local.test
> [Leerzeile]
> Cancelmessage.
> .
< 240 article posted ok

Server, die Cancel ausführen, sollten danach auf das Kommando ‚article <NummerDesGecanceltenPostings>‘ eine Fehlermeldung ausgeben. Da aus Performancegründen bei vielen großen Servern die Datenbank nur in größeren Abständen, unter Umständen nur einmal täglich (gewöhnlich nachts) gesäubert („gepurget“) wird, kann es sein, dass der Artikel noch über ‚article <Message-ID_Des_Gecancelten_Postings>‘ für einige Zeit abrufbar ist.

Will man dagegen einen geposteten Artikel durch eine neuere Version ersetzen, gibt man als zusätzliches Headerfeld „Supersedes:“ mit folgendem Inhalt an: ‚supersedes: <Message-ID_Des_Zu_Ersetzenden_Postings> ‘. Ideal ist, wenn man in diesem Fall auch die Message-ID des zu ersetzenden Postings als Referenz angibt (Headerfeld „References:“).

> post
< 340 OK, recommended ID <vorgeschlagene.message-id.fuer.supersede@mid.example.net>
> from: <user@example.net>
> subject: Supersede-Test, 2. Posting
> references: <message-id.des.zu.ersetzenden.postings@mid.example.net>
> supersedes: <message-id.des.zu.ersetzenden.postings@mid.example.net>
> newsgroups: local.test
> [Leerzeile]
> Achtung, Test, Test, Test!
> Dieses Posting soll das zuvor gesendete Posting mit der Message-ID
> <message-id.des.zu.ersetzenden.postings@mid.example.net> und dem
> Subject 'Supersede-Test, 1. Posting' ersetzen.
> .
< 240 article posted ok

Auch hier ist kein Server dazu gezwungen, ein solches Supersede auszuführen. Geschieht das nicht und hat man die References mit angegeben, bilden die Postings einen Thread (wobei das auch von der eventuellen Änderung des Subjects und den entsprechenden Einstellungen im Newsreader abhängt).

Zum ordnungsgemäßen Verlassen ‚QUIT‘ eingeben:

> quit
< 205 Closing connection.

Mail abholen mit Telnet – IMAP

Der Standardport ist 143.

Das Protokoll IMAP ist sehr umfangreich (RFC 3501 umfasst 108 Seiten), und vor allem sind die Kommandos zum Teil komplex. Deshalb meint der maßgebliche Entwickler des IMAP-Servers im Classic-Hamster: „Zum Teil per Telnet machbar, aber man will es nicht, es ist auch nicht dazu gedacht.“ Für umfangreiche Tests sollte man sich lieber einen alternativen IMAP-Clienten mit Logging-Fähigkeiten zulegen. Beschränken wir uns auf die etwas einfacheren Kommandos.

Zur Verbindungsaufnahme eingeben:

> telnet pausbacke.hamster.localhost 143   

Eine positive Antwort sieht z. B. so aus:

< * OK IMAP4rev1 Server Classic Hamster Version 42.0
  (Build 42.0.8.15) on pausbacke.hamster.localhost greets you!

Meldet sich jetzt nicht der erwartete IMAP-Server, kann man hier aufhören weiterzulesen und in Abhängigkeit von der Antwort an anderer Stelle nach Lösungen suchen.

Bevor es weitergeht, ein wichtiger Hinweis:

Bei IMAP muss jedem Client-Kommando eine eindeutige alphanumerische Zeichenkette, genannt Tag (ausgesprochen wird das „Tägg“), vorangehen. Am einfachsten ist es, von Null oder Eins hochzuzählen, evtl. noch zur Unterscheidung von anderen Zahlen durch einen oder wenige Buchstaben ergänzt. Die Serverantwort beginnt dann jedes Mal mit diesem Tag oder stattdessen einem Stern.

Vergisst man das Tag, wird der Server das Kommando irrtümlich für das Tag halten.

Mögliche Statusanzeigen sind:

<Tag> OK	Kommandoausführung erfolgreich
* OK	Informative Mitteilung
<Tag> NO	Fehlermeldung – korrektes Kommando, Ausführung aber nicht erfolgreich
* NO	Warnmeldung – Kommandoausführung aber möglich
<Tag> BAD	Fehlermeldung – Kommando bekannt, Ausführung aber wegen falscher Eingabe nicht möglich (z. B. unvollständiges Kommando)
* BAD	Fehlermeldung – unbekanntes Kommando oder interner Serverfehler
* PREAUTH	bereits mit Verbindungsaufnahme ist auf andere Weise Authentifizierung erfolgt (z. B. über Einwahl) – erscheint nur zu Beginn der Verbindung
* BYE	Antwort nach ordnungsgemäßer Abmeldung

Übersicht über unten aufgeführte Kommandos:

HELP	Hilfe anzeigen lassen
CAPABILITY	Auflistung der Fähigkeiten des Servers
LOGIN	Authentifizierung
LIST	Anzeige der Ordner
CREATE	Anlegen von Ordnern
DELETE	Löschen von Ordnern
RENAME	Umbenennen von Ordnern
LSUB	Anzeige der Abonnements
SUBSCRIBE / UNSUBSCRIBE	Abonnieren von Ordnern bzw. Abonnement aufheben
LOGOUT	Ordnungsgemäßes Verlassen

Obwohl es im RFC nicht definiert ist, kann man beim Hamster und evtl. einigen anderen Servern das Kommando HELP eingeben, um eine Anzeige zu erhalten, welche Kommandos der Server unterstützt.

> Tag1 help
< * Implemented Commands follow
< Tag1 {42}
< […]

Um eine Auflistung der Fähigkeiten des Servers zu erhalten, muss man das Kommando CAPABILITY eingeben.

> Tag2 capability
< * CAPABILITY IMAP4rev1 AUTH=CRAM-SHA1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5
< + AUTH=LOGIN IDLE LITERAL ID
< Tag2 OK I'm ready sending capabilities!

Wenn bei einem Server nicht aus Sicherheitsgründen LOGIN deaktiviert wurde (das sollte bei CAPABILITY als ‚LOGINDISABLED‘ deklariert werden), kann man sich mit ‚<Tag> login <User> <Pass>‘ anmelden. ‚<User>‘ natürlich durch den Benutzernamen ersetzen und ‚<Pass>‘ durch das Passwort.

Achtung! Das Passwort ist im Klartext zu sehen und sollte bei einer Veröffentlichung des Dialogs anonymisiert werden (z. B. durch Sterne).

> Tag3 login <User> <Pass>
< Tag3 OK LOGIN completed.

> Tag3 login <User> <Pass>
< Tag3 BAD LOGIN is switched off by server-admin. Please use AUTHENTICATE.

Allerdings sind die anderen Authentifizierungsmethoden (vgl. oben bei CAPABILITY die Angaben ‚AUTH=…‘) nicht für eine Telnet-Session geeignet.

Das Kommando LIST dient zur Anzeige der Ordner. Die Angabe erfolgt in der Form ‚<Tag> list "<Referenz>" "<Mailbox>"‘, wobei ‚<Referenz>‘ für einen Pfad zur Mailbox steht (die genaue Implementation ist serverabhängig!) und ‚<Mailbox>‘ für einen Ordner steht. Bei beiden sind die Wildcards ‚*‘ und ‚%‘ erlaubt, die sich nur dadurch unterscheiden, dass ‚*‘ den Hierarchietrenner einschließt (welcher das ist, hängt vom Server ab), ‚%‘ dagegen nicht (d. h. z. B., mit ‚list "*" "*"‘ wird die gesamte Ordnerliste angefordert!); ob Groß-/Kleinschreibung unterschieden wird, ist abhängig vom Betriebssystem des Servers (Windows und damit dem Hamster ist es egal). Leere Strings werden durch ‚""‘ (2x ") angegeben.

> Tag4 list "*" "*"
< * LIST () "/" "INBOX"
< […]
< * LIST () "/" "Test"
< * LIST () "/" "Test/Mail1"
< * LIST () "/" "Test/Mail2"
< Tag4 OK You have now the List!
> Tag5 list "" ""
< * LIST (\NOSELECT) "/" ""
< Tag5 OK You have now the List!
> Tag6 list "test" "*"
< * LIST () "/" "Test"
< * LIST () "/" "Test/Mail"
< * LIST () "/" "Test/Mail2"
< Tag6 OK You have now the List!
> Tag7 list "test" "%"
< * LIST () "/" "Test"
< Tag7 OK You have now the List!
> Tag8 list "test" "%/%"
< * LIST () "/" "Test/Mail"
< * LIST () "/" "Test/Mail2"
< Tag8 OK You have now the List!

Mit ‚<Tag> CREATE <Ordner>‘ wird ein Ordner angelegt. Wenn der Server die Erstellung von Unterordnern unterstützt, dann kann man hier bei ‚<Ordner>‘ den Pfad mit angeben. Wenn der übergeordnete Ordner dabei noch nicht existiert, wird er mitangelegt. Für den Namen sollten bei einer Telnet-Session nur ASCII-Zeichen von 0x21 (dez. 33) bis 0x7E (dez. 126) mit Ausnahme des „&“ verwendet werden. Ob zwischen Groß- und Kleinschreibung unterschieden wird, ist abhängig vom Betriebssystem des Servers.

> Tag9 create Testordner/Unterordner
< Tag9 OK Mailbox created!
> Tag10 list * testo*
< * LIST () "/" "Testordner"
< * LIST () "/" "Testordner/Unterordner"
< Tag10 OK You have now the List!

Gelöscht werden Ordner mit ‚<Tag> DELETE <Ordner>‘. Enthält der ausgewählte Ordner jedoch noch Unterordner, so kann er nicht gelöscht werden, sondern es wird dabei sein Status geändert. Ebenso wenig kann der Ordner INBOX gelöscht werden. Ob für ‚<Ordner>‘ zwischen Groß- und Kleinschreibung unterschieden wird, ist abhängig vom Betriebssystem des Servers.

> Tag11 delete testordner
< Tag11 OK Mailbox deleted!
> Tag12 list * testo*
< * LIST (\NOSELECT) "/" "Testordner"
< * LIST () "/" "Testordner/Unterordner"
< Tag12 OK You have now the List!
> Tag13 delete testordner/unterordner
< Tag13 OK Mailbox deleted!
> Tag14 delete testordner
< Tag14 OK Mailbox deleted!
> Tag15 list * testo*
< Tag15 OK You have now the List!

> Tag16 rename Test/Mail Test/Mail1
< Tag16 OK Mailbox renamed.
> Tag17 list "test" "%/%"
< * LIST () "/" "Test/Mail1"
< * LIST () "/" "Test/Mail2"
< Tag17 OK You have now the List!

Mit dem Kommando LSUB kann man sich die abonnierten Ordner anzeigen lassen. Die Angabe erfolgt in der Form ‚<Tag> lsub "<Referenz>" "<Mailbox>"‘, wobei ‚<Referenz>‘ für einen Pfad zur Mailbox steht (die genaue Implementation ist serverabhängig!) und ‚<Mailbox>‘ für einen Ordner steht. Bei beiden sind die Wildcards „*“ und „%“ erlaubt, die sich nur dadurch unterscheiden, dass „*“ den Hierarchietrenner einschließt (welcher das ist, hängt vom Server ab), „%“ dagegen nicht (d. h. z. B., mit ‚lsub "*" "*"‘ wird die gesamte Liste der abonnierten Ordner angefordert!); ob Groß-/Kleinschreibung unterschieden wird, ist abhängig vom Betriebssystem des Servers (Windows und damit dem Hamster ist es egal). Leere Strings werden durch ‚""‘ (2x ") angegeben.

> Tag18 lsub "*" "*"
< * LSUB () "/" "Test"
< Tag18 OK You have now the List!

Mit dem Kommando SUBSCRIBE abonniert man einen Ordner. Es muss für jeden zu abonnierenden Ordner ein eigenes ‚<Tag> subscribe <Ordner>‘ eingegeben werden, wobei ‚<Ordner>‘ inklusive Pfad anzugeben ist.

Umgekehrt wird mit ‚<Tag> UNSUBSCRIBE <Ordner>‘ ein Abonnement aufgehoben. Auch das muss für jeden Ordner einzeln durchgeführt werden.

Ob für ‚<Ordner>‘ Groß-/Kleinschreibung unterschieden wird, ist abhängig vom Betriebssystem des Servers.

> Tag19 subscribe test/mail1
< Tag19 OK Mailbox subscribed
> Tag20 subscribe test/mail2
< Tag20 OK Mailbox subscribed
> Tag21 lsub "*" "mail*"
< * LSUB () "/" "Test/Mail1"
< * LSUB () "/" "Test/Mail2"
< Tag21 OK You have now the List!
> Tag22 unsubscribe test/mail1
< Tag22 OK Mailbox unsubscribed
> Tag23 unsubscribe test/mail2
< Tag23 OK Mailbox unsubscribed
> Tag24 lsub "*" "mail*"
< Tag24 OK You have now the List!

Zum ordnungsgemäßen Verlassen dient das Kommando LOGOUT:

> Tag25 logout
< * BYE IMAP4rev1 closing connection - goodbye!
< Tag25 OK Closing.

Mail abholen mit Telnet – POP3

Der POP3-Standardport ist 110.

Zur Verbindungsaufnahme also eingeben:

> telnet pausbacke.hamster.localhost 110

Eine positive Antwort sieht z. B. so aus:

< +OK POP3-Server Classic Hamster Version 42.0 (Build
  42.0.8.15) pausbacke.hamster.localhost greets you!

Meldet sich jetzt nicht der erwartete POP3-Server, kann man hier aufhören weiterzulesen und in Abhängigkeit von der Antwort an anderer Stelle nach Lösungen suchen.

Mögliche Statusanzeigen (hier keine Zahlen):

+OK	Alles in Ordnung
-ERR	Fehler

Übersicht über unten aufgeführte Kommandos:

HELP	Hilfe ausgeben lassen
CAPA	Optionale Kommandos anzeigen lassen
USER & PASS	Authentifizierung
STAT	Übersicht über Mailbox
LIST	Aufstellung des Mailboxinhaltes
UIDL	Auflistung der UID
TOP	Header (und optional Teile des Bodys) abrufen
RETR	Eine Nachricht vollständig abrufen
DELE	Nachrichten löschen
RSET	Markierung zum Löschen rückgängig machen
QUIT	Ordnungsgemäßes Verlassen

Obwohl es im RFC nicht definiert ist, kann man bei vielen Servern das Kommando HELP eingeben, um eine Anzeige zu erhalten, welche Kommandos der Server unterstützt.

> help
< +OK Implemented commands follow:
< […]
< .

Mit dem Kommando CAPA kann man sich bei den meisten Servern die Authentifizierungsmöglichkeiten und optionale Kommandos anzeigen lassen.

> capa
< +OK Capability of non-authorization follows:
< TOP
< USER
< […]
< UIDL
< IMPLEMENTATION HamsterPOP3Server
< .

Die Angaben können variieren in Abhängigkeit davon, ob man authentifiziert ist oder nicht, deshalb auch der Hinweis in der ersten Zeile der Serverantwort.

Zur Authentifizierung dienen die Kommandos USER und PASS, s. folgendes Bsp.; ‚<User>‘ durch den Benutzernamen ersetzen und ‚<Pass>‘ durch das Passwort. (Es gibt weitere Authentifizierungsmethoden, die aber für eine Telnet-Session nicht geeignet sind.)

Achtung: Das Passwort ist im Klartext zu sehen und sollte bei einer Veröffentlichung des Dialogs anonymisiert werden (z. B. durch Sterne).

> user <User>
< +OK More authentication information required
> pass <Pass>
< +OK mailbox locked, 5 messages

Alles ist gut – wir sind drin und bekommen bei diesem Server auch gleich gemeldet, dass es 5 Mitteilungen in der Mailbox gibt.

Mit dem Kommando STAT erhält man eine Übersicht über seine Mailbox.

> stat
< +OK 5 3220

Verallgemeinert sieht die Antwort so aus: ‚<Statusanzeige> n m‘, wobei ‚n‘ die Anzahl der Nachrichten in der Mailbox darstellt (hier also 5) und ‚m‘ die Gesamtgröße in Bytes angibt (hier 3220 Bytes).

Mit dem Kommando LIST kann man eine detailliertere Aufstellung erhalten. Für jede Nachricht wird dann in einer eigenen Zeile erst die Nummer und dann die Größe in Bytes aufgeführt. Wenn man viele Nachrichten in der Mailbox hat, kann die Liste also sehr groß werden!

Mit ‚list <Nummer>‘ kann man die Angabe auf eine einzelne Nachricht einschränken. Die Numerierung erfolgt bei jeder Anmeldung neu, ändert sich während jeder Session aber nicht.

> list
< +OK 5 messages
< 1 999
< 2 666
< 3 1111
< 4 333
< 5 111
< .
> list 3
< +OK 3 1111

Ein optionales Feature, das viele Server nutzen, ist die Vergabe von UID („Unique Identification Numbers“ / eindeutige Identifikationsnummern). Wie der Name vermuten lässt, bleibt die UID für jede Nachricht immer konstant. Dadurch erst wird es zum Beispiel möglich, bereits einmal geladene Mail bei späteren Sessions zu ignorieren oder nach einem festen Zeitraum zu löschen.

Um eine Auflistung dieser UIDs zu bekommen, muss man das Kommando UIDL (für „Unique ID Listing“) eingeben. Ob ein Server dieses Kommando unterstützt, erfährt man durch Eingabe von CAPA.

Mit ‚uidl <Nummer>‘ wird die Ausgabe wieder auf die mit ‚<Nummer>‘ angegebene Nachricht beschränkt, wobei man ‚<Nummer>‘ durch das Kommando LIST erhält.

> uidl
< +OK
< 1 abcdefghijklmnopqrstuvwxyz1234567890
< 2 zyxwvutsrqponmlkjihgfedcba0987654321
< 3 1234567890abcdefghijklmnopqrstuvwxyz
< 4 abcdefghijklmnopqrstuvwxyz0987654321
< 5 zyxwvutsrqponmlkjihgfedcba1234567890
< .
> uidl 3
< +OK 3 1234567890abcdefghijklmnopqrstuvwxyz

Das erlaubte Format der UID ist: 1 bis 70 Zeichen von 0x21 (dez. 33) bis 0x7E (dez. 126), also aus dem ASCII-Bereich.

Manche Server haben in der Vergangenheit das Gebot der Eindeutigkeit verletzt, indem sie immer wieder neue „UID“ (die hier diesen Namen nicht verdienten) vergaben.

Auch das Kommando TOP ist zwar laut RFC optional, wird aber von fast allen Servern unterstützt, wenn auch zum Teil nicht ganz korrekt (mehr dazu unten). Ob ein Server dieses Kommando unterstützt, erfährt man durch Eingabe von CAPA.

Mit ‚top <Nummer> <Zeilen>‘ erhält man alle Header und die durch ‚<Zeilen>‘ angeforderte Anzahl an Zeilen des Bodys der mit ‚<Nummer>‘ angegebenen Nachricht. ‚<Nummer>‘ erhält man durch das Kommando LIST. Besitzt die Nachricht weniger Zeilen, als angefordert wurden, wird der gesamte Inhalt ausgegeben, ohne dass Leerzeilen ergänzt werden.

> top 3 1
< +OK 1111 octets
< Received: from localhost (HELO [127.0.0.1]) [127.0.0.1]
< by pausbacke.hamster.localhost (192.168.0.1) (userid 1)
< with ESMTP (Classic Hamster Version 42.0 Build
  42.0.8.15) ;
< Tue, 20 Apr 2004 20:04:04 +0200
< From: Hamster-Administrator
  <admin@hamster.example.net>
< [weitere Headerzeilen]
< [Leerzeile]
< Du, mein liebster User!
< .

Hier ist „Du, mein liebster User!“ die erste und als einzige auch übertragene Zeile des Bodys.

Manche Server interpretieren dagegen ‚<Zeilen>‘ fälschlicherweise unter Einbeziehung der Header, so dass diese unter Umständen nur zum Teil ausgegeben werden. Bei dem obigen Beispiel mit ‚top 3 1‘ wäre dann nur die erste Headerzeile („Received: [...]“) übertragen worden! Ein weiteres Problem mit diesem Kommando gibt es oft – gerade in der Zusammenarbeit des Hamsters – mit externen Spamfilterprogrammen.

Mit ‚RETR <Nummer>‘ ruft man eine Nachricht immer vollständig ab. An ‚<Nummer>‘ gelangt man durch das Kommando LIST.

> retr 3
< +OK 1111 octets
< Received: from localhost (HELO [127.0.0.1]) [127.0.0.1]
< by pausbacke.hamster.localhost (192.168.0.1) (userid 1)
< with ESMTP (Classic Hamster Version 42.0 Build
  42.0.8.15) ;
< Tue, 20 Apr 2004 20:04:04 +0200
< From: Hamster-Administrator
  <admin@hamster.example.net>
< To: User <user@hamster.example.net>
< [Rest der Nachricht]
< .

Gelöscht werden Nachrichten durch Eingabe von ‚DELE <Nummer>‘. ‚<Nummer>‘ erhält man durch das Kommando LIST.

> dele 3
< +OK message 3 marked for deletion
> dele 5
< +OK message 5 marked for deletion
> list
< +OK 3 messages
< 1 999
< 2 666
< 4 333
< .

Das bewirkt während der Session zunächst nur, dass die durch ‚<Nummer>‘ angegebene Nachricht zum Löschen vorgemerkt wird. Der eigentliche Löschvorgang erfolgt erst, wenn man sich ordnungsgemäß abgemeldet hat (s. u.). Bricht die Verbindung zum Server ab oder schließt man Telnet ohne ordnungsgemäße Abmeldung, bleiben die Nachrichten erhalten. Trotzdem wird man bei den meisten Servern noch während der Session nicht mehr auf die jeweilige Nachricht zugreifen können, d. h. bei allen oben erwähnten Kommandos wird die Nachricht nicht mehr erscheinen bzw. wird der Server eine Fehlermeldung ausgeben.

Will man die Markierung zum Löschen rückgängig machen, muss man das Kommando RSET angeben. Die Markierung wird damit für alle zum Löschen markierten Nachrichten entfernt!

> rset
< +OK mailbox has 5 messages
> list
< +OK 5 messages
< 1 999
< 2 666
< 3 1111
< 4 333
< 5 111
< .

Zum ordnungsgemäßen Verlassen ‚QUIT‘ eingeben:

> quit
< +OK closing connection - goodbye!

Mail versenden mit Telnet

Das zugrundeliegende Protokoll ist SMTP, der Standardport ist 25.

Später wurde das Protokoll erweitert (ESMTP = Extended SMTP), auf dessen Grundlage unter anderem auch die Möglichkeit zur Authentifizierung (SMTP-AUTH) basiert. Die Portnummer hat sich dabei aber nicht verändert. (Viele Server bieten aber zusätzlich auf Port 587 einen Zugang exklusiv per SMTP-AUTH.)

Zur Verbindungsaufnahme also eingeben:

> telnet pausbacke.hamster.localhost 25

Eine positive Antwort sieht z. B. so aus:

< 220 SMTP-Server Classic Hamster Version 42.0 (Build
  42.0.8.15) pausbacke.hamster.localhost is ready.

Meldet sich jetzt nicht der erwartete Mailserver, kann man hier aufhören weiterzulesen und in Abhängigkeit von der Antwort an anderer Stelle nach Lösungen suchen.

Zur Bedeutung der dreistelligen Zahlen (Statuscodes):

1xx	Kommando bis jetzt in Ordnung, erwarte zusätzliche Eingaben, um weitermachen zu können (nur bei ESMTP)
2xx	Kommando in Ordnung
3xx	Kommando bis jetzt in Ordnung, erwarte weitere Eingaben (nur bei Kommandosequenzen)
4xx	temporärer Fehler
5xx	permanenter Fehler

Genaueres s. unter „Servermeldungen bzw. Protokoll-Antwortcodes“ bzw. im RFC 2821.

Übersicht über unten aufgeführte Kommandos:

HELP	Hilfe ausgeben lassen
HELO	Anmeldung nach klassischem SMTP
EHLO	Anmeldung gemäß ESMTP
AUTH	Authentifizierung
MAIL FROM & RCPT TO & DATA	Mail verschicken
QUIT	Ordnungsgemäßes Verlassen

Bei Eingabe von HELP erhält man meist eine Anzeige, welche Kommandos der Server unterstützt.

> help
< 214-Implemented commands follow:
< 214-helo
< 214-ehlo
< […]

Das Kommando muss von allen Servern unterstützt werden, die ausgegebene Liste kann aber auch leer sein!

Nach klassischem SMTP erfolgt die Anmeldung mit ‚HELO <Hostname>‘ (von „Hello“). ‚<Hostname>‘ muss dabei mindestens bei Rechnern, die nicht nur innerhalb eines LAN erreichbar bzw. nicht nur per Telefon an das Internet angebunden sind, ein „Fully Qualified Domain Name“ (FQDN) sein oder wenigstens eine IP-Nummer. Eine Authentifizierung ist nicht erforderlich und standardmäßig auch nicht möglich.

> helo gold.hamster.localhost
< 250 helo gold.hamster.localhost

Von den meisten SMTP-Servern wird aber inzwischen die Anmeldung gemäß ESMTP unterstützt. Dazu ist das Kommando ‚EHLO <Hostname>‘ (von „Extended HELO“) einzugeben.

> ehlo gold.hamster.localhost
< 250-pausbacke.hamster.localhost
< 250-8BITMIME
< 250-AUTH DIGEST-MD5 CRAM-SHA1 CRAM-MD5 LOGIN
< 250-AUTH=DIGEST-MD5 CRAM-SHA1 CRAM-MD5 LOGIN
< 250 HELP

Der Server gibt daraufhin in seiner Antwort – gewöhnlich in mehreren Zeilen – zuerst seinen Domainnamen an und danach bekannt, welche Erweiterungen er unterstützt. Jede Zeile mit Ausnahme der letzten muss so aussehen: ‚250-<unterstützteErweiterung> [optionale Parameter]‘; nur in der letzten Zeile hat statt des ‚-‚ ein Leerzeichen zu stehen (wie auch im Beispiel zu sehen). Ein Server, der keine Erweiterungen besitzt, müsste dem entsprechend so antworten: ‚250 <Servername>‘.

Aufgrund der Spamproblematik muss man sich bei den meisten Servern inzwischen authentifizieren, sonst nehmen sie nur noch Mail für Ihre eigene Domain an (und das zum Teil das auch nur von bestimmten IP-Adressen).

Läuft die Authentifizierung nicht über die per Telefoneinwahl zugewiesene IP-Nummer des eigenen Providers, ist besonders die obige Zeile mit ‚AUTH‘ von Interesse (die zweite Zeile fängt einen Bug in einigen Netscape-Versionen ab). Hier teilt der Server mit, welche Authentifizierungsmechanismen er kennt. Die einfachste ohne SSL angebotene Variante ist ‚LOGIN‘, bei der Username und Passwort base64-kodiert werden, wodurch sie zwar verschleiert, aber auch leicht wieder zu dekodieren sind.

Die anderen Varianten sind für die Arbeit mit Telnet aber nicht praktikabel. So bleibt nur die Authentifizierung durch Eingabe von ‚AUTH LOGIN‘. Man benötigt dafür aber ein externes Tool, das Zeichenketten, hier den Usernamen und das Passwort, base64-kodieren kann, wie beispielsweise UUDeview, den Totalcommander oder etwas Spezielles wie base64.exe.

Achtung: Das Passwort ist leicht zu dekodieren und sollte bei einer Veröffentlichung des Dialogs anonymisiert werden (z. B. durch Sterne).

> auth login
< 334 VXNlcm5hbWU6
[D. h. base64-dekodiert ‚334 Username:‘.]
> dXNlcg==
[D. h. ‚user‘, also verallgemeinert der Username in Base64.]
< 334 UGFzc3dvcmQ6
[D. h. ‚334 Password:‘.]
> Z2VoZWlt
[D. h. ‚geheim‘, also verallgemeinert das Passwort in Base64.]
< 235 Authentication successful.

Um eine Nachricht zu verschicken, muss man folgendermaßen vorgehen:

Zunächst muss man den sogenannten „Envelope“ (Umschlag) angeben (s. u. dazu mehr), nämlich ‚MAIL FROM:‘ für den (wahren) Absender und ‚RCPT TO:‘ für den oder die (wahren) Empfänger, und zwar für jeden Empfänger in einer eigenen Zeile. Das Kommando DATA leitet dann die Eingabe der Nachricht ein. Dann muss mindestens das Headerfeld „From:“ angegeben werden (*), „Subject:“ und „To:“ sind aber auch zu empfehlen bzw. viele Server verlangen die Angabe von „To:“. Alles immer auf eigenen Zeilen eingeben. Anschließend eine Leerzeile einfügen, dann den Text und am Ende einen Punkt auf einer eigenen Zeile eingeben (jede Zeile mit <Return> abschließen). Die Nachricht darf in der unten angegebenen Form nur ASCII-Zeichen enthalten, was für Testmail meistens ausreichen sollte.

(*) Laut RFC 2822 muss „Date:“ ebenso unbedingt angegeben werden, aber das wird üblicherweise ebenso durch die Server gesetzt.

> mail from: User Hase <hase@hamster.localhost>
< 250 OK
> rcpt to: Hamsteradmin <admin@hamster.localhost>
< 250 OK
> rcpt to: User Maus <maus@hamster.localhost>
< 250 OK
> data
< 354 Start mail input; end with <CRLF>.<CRLF>
> from: Hase <hase@example.net>
> to: Goldhamster <goldhamster@example.net>
> subject: Testmail
> [Leerzeile]
> Das ist nur eine Testnachricht.
> Euer Hasilein.
> .
< 250 OK

Am Ende vor dem Punkt auf eigener Zeile nicht noch eine Leerzeile eingeben, das soll laut RFC 2821 unbedingt vermieden werden (ist allerdings bei einer Testnachricht nicht so tragisch).

Bemerkenswert ist in diesem Zusammenhang, dass die in der Nachricht angegebenen Absender- und Empfängeradressen, obwohl sie Pflichtangaben sind, für den Transport keinerlei Bedeutung haben, sondern nur die bei ‚MAIL FROM:‘ und ‚RCPT TO:‘ angegebenen, die bei den meisten Servern nicht in der Nachricht angegeben werden, da sie, wie oben erwähnt, den „Umschlag“ darstellen (Ausnahmen sind solche Angaben wie „X-Envelope-From:“ bzw. „X-Envelope-To:“).

Im obigen Beispiel ist die wahre Absenderadresse deshalb „<hase@hamster.localhost>“, und die Mail geht an „<admin@hamster.localhost>“ und „<maus@hamster.localhost>“, obwohl in „To:“ und „From:“ etwas anderes steht. Bei dem Großteil der Spamflut, die fast jeder von uns erhält, ist das nicht anders.

Zum ordnungsgemäßen Verlassen ‚QUIT‘ eingeben:

> quit
< 221 closing connection - goodbye!