Der übliche Weg, auf E-Mails zuzugreifen besteht darin, MS Outlook zu starten und loszulegen. Oft genug geschieht es aber, daß entweder MS Outlook oder der Webmailer für den E-Mail-Zugang streiken. Ganze Männer möchten manchmal aber auch wissen, wie denn nun eine solche E-Mail genau ausschaut – das ist der Auftritt für Telnet und das POP3-Protokoll…

Von Diensten und Dämonen

Auf dem Server, der unsere E-Mails hortet, läuft entweder ein POP3- oder ein IMAP-Dienst und entsprechend hängt davon auch die zu verwendende Client-Software für den Zugriff ab. Der IMAP-Dienst, oder „Daemon“, wie er auch genannt wird, hält alle E-Mails auf dem Server vor. Wir laden diese also nicht auf unseren Rechner runter und entfernen sie vom Server, sondern nutzen eine Client-Software, wie z.B. das ominöse MS Outlook, um auf die E-Mails zuzugreifen, zu löschen, Ordner anzulegen oder unsere lokale Kopie mit den Inhalten auf dem Server zu synchronisieren. IMAP bietet noch viele weitere Vorteile, auf die wir hier aber nicht eingehen möchten, da dieser Artikel das POP3-Protokoll behandelt.

POP3 – oder: wie man Knochen freilegt

POP3-Server sammeln die E-Mails nur solange, bis sie abgeholt werden. Es ist nicht möglich, auf dem Server Verzeichnisse anzulegen oder die Inhalte mit unserem lokalen E-Mail-Client zu synchronisieren. POP3 ist ein nackter E-Mail-Sammeldienst – mehr nicht.
Für gewöhnlich sind POP3-Daemons darauf konfiguriert, auf Port 110 auf eingehende Verbindungen zu lauschen, Befehle entgegenzunehmen und Rückmeldungen zu geben. Gehen wir doch einmal unter Windows in die Kommandozeile und testen das:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\> telnet pop.irgendeinedomainiminternet.de 110

Wenn wir alles richtig eingegeben haben (ggf. läuft ihr POP3-Daemon nicht auf dem Standardport 110) erhalten wir als Rückmeldung einen gelöschten Bildschirm und in der ersten Zeile einen Befehl, der für unseren hier getesteten POP3-Daemon folgendes meldet:

+OK Hello there.
_

In der letzten Zeile blinkt der Cursor und erwartet unsere Eingabe. Als erstes möchten wir uns authentifizieren und geben folgende Sequenz ein und bestätigen diese:

user 
+OK Password required.

Sie sehen, daß ein korrekt empfangener Befehl mit „+OK“ quittiert wird. Sollte der Befehl dem POP3-Daemon unbekannt sein, so sehen Sie ein „-ERR Invalid command.“ und erhalten den nächsten Versuch, ihm etwas Sinnvolles mitzuteilen.
Ob der Benutzername gültig ist, sehen wir hier aus Sicherheitsgründen nicht. Erst eine Passworteingabe verrät, ob wir erfolgreich sind. Würde ersteres verraten werden, so würden Brute-Force-Attacken auf E-Mail-Accounts viel häufiger auftreten.
Um dem POP3-Daemon das Passwort mitzuteilen, geben wir folgenden Befehl ein:

pass <passwort>
+OK logged in.

Nach dem Einloggen können wir dafür sorgen, daß die Session nicht aufgrund eines Timouts automatisch beendet wird. Versuchen Sie dazu folgendes:

noop
+OK Yup.

Das ist keine Operation, die irgendetwas bewirkt. Sie provoziert nur ein „+OK“ des Servers und sagt ihm, daß wir noch da sind.

Zum Auftakt gönnen wir uns einfach mal eine Übersicht über den Inhalt des Postfachs:

stat
+OK 5 9637

Wir haben also 5 E-Mails im Postfach mit einer Gesamtgröße von 9637 Bytes. Lassen wir uns diese einmal separat auflisten:

list
+OK POP3 clients that break here, they violate STD53.
1 1503
2 1453
3 1420
4 4001
5 1260
.

Die Rückmeldungen der POP3-Daemons sind oftmals sehr salopp gehalten und mehr oder weniger informativ. Wir wollen auf diese jetzt aber nicht eingehen, sondern schauen mal, was wir als Rückmeldung erhalten.

1 1503
2 1453
3 1420
4 4001
5 1260

