IMAP. Internet Message Access Protocol IMAP

Transkript

1 IMAP Internet Message Access Protocol Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN Der -Dienst funktioniert ähnlich wie der klassische, uns gut bekannte Briefpostdienst. Zuerst übergibt ein Absender eine zu verschickende mithilfe des Simple Mail Transfer Protocol (SMTP) an einen Ausgangs-Mailserver, was mit der Übergabe eines Briefes an eine Poststelle vergleichbar ist. Daraufhin wird die Nachricht zum Eingangs-Mailserver des Empfängers transportiert. Hat die den Eingangs-Mailserver erreicht, wird sie dort in der einem Postfach entsprechenden Mailbox des Empfängers gespeichert. Danach muss der Rechner des Empfängers die Nachricht selbst abrufen. Zu diesem Zweck kann das Protokoll IMAP eingesetzt werden. IMAP ist also ein -Abrufprotokoll. Seine aktuelle Version ist IMAP4. IMAP4 ist ein Protokoll für den Zugriff auf Mailboxen im Mailserver. Bei IMAP4 können auf einem Mailserver mehrere Mailboxen auch als Ordner bezeichnet eingerichtet werden. Sie können sogar eine hierarchische Struktur bilden. Der Rechner eines Benutzers kann IMAP4 nicht nur verwenden, um die empfangenen und in den Mailboxen eines Benutzers auf dem Mailserver gespeicherten E- Mails abzurufen, sondern und im Gegensatz zum - Abrufprotokoll POP3 1 auch dazu, um sie dort zu belassen, zu bearbeiten und zu verwalten, als ob sie sich auf seinem Rechner befänden. Weil ungelöschte s bei IMAP4 dauerhaft auf dem Mailserver gespeichert bleiben, ist dieses Protokoll besonders denjenigen Benutzern von Nutzen, die oft unterwegs sind und von verschiedenen Rechnern aus Zugriff auf ihre s haben müssen. IMAP wurde 1986 an der Stanford University in Kalifornien entworfen und damals noch als Interactive Message Access Protocol bezeichnet. Diese Version von IMAP wurde erweitert und im Juli 1988 als Version 2 des IMAP kurz IMAP2 in RFC 1064 veröffentlicht. Die Spezifikation von IMAP2 wurde kurze Zeit später aber modifiziert, sodass bereits im August 1990 RFC 1064 durch RFC Post Office Protocol Version 3 1

2 abgelöst wurde. In der Zwischenzeit wurde IMAP2 weiterentwickelt und die, als IMAP3 bezeichnete, dritte Version des Protokolls in RFC 1203 (Februar 1991) spezifiziert. Daraufhin wurde RFC 1176 durch RFC 1203 abgelöst. Die erste Fassung der aktuellen Version von IMAP heute als Internet Message Access Protocol Version 4 (IMAP4) bezeichnet wurde (im Dezember 1994) in RFC 1730 spezifiziert. Zeitgleich wurde in RFC 1731 auch das Prinzip der Authentifizierung bei IMAP4 veröffentlicht. Danach wurde IMAP4 weiter modifiziert und (im Dezember 1996) als IMAP4rev1 in RFC 2060 spezifiziert. Im März 2003 wurde RFC 2060 durch RFC 3501 abgelöst. Die heute geltende Spezifikation des IMAP4rev1 ist in RFC 3501 enthalten. Die in den letzten Jahren steigenden Anforderungen an die Verwaltung und die Archivierung von s in Unternehmen und in öffentlichen Einrichtungen haben dazu geführt, dass der Kern von IMAP4 ständig weiterentwickelt wurde. Aus diesem Grund wurde die heute verbindliche Spezifikation des eigentlichen Protokolls IMAP4 in RFC 3501 durch mehrere, in verschiedenen RFCs beschriebene Lösungen ergänzt. RFC 3501 wird deshalb durch RFCs u.a. mit den Nummern 4466, 4469, 4551, 5032, 5182 und 5738 erweitert. Um die Funktionalität von IMAP4 erweitern zu können, ohne seinen Kern modifizieren zu müssen, wurde das Konzept der sog. IMAP- Extensions 2 eingeführt. Diese werden in mehreren RFCs, wie z.b. RFC 2195, RFC 4467, RFC 4978 und RFC 5161, veröffentlicht. Bedeutung von IMAP4 Bild 1 zeigt, welche Systemkomponenten und Protokolle bei der Übermittlung einer über das Internet im hier gezeigten Beispiel vom Absender Alice zum Empfänger Bob beteiligt sind. Das -Konzept im Internet basiert darauf, dass in jeder der beiden beteiligten Internetdomains, in diesem Fall abc.de und xyz.de, ein spezieller Server ein sog. Mailserver, auch - 2 Es handelt sich hierbei im Grunde um das gleiche Extensions-Konzept wie bei den -Protokollen SMTP und POP3. 2

3 Server genannt eingerichtet wird. Den Mailserver könnte man mit einer Poststelle innerhalb eines Postleitzahlgebiets vergleichen. Demzufolge würde eine Internetdomain einem Postleitzahlgebiet beim Briefdienst entsprechen. Bild 1: Illustration der Aufgabe von IMAP4 SMTP: Simple Mail Transfer Protocol IMAP4 ermöglicht dem Benutzer, von einem beliebigen Rechner 3 auf seine persönliche Mailbox auf dem Mailserver zuzugreifen, um seine s abzurufen. Weil die s bei IMAP4 auch auf dem Mailserver verbleiben können, ermöglicht IMAP4 im Gegensatz zu seinem Bruder POP3 ebenso die Bearbeitung und Verwaltung von s auf dem Mailserver. Besonderheiten von IMAP4 Hervorzuheben sind die folgenden Besonderheiten von IMAP4: Client-Server-Protokoll IMAP4 funktioniert nach dem Client-Server-Prinzip (vgl. Bild 1). Ein IMAP4-Client stellt eine Softwareinstanz auf dem Rechner des Benutzers dar. Diese ist nicht nur für den Abruf von E- Mails aus dem Mailserver zuständig, sondern auch für die Verwaltung von s auf dem Mailserver. Die Funktion eines IMAP4-Clients wird von einem -Editor, z.b. Microsoft Outlook, Mozilla Thunderbird, Gnus oder Alpine, unterstützt und 3 Dies ist möglich, weil auf die IMAP4-Funktionen und demzufolge auch auf eine Mailbox auf dem Mailserver über einen Webbrowser zugegriffen werden kann. 3

4 kann auch von einem Webbrowser in Anspruch genommen werden. Eine Softwareinstanz auf einem Mailserver, die als Kommunikationspartner des IMAP4-Clients dient, stellt einen IMAP4-Server dar. IMAP4 over TCP IMAP4 verwendet das verbindungsorientierte Transportprotokoll TCP 4. Der Well Known Port (WKP) von IMAP4 ist 143 der WKP der Version 3 von IMAP (IMAP3) ist aber 220. IMAP4 over TLS Um einen gesicherten Abruf von s zu garantieren, kann IMAP4 das Sicherheitsprotokoll TLS nutzen. 5 Man spricht in diesem Fall von IMAP4 over TLS oder von IMAPS (Secure IMAP oder auch Secure IMAP4). Der Well Known Port von IMAPS ist 993. Commands und Responses Bei IMAP4 sendet der Client Befehle sog. Commands an den Server und dieser übermittelt ihm Responses als Antworten auf die Commands. Mit einem sog. Status Response wie z.b. OK, NO, BAD informiert der Server den Client über den Status der Ausführung eines Command. Textbasiertes Protokoll Bei IMAP4 genauso wie beim -Abholprotokoll POP3 werden alle Commands des Clients und alle Responses des Servers als lesbare Zeichenketten zeilenweise, wie ein Text geschrieben. Jeder Command und jeder Response muss am Ende mit dem Zeichen CRLF (Carriage Return and Line Feed) abgeschlossen werden, was einem Druck auf die Taste ENTER entspricht. Das Zeichen CRLF darf daher weder innerhalb eines Command noch innerhalb eines Response vorkommen. 4 Transmission Control Protocol 5 Die Version 1.0 von Transport Layer Security (TLS) in RFC 2246 (1999) spezifiziert entspricht weitgehend der Version 3.0 des von der Firma Netscape entwickelten Sicherheitsprotokolls SSL (Secure Socket Layer). Daher spricht man auch vom IMAP4 over SSL. 4

5 Schreibweise von Commands Für die Spezifikation von Commands verwendet man einen Command-Code, wie z.b. LOGIN, SELECT und CREATE. Nach einem Command-Code können einige Parameter folgen. Jedem Command wird ein sog. Tag als seine Identifikation (ID), wie z.b. A001, A002 vorangestellt. Demzufolge kann eine einen Command beinhaltende Zeile folgende Struktur haben: <ID> <Command-Code> <Parameters> <CRLF> <CRLF> symbolisiert das Drücken der ENTER-Taste. Der Server (S:) antwortet auf einen Command des Clients (C:) mit der Angabe von dessen Identifikation, wie z.b. C: A001 LOGIN Mustermann Passwort S: A001 OK LOGIN completed Zustandsorientiertes Protokoll Während der Kommunikation zwischen Client und Server sind mehrere Phasen zu unterscheiden. Man bezeichnet sie als Zustände von IMAP4. Demzufolge ist IMAP4 ein zustandsorientiertes Protokoll. Bild 2 illustriert dies. Die Commands bei IMAP4 sind von seinem Zustand abhängig, d.h. in jedem Zustand können seitens des Clients nur bestimmte Commands gesendet werden. Daher spricht man z.b. von Commands im Zustand Authenticated oder von Commands im Zustand Selected. Einige Commands, die sog. Any State Commands, können jedoch in allen Zuständen gesendet werden. Erweiterungen von IMAP4 IMAP4-Extensions Um den Kern von IMAP4 einfach zu gestalten, wurden und werden die Erweiterungen sog. Extensions für IMAP4 auf eine einheitliche Weise nach den in RFC 3501 dargestellten Prinzipien spezifiziert. Eine Extension stellt in der Regel eine zusätzliche IMAP4-Funktion als Capability bezeichnet dar. Jede Capability hat einen Namen. Der Client kann den Server mit dem Command CAPABILITY auffordern, ihm seine Capabilities, also seine Fähigkeiten, mitzuteilen. Auf diese Weise erfährt er, welche Funktionen er beim Server in Anspruch nehmen kann. IMAP4-Erweiterung STARTTLS IMAP4 over TLS Um den gesicherten Abruf von s zu garantieren, kann IMAP4 genau wie die -Protokolle SMTP und POP3 das Sicherheitsprotokoll TLS nutzen. Dies kann mithilfe der in RFC 2595 spezifizierten IMAP4-Extension STARTTLS erfolgen. 5

6 Zustandsmodell von IMAP4 Wie bereits erwähnt wurde, ist IMAP4 ein zustandsorientiertes Protokoll. In dessen Verlauf sind fünf IMAP4-Zustände zu unterscheiden. In jedem Zustand kann der Client dem Server nur bestimmte Commands senden. Die Zustände von IMAP4 und die Übergänge zwischen ihnen lassen sich als IMAP4- Zustandsdiagramm darstellen, hier durch Bild 2 illustriert. Weil IMAP4 das verbindungsorientierte Transportprotokoll TCP nutzt, muss zwischen Client und Server zuerst eine TCP-Verbindung aufgebaut und diese nach dem Ablauf der Kommunikation zwischen ihnen auch wieder abgebaut werden. Bild 2: Zustände im IMAP4-Verlauf (IMAP4-Zustandsdiagramm) Die einzelnen Zustände von IMAP4 sind: Server greeting die Begrüßung seitens des Servers In diesem Zustand, der nach dem Aufbau einer TCP-Verbindung zwischen Client und Server beginnt, wird der Client, falls er nicht authentifiziert ist, vom Server mit OK dazu aufgefordert, seine Identität vorzuweisen, und IMAP4 geht in den Zustand No Authenticated über, oder, falls er bereits (auf eine andere Weise) authentifiziert worden ist, vom Server mit PREAUTH darüber informiert, dass er bereits eine Mailbox auswählen kann, 6

7 woraufhin der Übergang in den Zustand Authenticated erfolgt. Der Server kann auch aus irgendeinem Grund den Client mittels BYE dazu veranlassen, die TCP-Verbindung abzubauen; daraufhin geht IMAP4 in den Zustand Logout über. Not Authenticated Identität des Clients wird überprüft Während dieses Zustands überprüft der Server die Identität des Clients. Ist sie korrekt, dann ist die Authentifizierung erfolgreich und IMAP4 geht in den Zustand Authenticated über. Ist die Identität des Clients aber nicht korrekt, erfolgt der Übergang in den Zustand Logout. Im Zustand Not Authenticated kann der Client nur einige Commands, wie z.b. LOGIN und AUTHENTICATE bzw. STARTLS, senden. Authenticated der Client kann eine Mailbox auswählen Dieser Zustand beginnt nach einer erfolgreichen Authentifizierung des Clients. Während dieses Zustands kann der Client u.a. eine Mailbox mit dem Command SELECT auswählen bzw. eine neue mit CREATE einrichten. Selected der Client verwaltet Mailbox(en) Nachdem der Client z.b. mit dem Command SELECT eine Mailbox ausgewählt hat, geht IMAP4 in den Zustand Selected über, in dem der Client verschiedene Operationen durchführen kann, wie z.b. mit CLOSE die ausgewählte Mailbox schließen, zum Zustand Authenticated übergehen und danach eine neue Mailbox auswählen, mit SEARCH nach bestimmten s suchen, mit DELETE eine Mailbox löschen bzw. mit COPY s in eine andere Mailbox kopieren. Logout Übergang zum Abbau der TCP-Verbindung Den Übergang zum Zustand Logout initiiert der Client mit dem Command LOGOUT bzw. der Server mit BYE. Im Zustand Logout können Client und Server eventuell noch anstehende Änderungen ausführen, bevor sie mit dem Abbau der zwischen ihnen bestehenden TCP-Verbindung beginnen. 7

8 Status Responses bei IMAP4 Ein Server kann als Antwort auf einen Command vom Client einen Status Response mit der Information über den Status der Ausführung eines Command senden. 6 Mögliche Responses sind: OK positive Antwort Der Server signalisiert dem Client mit OK, dass ein Command fehlerfrei von ihm ausgeführt wurde. Ein Response OK kann auch einen Text als zusätzliche Information über die Art und Weise der Command-Ausführung enthalten, wie z.b. A001 OK LOGIN completed NO negative Antwort Mit dem Response NO wird der Client darüber informiert, dass ein Command nicht ausgeführt werden konnte, dass z.b. bei der Ausführung eine fehlerhafte Situation aufgetreten ist. BAD Fehlermeldung Mit dem Response BAD wird der Client darüber informiert, dass ein Protokollfehler aufgetreten ist, dass z.b. der Command oder die Syntax nicht korrekt ist. PREAUTH keine Authentifizierung nötig Mit PREAUTH wird dem Client im Zustand Server greeting angezeigt, dass keine Authentifizierung nötig ist. IMAP4 geht dann direkt in den Zustand Authenticated über (vgl. Bild 2). BYE Tschüss und Abbruch der Verbindung Mit einem Response BYE wird der Client aufgefordert, die bestehende Verbindung zu beenden. IMAP4 geht dann in den Zustand Logout über. 6 Der Client vergibt an die gesendeten Commands eine eindeutige Identifikation, z.b. A001, A002. Eine solche wird auch Tag genannt. Der Server stellt jedem Response die Identifikation eines Command voran und klärt auf diese Weise, auf welchen Command sich der Response bezieht. Ein Response kann auch mit dem Symbol * beginnen also untagged und ohne Bezug auf einen Command sein. 8

9 Ein Status Response kann optional in Klammern [...] einen sog. Response Code, wie z.b. ALERT, READ-ONLY und CHARSET, enthalten. Die Status Responses PREAUTH und BYE sind immer untagged, d.h. ohne Bezug auf einen Command, und beginnen mit dem Symbol *. Jeder IMAP4-Respsonse wird mit dem Symbol <CRLF> also mit dem Drücken der ENTER-Taste beendet. Beispiel: Nach dem Aufbau einer TCP-Verbindung signalisiert der Server mit dem untagged Response *OK wie folgt seine Bereitschaft zu kommunizieren: S: * OK IMAP4 server ready C: A001 LOGIN alex mustermann <password> S: * OK IMAP4 [ALERT] system shutdown in 10 minutes A001 OK LOGIN completed Typischer Verlauf des Mail-Abrufs mit IMAP4 Für den Abruf von s mit IMAP4 wird das verbindungsorientierte TCP verwendet. Dadurch wird eine zuverlässige Übermittlung von s garantiert. Bild 3 veranschaulicht einen typischen Verlauf des Abrufs von s mit IMAP4. Bild 3: Beispiel für einen Verlauf des Mail-Abrufs mit IMAP4 typische Schritte Beim hier gezeigten Verlauf des Mail-Abrufs mit IMAP4 sind folgende Schritte zu unterscheiden: 9

10 1. Der Client initiiert den Aufbau einer TCP-Verbindung, um neue s vom Server abzurufen. 2. Der Server signalisiert seine Kommunikationsbereitschaft. Da der Client noch nicht authentifiziert ist, wird er mit *OK dazu aufgefordert, seine Identität vorzuweisen. 3. Die Authentifizierung des Clients. Der Client übermittelt im Command LOGIN seinen Namen und das Passwort. Der Server bestätigt LOGIN mit OK 7, z.b. C: A001 LOGIN bob mustermann <password> S: A001 OK LOGIN completed 4. Der Client wählt eine Mailbox aus. Hierfür sendet er den Command SELET mit dem Mailboxnamen bobmailbox und der Server übermittelt ihm den Status der ausgewählten Mailbox wie folgt C: A002 SELECT INBOX S: * 5 EXISTS * 2 RECENT * OK [UNSEEN 4] Message 4 is first unseen * OK [UIDVALIDITY ] UIDs valid * FLAGS (\Answered \Seen \Unseen \Deleted \Flagged \Draft) A002 OK SELECT completed SELECT-Response: In der Mailbox (INBOX) befinden sich 5 s (5 EXISTS), davon 2 neue, noch ungesehene (2 RECENT); die erste ungesehene Mail hat die Sequenznummer 4 (UNSEEN 4). Die UID-Gültigkeitsnummer (Unique Identifier Validity Number) als Parameter UIDVALIDITY ist Der Status jeder kann in diesem Fall mit den folgenden Flags gekennzeichnet werden: Answered (beantwortet), Unseen (ungesehen), Seen (gesehen), Deleted (gelöscht), Flagged (markiert) und Draft (Entwurf). 7 Es sei hervorgehoben, dass die Angaben in LOGIN im Klartext also unverschlüsselt übermittelt werden. Es handelt sich hier also um eine ungesicherte Authentifizierung. 8 Auf die Bedeutung von UIDVALIDITY wird im Weiteren näher eingegangen siehe: Identifikation von s in einer Mailbox. 10

11 5. Der Client ruft (in der Regel zuerst nur) die Headers der beiden neuen s ab. Um die Herkunft und den Betreff der neuen s abzulesen, sendet er den Command FETCH mit der Angabe der Sequenznummern 4 und 5 (als Bereich 4:5): C: A003 FETCH 4:5 RFC822.HEADER 9 S: * 4 FETCH (RFC822.HEADER {1254} Received: from msrv.abc.de ([ ]) From: Alice Musterfrau <alice@abc.de> To: Bob Mustermann <bob@xyz.de> Subject: Viele Gruesse ) A003 OK Fetch completed * 5 FETCH (RFC822.HEADER {948} Der Header der zweiten neuen ) A003 OK FETCH completed FETCH-Response: Die Header der s mit den Sequenznummern 4 und 5 werden hintereinander, getrennt in zwei FETCH-Responses, die untagged (*) sind, übermittelt. Jedem von beiden wird die Sequenznummer der betreffenden vorangestellt. Der Inhalt des FETCH-Response als Serverdaten wird mit runden Klammern ( und ) markiert. Die abschließende Klammer ) verweist auf das Ende des Inhaltes 10 hier des übermittelten Headers. Am Anfang von Serverdaten wird angegeben, welcher - Teil transportiert wird (hier RFC822.HEADER) und wie groß (in Bytes) er ist. 9 Die Struktur des Header in s legt RFC 822 fest. Mit der Angabe RFC822.HEADER in der Zeile mit FETCH wird darauf verwiesen, dass es sich um Header nach RFC 822 handelt. 10 Anders als bei IMAP4 wird bei den -Protokollen SMTP und POP3 auf das Ende der übermittelten mit der Folge <CRLF>.<CRLF> verwiesen also der Kombination ENTER-Taste, Punkt, ENTER-Taste. 11

12 6. Der Client löscht die erste neue . Durch das Absenden von STORE ändert er zuerst den Status der ersten neuen mit der Sequenznummer 4 auf deleted. Auf diese Weise wird sie zum Löschen vorbereitet. Anschließend wird der Command EXPUNGE gesendet, um das endgültige Löschen einzuleiten: C: A004 STORE 4 FLAGS \DELETED S: * 4 FETCH (FLAGS (\Deleted)) A004 OK Store completed C: A005 EXPUNGE S: * 1 EXPUNGE A005 OK EXPUNGE completed Bemerkung: Das Löschen einer in zwei Schritten hat den Vorteil, dass eine aus Versehen als deleted markierte noch gerettet werden kann; deren Status kann z.b. mit dem Command STORE von deleted auf seen gesetzt werden. 7. Der Client ruft die zweite neue ab. Hierfür sendet er den Command FETCH mit der Sequenznummer 4 11 dieser C: A006 FETCH 4 RFC822 S: * 4 FETCH (RFC822 {10135} Die zweite neue ) A006 OK FETCH completed FETCH-Response: Dieser enthält in den Klammern ( und ) die übermittelte ; sie ist Bytes lang. 8. Der Client meldet sich beim Server ab. Dies erfolgt durch das Absenden des Command LOGOUT. Der Server antwortet darauf mit dem BYE-Response: C: A007 LOGOUT S: * BYE Logging out A007 OK LOGOUT completed 9. Nach dem Abmelden des Clients beim Server wird die noch bestehende TCP-Verbindung abgebaut. 11 Nach dem Löschen der mit der Sequenznummer 4 springt die Sequenznummer der nächsten von 5 auf 4. 12

13 Für die Fortsetzung siehe: Fachkompendium Protokolle und Dienste der Informationstechnologie, WEKA-Verlag, ISBN-13: