Internet Message Access Protocol

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von IMAP4)
Zur Navigation springen Zur Suche springen
IMAP und Imap sind Weiterleitungen auf diesen Artikel. Weitere Bedeutungen sind unter IMAP (Begriffsklärung) aufgeführt.
Internet Message Access Protocol
Familie: Internetprotokollfamilie
Einsatzgebiet: Lesen und Verwalten von E-Mails
Ports: 143/TCP[1]
993/TCP (nur mit TLS)
IMAP im TCP/IP-Protokollstapel:
Anwendung IMAP
Transport TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus 		Token
Ring 		FDDI …
Standard: RFC 9051[2]

Das Internet Message Access Protocol (IMAP), ursprünglich Interactive Mail Access Protocol, ist ein Netzwerkprotokoll, das ein Netzwerkdateisystem für E-Mails bereitstellt.

IMAP wurde in den 1980er Jahren mit dem Aufkommen von Personal Computern entworfen, um bei der Mail-Kommunikation Abhängigkeiten von einzelnen Client-Rechnern aufzulösen.[3] Zu diesem Zweck erweitert IMAP die Funktionen und Verfahren des Post Office Protocol (POP) so, dass Benutzer ihre Mails, Ordnerstrukturen und Einstellungen auf den (Mail-)Servern speichern und belassen können. Während bei der Verwendung von POP die Nachrichten entweder nach dem Abruf gelöscht oder beim nächsten Abruf erneut empfangen werden, ermöglicht IMAP eine zentrale Verwaltung mit Suchfunktion und serverseitiger „Gelesen“-Markierung.

Das Simple Mail Access Protocol (SMAP) ist ein Ansatz, die Funktionalität von IMAP mit dem Simple Mail Transfer Protocol (SMTP) zu vereinen, das ansonsten zum Senden von E-Mails erforderlich bleibt.

Protokolleigenschaften

[Bearbeiten | Quelltext bearbeiten]

IMAP ist ein textbasiertes Protokoll zum Zugriff auf E-Mails, die sich auf einem Mailserver befinden. Ein Mail-Client stellt Anfragen an den Server nur nach aktuell benötigten Informationen. Möchte ein Nutzer z. B. den Inhalt eines Ordners sehen, holt sich der Client eine aktuelle Nachrichtenliste des betreffenden Ordners vom Server. Soll der Inhalt einer Mail angezeigt werden, wird dieser vom Server geladen. Da alle Daten weiterhin auf dem Server verbleiben, zeigen – auch bei der Benutzung von mehreren Clients – alle den gleichen, aktuellen Datenbestand einer Mailbox an. Zudem wird eine lokale Speicherung der Daten unnötig und erweiterte Möglichkeiten wie das Durchsuchen von Mails werden serverseitig durchgeführt.

Mit IMAP ist auch der Zugriff auf verschiedene Ordner innerhalb einer Mailbox möglich. Viele Server können eingehende Mails auch direkt in verschiedene Ordner einsortieren (filtern). Durch das Setzen von Zugriffsrechten für Ordner einer Mailbox können auch mehrere Benutzer gleichzeitig auf dieselben Daten zugreifen. Die Erweiterung IMAP IDLE ermöglicht eine sofortige Benachrichtigung an Clients (pushing), wenn eine neue Mail eintrifft. So wird unnötiger Datenverkehr vermieden, der bei ständigen Anfragen (polling) eines Clients anfallen würde. Verfügt man über keine Internetverbindung zu seinem Mailserver, ist in der Regel auch kein Zugriff mehr auf die Mails möglich. Einige Clients lösen dieses Problem, indem sie lokale Kopien der Mails anlegen, auf die sie im Offline-Modus zurückgreifen können. Bei wiederhergestellter Internetverbindung werden die Daten wieder mit dem Mailserver abgeglichen (synchronisiert).

Wegen der zentralen Speicherung der Daten auf einem externen Server muss auch der eigene Datenschutz berücksichtigt werden. Die Verbindung zum Server sollte deshalb verschlüsselt werden.

Beispiel einer IMAP-Sitzung (IMAP4rev1-Beispiel aus RFC 3501, 8. Kapitel[4] – gekürzt):

Client Server Erklärung
* OK IMAP4rev1 Service Ready Server begrüßt den Client
a001 login mrc secret Client meldet sich an
a001 OK LOGIN completed Server bestätigt Anmeldung
a002 select inbox Client wählt inbox als aktiven Ordner
* 18 EXISTS

* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* 2 RECENT
* OK [UNSEEN 17] Message 17 is the first unseen message
a002 OK [READ-WRITE] SELECT completed

18 Mails vorhanden

definierte Flags
2 dringliche Mails (z. B. neue Mails)
Mail Nr. 17 ist ungelesen. Alle älteren wurden bereits gelesen.
Client darf Änderungen an Mails durchführen

a003 fetch 12 full Client fordert Infos zu Mail Nr. 12
* 12 FETCH (FLAGS (\Seen)
INTERNALDATE „17-Jul-1996 02:44:25 -0700“
RFC822.SIZE 4286
ENVELOPE („Wed, 17 Jul 1996 02:23:25 -0700 (PDT)“
„IMAP4rev1 WG mtg summary and minutes“
((„Terry Gray“ NIL „gray“ „cac.washington.edu“))
((„Terry Gray“ NIL „gray“ „cac.washington.edu“))
((„Terry Gray“ NIL „gray“ „cac.washington.edu“))
((NIL NIL „imap“ „cac.washington.edu“))
((„John Klensin“ NIL „KLENSIN“ „MIT.EDU“))
NIL NIL
„<B27397-0100000@cac.washington.edu>“)
BODY („TEXT“ „PLAIN“ („CHARSET“ „US-ASCII“) NIL NIL „7BIT“ 302892))

a003 OK FETCH completed

Mail wurde bereits gelesen

am 17. Juli 1996 zugestellt
über 4 kB groß
Mail-Header:

Datum
Betreff
Absender (From)
Absender (Sender)
Antwort-an
Empfänger (To)
Kopie-Empfänger (CC)
BCC und In-Reply-To nicht angegeben
Message-ID
a004 fetch 12 body[header] Client möchte alle Header zu Mail Nr. 12
* 12 FETCH (BODY[HEADER] {342}
Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
From: Terry Gray <gray@cac.washington.edu>
Subject: IMAP4rev1 WG mtg summary and minutes
To: imap@cac.washington.edu
cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
Message-Id: <B27397-0100000@cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
)

a004 OK FETCH completed

Server sendet geforderte Mailheader
a005 store 12 +flags \deleted Mail Nr. 12 als gelöscht markieren
* 12 FETCH (FLAGS (\Seen \Deleted))

a005 OK +FLAGS completed

a006 logout Client meldet sich ab
* BYE IMAP4rev1 server terminating connection

a006 OK LOGOUT completed

Clients

[Bearbeiten | Quelltext bearbeiten]

IMAP wird inzwischen von fast allen gängigen E-Mail-Programmen unterstützt. Allerdings bestehen große Unterschiede im Grad der Unterstützung. Viele Clients unterstützen nur Basisfunktionen für den Nachrichtenabruf (was den meisten Nutzern ausreicht). Nur wenige Programme nutzen den vollen Funktionsumfang, den IMAP-Server bieten. Dazu gehört zum Beispiel die Rechtevergabe zum gemeinsamen Zugriff verschiedener Benutzer auf einen Ordner.

Auswahl von Clients mit erweiterter IMAP-Unterstützung:

Auswahl von Clients mit einfacher IMAP-Unterstützung:

Server

[Bearbeiten | Quelltext bearbeiten]

Inzwischen unterstützen viele Mailserver IMAP. Einige Provider unterdrücken jedoch die Funktionalität (oder verlangen ein erhöhtes Entgelt), da bei IMAP mehr Daten auf dem Server gespeichert bleiben und auch die durchschnittliche Übertragungsmenge steigt.

Cyrus war 1996 der erste Server mit einer Version von IMAP, die als Internetstandard empfohlen war.[5] UW IMAP zog im selben Jahr nach und war zuvor Proof of Concept von IMAP. Dieser Server von der University of Washington erweitert IMAP, was aber nicht dokumentiert und trotzdem von der Carnegie Mellon University in ihren Cyrus übernommen wurde.[6][7][8] Dieses Vorgehen der beiden Universitäten bei den ersten Implementierungen bewirkte, dass Konformität und Kompatibilität bei IMAP notorisch strittig ist.

Mit dem Courier Mail Server kam die Abkehr vom mbox-Konzept, das inzwischen als untauglich gilt. Courier speichert die E-Mails nach dem Maildir-Konzept.[9] Die Stabilität und Leistungsfähigkeit des Speicherkonzepts ist ein wesentliches Kriterium von Servern für IMAP.[10]

Im Unix-Umfeld kommen außer den genannten unter anderem folgende IMAP-Server zum Einsatz:

Auch auf anderen Plattformen und auch im kommerziellen Bereich bieten Messaging-Produkte IMAP-Schnittstellen an.

Darüber hinaus bauen Groupware-Lösungen IMAP fest in ihr Konzept ein:

Unterschiede zum Post Office Protocol

[Bearbeiten | Quelltext bearbeiten]

Im Gegensatz zum Post Office Protocol ermöglicht IMAP eine Verwaltung von Nachrichtenordnern auf dem Server. Wenn eine Nachricht per IMAP als „gelesen“ markiert wurde, ist diese Markierung auch für alle anderen Clients sichtbar. Gelöschte Nachrichten verschwinden von allen synchronisierten Geräten.

Nachrichten können direkt auf dem Server durchsucht werden, sodass Clients keine vollständige Kopie aller Ordner vorhalten müssen, um einzelne Nachrichten zu finden. Die serverseitige Suchfunktion und die zentrale Speicherung aller Nachrichten verlagert Rechenarbeit und Speicherplatzverbrauch von den Clients auf den Server.

Authentifizierung

[Bearbeiten | Quelltext bearbeiten]

Der Server kann den Zugriff für nicht-autorisierte Benutzer auf eine Mailbox verweigern. In jedem Fall muss sich der Nutzer authentifizieren, bevor er Zugriff auf Mails erlangen kann. Das geschieht, indem er sich mit Benutzername und Passwort anmeldet. Das Passwort wird dabei auf IMAP-Protokoll-Ebene im Klartext übertragen. Mailserver können deshalb Clients verbieten, das Passwort zu übertragen, falls zuvor keine verschlüsselte Sitzung aufgebaut wurde.

Alternativ ist auch die Verwendung anderer Netzwerk-Authentifikationsprotokolle (z. B. GSSAPI, Kerberos) möglich.

Verschlüsselung

[Bearbeiten | Quelltext bearbeiten]
IMAPS im TCP/IP-Protokollstapel:
Anwendung IMAP
Transport SSL/TLS
TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus 		Token
Ring 		FDDI …

Um die Daten während der Übertragung vor Dritten zu schützen, kann die Datenverbindung mittels SSL/TLS verschlüsselt werden. Dafür existieren zwei unterschiedliche Methoden:

STARTTLS

[Bearbeiten | Quelltext bearbeiten]

Nach dem Aufbau einer unverschlüsselten Datenverbindung mit dem Server (Port 143) kann mittels des Kommandos STARTTLS eine verschlüsselte Sitzung initiiert werden, so dass alle nachfolgend versendeten Daten über diese Verbindung nur noch verschlüsselt übertragen werden. Diese Protokollerweiterung ist in der Protokollspezifikation fest vorgesehen.

IMAPS

[Bearbeiten | Quelltext bearbeiten]

Bei der Verwendung von IMAPS (Internet Message Access Protocol Secure) wird die Verbindung zum (Mail-)Server bereits während des Verbindungsaufbaus durch SSL verschlüsselt. Damit der Server das erkennt, muss ein anderer Port verwendet werden. Dafür wurde der Port 993 reserviert.

Nach dem Aufbau der SSL-Verbindung wird mindestens IMAPv4 verwendet. Die SSL-Schicht ist für das IMAP-Protokoll transparent, d. h., es werden keine Änderungen am IMAP-Protokoll vorgenommen.

In RFC 8314[11] wird die Verwendung von IMAPS gegenüber STARTTLS und gänzlich unverschlüsseltem IMAP bevorzugt.

Geschichte

[Bearbeiten | Quelltext bearbeiten]

Im Juli 1988 schlug Mark Crispin die zweite Version des Protokolls vom SUMEX-AIM zur Erprobung im Internet vor.[3] SUMEX-AIM bedeutet „Stanford University Medical Experimental Computer for Artificial Intelligence in Medicine“ und meint ein über die gesamte USA vernetztes Projekt für künstliche Intelligenz in der Medizin.[12]

Im Februar 1991 wurde als Gegenentwurf zu Crispins neuer zweiten Version vom August 1990 die dritte Version veröffentlicht.[13][14]

Im Dezember 1994 wurde die erste nicht mehr experimentelle und vierte Version veröffentlicht.[15] Im Dezember 1996 folgte die Feststellung, dass eine von mehreren undokumentierten Versionen des Protokolls weit verbreitet war, und die erste Revision der vierten Version, die im März 2003 nochmals geändert wurde.[16][17][18]

Spezifikationen

[Bearbeiten | Quelltext bearbeiten]

Die Dokumentation von IMAP setzt sich aus einer Vielzahl von grundlegenden, ergänzenden oder erweiternden RFC zusammen.[2]

  • RFC: 1731 – IMAP4 Authentication Mechanisms. Dezember 1994 (englisch).
  • RFC: 1732 – IMAP4 Compatibility With IMAP2 And IMAP2BIS. Dezember 1994 (englisch).
  • RFC: 1733 – Distributed Electronic Mail Models In IMAP4. Dezember 1994 (englisch).
  • RFC: 2061 – IMAP4 Compatibility With IMAP2BIS. Dezember 1996 (englisch).
  • RFC: 2062 – Internet Message Access Protocol – Obsolete Syntax. Dezember 1996 (englisch).
  • RFC: 2087 – IMAP4 QUOTA Extension. (englisch).
  • RFC: 2088 – IMAP4 non-synchronizing literals. (englisch).
  • RFC: 2177 – IMAP4 IDLE command. (englisch).
  • RFC: 2180 – IMAP4 Multi-Accessed Mailbox Practice. (englisch).
  • RFC: 2193 – IMAP4 Mailbox Referrals. (englisch).
  • RFC: 2195 – IMAP/POP AUTHorize Extension for Simple Challenge/Response. (englisch).
  • RFC: 2221 – IMAP4 Login Referrals. (englisch).
  • RFC: 2342 – IMAP4 Namespace. (englisch).
  • RFC: 2595 – Using TLS with IMAP, POP3 and ACAP. (englisch).
  • RFC: 2683 – IMAP4 Implementation Recommendations. (englisch).
  • RFC: 2971 – IMAP4 ID Extension. (englisch).
  • RFC: 3348 – IMAP4 Child Mailbox Extension. (englisch).
  • RFC: 3501 – Internet Message Access Protocol – Version 4rev1. (englisch).
  • RFC: 3502 – IMAP MULTIAPPEND Extension. (englisch).
  • RFC: 3503 – Message Disposition Notification (MDN)profile for Internet Message Access Protocol (IMAP). (englisch).
  • RFC: 3516 – IMAP4 Binary Content Extension. (englisch).
  • RFC: 3656 – The Mailbox Update (MUPDATE)Distributed Mailbox Database Protocol. (englisch).
  • RFC: 3691 – IMAP UNSELECT command. (englisch).
  • RFC: 4314 – IMAP4 Access Control List (ACL) Extension. (englisch).
  • RFC: 4315 – Internet Message Access Protocol (IMAP) – UIDPLUS Extension. (englisch).
  • RFC: 4466 – Collected Extensions to IMAP4 ABNF. (englisch).
  • RFC: 4467 – Internet Message Access Protocol (IMAP) – URLAUTH Extension. (englisch).
  • RFC: 4469 – Internet Message Access Protocol (IMAP) – CATENATE Extension. (englisch).
  • RFC: 4549 – Synchronization Operations for Disconnected IMAP4 Clients. (englisch).
  • RFC: 4551 – IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization. (englisch).
  • RFC: 4731 – IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned. (englisch).
  • RFC: 4959 – IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response. (englisch).
  • RFC: 4978 – The IMAP COMPRESS Extension. (englisch).
  • RFC: 5032 – WITHIN Search Extension to the IMAP Protocol. (englisch).
  • RFC: 5092 – IMAP URL Scheme. (englisch).
  • RFC: 5161 – The IMAP ENABLE Extension. (englisch).
  • RFC: 5162 – IMAP4 Extensions for Quick Mailbox Resynchronization. (englisch).
  • RFC: 5182 – IMAP Extension for Referencing the Last SEARCH Result. (englisch).
  • RFC: 5255 – Internet Message Access Protocol Internationalization. (englisch).
  • RFC: 5256 – Internet Message Access Protocol – SORT and THREAD Extensions. (englisch).
  • RFC: 5257 – Internet Message Access Protocol – ANNOTATE Extension. (englisch).
  • RFC: 5258 – Internet Message Access Protocol version 4 – LIST Command Extensions. (englisch).
  • RFC: 5464 – The IMAP METADATA Extension. (englisch).
  • RFC: 5465 – The IMAP NOTIFY Extension. (englisch).
  • RFC: 5530 – IMAP Response Codes. (englisch).
  • RFC: 5550 – The Internet Email to Support Diverse Service Environments (Lemonade) Profile. (englisch).
  • RFC: 5593 – Internet Message Access Protocol (IMAP) – URL Access Identifier Extension. (englisch).
  • RFC: 5738 – IMAP Support for UTF-8. (englisch).
  • RFC: 5788 – IMAP4 Keyword Registry. (englisch).
  • RFC: 5819 – IMAP4 Extension for Returning STATUS Information in Extended LIST. (englisch).
  • RFC: 5957 – Display-Based Address Sorting for the IMAP4 SORT Extension. (englisch).
  • RFC: 6154 – IMAP LIST Extension for Special-Use Mailboxes. (englisch).
  • RFC: 6203 – IMAP4 Extension for Fuzzy Search. (englisch).
  • RFC: 6785 – Support for Internet Message Access Protocol (IMAP) Events in Sieve. (englisch).
  • RFC: 6851 – Internet Message Access Protocol (IMAP) – MOVE Extension. (englisch).
  • RFC: 7162 – IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC). (englisch).
  • RFC: 7377 – IMAP4 Multimailbox SEARCH Extension. (englisch).

Literatur

[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ Service Name and Transport Protocol Port Number Registry. iana.org, 1. Juli 2024, abgerufen am 18. Juli 2024 (englisch).
  2. ↑ a b Alexey Melnikov: RFC: 9051 – Internet Message Access Protocol (IMAP) – Version 4rev2. (englisch).
  3. ↑ a b M. Crispin: RFC: 1064 – Interactive Mail Access Protocol – Version 2. Juli 1988 (englisch).
  4. ↑ M. Crispin: RFC: 3501 – Internet Message Access Protocol – Version 4rev1. März 2003, Abschnitt 8 (englisch).
  5. ↑ IMAP: The Internet Message Access Protocol – Brief Overview and History. University of Washington, 1996, abgerufen am 20. Januar 2012 (englisch).
  6. ↑ M. Crispin: Pine won’t search my IMAP mail. Google, 8. Februar 2003, abgerufen am 8. Mai 2011 (englisch).
  7. ↑ IMAP4 Status. University of Washington, 1996, abgerufen am 20. Januar 2012 (englisch).
  8. ↑ Changes to the Cyrus IMAP Server since 2.3.x. Carnegie Mellon University, abgerufen am 8. Mai 2011 (englisch).
  9. ↑ P. Heinlein, P. Hartleben: The book of IMAP: building a mail server with Courier and Cyrus. Google, S. 107, abgerufen am 8. Mai 2011 (englisch).
  10. ↑ P. B. Koetter: UW IMAP, Courier, Cyrus und Dovecot im direkten Vergleich. Linux New Media, abgerufen am 8. Mai 2011.
  11. ↑ RFC: 8314 – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. Januar 2018 (englisch).
  12. ↑ The Seeds of Artificial Intelligence. In: Educational Research Information Center. United States Department of Education, abgerufen am 5. Februar 2015 (englisch).
  13. ↑ J. Rice: RFC: 1203 – Interactive Mail Access Protocol – Version 3. Februar 1991 (englisch).
  14. ↑ M. Crispin: RFC: 1176 – Interactive Mail Access Protocol – Version 2. August 1990 (englisch).
  15. ↑ M. Crispin: RFC: 1730 – Internet Message Access Protocol – Version 4. Dezember 1994 (englisch).
  16. ↑ M. Crispin: RFC: 2061 – IMAP4 compatibility with IMAP2bis. Dezember 1996 (englisch).
  17. ↑ M. Crispin: RFC: 2060 – Internet Message Access Protocol – Version 4rev1. Dezember 1996 (englisch).
  18. ↑ M. Crispin: RFC: 3501 – Internet Message Access Protocol – Version 4rev1. März 2003 (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Internet_Message_Access_Protocol&oldid=246863666“