Die 1. Spalte verrät uns die durchlaufende Nummer, mit der wir die E-Mail gegenüber dem POP3-Daemon referenzieren. Die 2. Spalte enthält die Größe der jeweiligen E-Mail in Bytes, hier also 1503, 1453, 1420, 4001 und 1260 Bytes.

Schauen wir uns einmal den Inhalt der 1. E-Mail an:

[text]retr 1
+OK 1503 octets follow.
Return-Path:
Delivered-To: [email protected]
Received: (qmail 4428 invoked from network); 28 Oct 2006 21:39:13 +0200
Received: from bay105-f20.bay105.hotmail.com (HELO hotmail.com) (65.54.224.30)
by pxxxxxxxx.pureserver.info with SMTP; 28 Oct 2006 21:39:13 +0200
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Sat, 28 Oct 2006 12:39:12 -0700
Message-ID:
Received: from 65.54.224.200 by by105fd.bay105.hotmail.msn.com with HTTP;
Sat, 28 Oct 2006 19:39:12 GMT
X-Originating-IP: [76.23.102.211]
X-Originating-Email: [[email protected]]
X-Sender: [email protected]
From: „John Doe“
To: [email protected]
Bcc:
Subject: Mein E-Mail-Betreff
Date: Sat, 28 Oct 2006 21:39:12 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 28 Oct 2006 19:39:12.0297 (UTC) FILETIME=[BE7E0190:01C6FAC8]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on
p15183134.pureserver.info
X-Spam-Level:
X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER
autolearn=no version=2.64

Hallo,

dies ist eine Test-E-Mail, um den direkten Zugriff auf E-Mails per POP3 zu
veranschaulichen.

Mfg, John Doe[/text]

Hier sehen wir jetzt die E-Mail in ihrer rohesten und ursprünglichsten Form (selbstverständlich ohne Zeilennummern, die wurden hier der Lesbarkeit halber eingefügt), wie sie auf dem Server vorliegt – inkl. den sogenannten Headern, die von MS Outlook & Co. geparst und an den entsprechenden Stellen in der Oberfläche angezeigt werden. Wie man sehen kann, ist auf dem Server Spamassassin installiert, der seine Spam-Tests über die E-Mail hat laufen lassen und ihr einen Wert von 0.8 zugewiesen hat – kein SPAM, da die Toleranz in dieser Konfiguration bei 5.0 Punkten liegt.

Zu den wichtigsten Headern gehören:

[text]Return-Path:
Delivered-To: [email protected]
X-Originating-IP: [76.23.102.211]
X-Originating-Email: [[email protected]]
X-Sender: [email protected]
From: „John Doe“
To: [email protected]
Bcc:
Subject: Mein E-Mail-Betreff
Date: Sat, 28 Oct 2006 21:39:12 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed[/text]

Über diese Header lässt sich der Absender identifizieren (so denn er nicht von einem Spammer gefälscht wurde), der Betreff auslesen und die IP-Adresse des Senders überprüfen. Der Content-Type zeigt hier an, daß die E-Mail im Textformat vorliegt, also keine HTML-Codes ausgelesen und für die Anzeige ausgewertet werden müssen.

Die Ausgabe begrenzen – oder: mehr Kontrolle bitte

Wenn wir uns die 4. E-Mail mit gerade einmal 4001 Bytes anzeigen lassen, sehen wir, daß sich der Bildschirm ganz schnell mit Headerinformationen und dem gesamten Body der E-Mail füllt, der uns aber eigentlich gar nicht interessiert. Was, wenn die E-Mail 20 KB groß wäre? Dann müssten wir hochscrollen, um über die Header sehen zu können, von wem die E-Mail eigentlich stammt. Versuchen wir also mal, die Ausgabe der 1. E-Mail zu begrenzen:

[text]top 1 0
+OK headers follow.
Return-Path:
Delivered-To: [email protected]
Received: (qmail 4428 invoked from network); 28 Oct 2006 21:39:13 +0200
Received: from bay105-f20.bay105.hotmail.com (HELO hotmail.com) (65.54.224.30)
by pxxxxxxxx.pureserver.info with SMTP; 28 Oct 2006 21:39:13 +0200
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Sat, 28 Oct 2006 12:39:12 -0700
Message-ID:
Received: from 65.54.224.200 by by105fd.bay105.hotmail.msn.com with HTTP;
Sat, 28 Oct 2006 19:39:12 GMT
X-Originating-IP: [76.23.102.211]
X-Originating-Email: [[email protected]]
X-Sender: [email protected]
From: „John Doe“
To: [email protected]
Bcc:
Subject: Mein E-Mail-Betreff
Date: Sat, 28 Oct 2006 21:39:12 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 28 Oct 2006 19:39:12.0297 (UTC) FILETIME=[BE7E0190:01C6FAC8]
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on
p15183134.pureserver.info
X-Spam-Level:
X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER
autolearn=no version=2.64

.[/text]

Wie Sie sehen, werden uns nur die Header zurückgeliefert. Mit dem Befehl „top 1 0“ lassen wir uns von der 1. E-Mail alle Header, aber nicht den eigentlichen Inhalt der E-Mail, anzeigen.
Mit „top 1 12“ können wir uns entsprechend alle Header und die ersten 12 Zeilen des Inhalts anzeigen lassen:

[text]top 1 12
+OK headers follow.
Return-Path:
Delivered-To: [email protected]
… etc. pp.
[/text]

E-Mails löschen

Enttäuscht stellen wir fest, daß sich die Hälfte der E-Mails mit der Verlängerung unserer relevanten Organe beschäftigen (Betreff: „Barbara, get your risk-free penis enlargement“) und so tippen wir beherzt folgende Befehle ein:

dele 3
+OK Deleted.
dele 4
+OK Deleted.

Die E-Mails Nr. 3 und 4 wurden jetzt zwar gelöscht… aber was sehen unsere müden Augen da?

list
+OK POP3 clients that break here, they violate STD53.
1 1503
2 1453
5 1260
.

Wo ist die fortlaufende Nummerierung der E-Mails hin?
Ganz einfach: die E-Mails sind als „zu löschen“ notiert und werden nicht mehr angezeigt. Tatsächlich gelöscht werden sie aber erst, wenn wir uns per…

quit
+OK Bye-bye.

… ausloggen. Bis dahin werden sie einfach aus der Listenansicht ausgespart. Durch die Sprünge in der Nummerierung sehen wir, daß E-Mails zum Löschen markiert worden sind.

Wenn wir aber vor dem Ausloggen parallel eine zweite Verbindung zum POP3-Daemon aufbauen und uns den Inhalt des Postfachs anzeigen lassen, sehen wir noch alle 5 E-Mails. Die Löschung und Entfernung aus der Anzeige gilt also nur für die 1. Session und die physikalischen Löschungen werden erst vorgenommen, wenn wir die diese 1. Session beendet haben. Bis dahin befinden wir uns in der transaction phase und das Postfach ist für Modifikationen durch parallele Sessions gesperrt.

Nervöser Zeigefinger?

Jetzt haben Sie doch glatt aus Versehen mit „dele“ alle E-Mails zum Löschen vorgemerkt und trauen sich nicht mehr, sich auszuloggen? Sehen Sie sich schon die ganze Nacht lang am Rechner „noop“ eingeben, damit die Session nicht automatisch beendet wird? Keine Sorge, auch das lässt sich lösen:

rset
+OK Resurrected.

Damit wird auf dem Server ein Reset durchgeführt und das Löschen zum Löschen vorgemerkter E-Mails verhindert.

Die Idee mit dem POP3-Client…

… ist Ihnen spätestens jetzt gekommen! Die hier genannten Befehle reichen aus, um mit einer beliebigen, netzwerkfähigen Programmiersprache in wenigen Zeilen Code einen eigenen, rudimentären (lesenden) E-Mail-Client zu implementieren. Wer das jetzt tun möchte, sollte aber wissen, daß zumindest die gebräuchlicheren Programmiersprachen (Java, PHP etc.) diese Funktionen bereits über Standardlibraries bereitstellen…

Weitere Informationen

Die genaue Beschreibung des POP3-Protokolls findet sich im RFC1939.

Wenn Sie Bücher zu dem Thema suchen empfiehlt sich ein Klassiker der deutschen Computerliteratur: „Internet intern“ von Data Becker aus dem Jahre 2000. Das Buch ist zwar etwas veraltet und bei weitem nicht mehr auf dem neusten Stand, aber leider das einzige, das ich zu diesem Thema im Bücherregal stehen habe und empfehlen kann.

1 Kommentar

E-Mails lesen über Telnet und POP3 « Ihnocent
Sep 8, 2010 15:39

Weitere Empfehlungen: