Internetmeddelandeåtkomstprotokoll -
Internet Message Access Protocol

"IMAP" omdirigerar här. Det är inte att förväxla med MAPI , ett e -postklient -API.
"IMAP" omdirigerar här. För NASA -rymdfarkoster, se Interstellar Mapping and Acceleration Probe . För det antipsykotiska, se Fluspirilene .
Internet -protokoll
Appliceringsskikt
Transportskikt
Internet lager
Länk lager
.

993.

Nästan alla moderna e-postklienter och servrar stöder IMAP, som tillsammans med det tidigare POP3 (Post Office Protocol) är de två vanligaste standardprotokollen för e-posthämtning. Många webbpostleverantörer som Gmail och Outlook.com ger också stöd för både IMAP och POP3.

E -postprotokoll

Internet Message Access Protocol är ett applikationslagret Internetprotokoll som gör att en e-postklient att komma åt e-post på en fjärrpostserver . Den nuvarande versionen definieras av RFC  3501 . En IMAP-server lyssnar vanligtvis på välkänd port 143, medan IMAP över SSL/TLS (IMAPS) använder 993.

Inkommande e -postmeddelanden skickas till en e -postserver som lagrar meddelanden i mottagarens e -postlåda. Användaren hämtar meddelandena med en e -postklient som använder ett av ett antal e -posthämtningsprotokoll. Medan vissa klienter och servrar företrädesvis använder leverantörsspecifika, proprietära protokoll , stöder nästan alla POP och IMAP för att hämta e-post-vilket gör att många fria val mellan många e-postklienter som Pegasus Mail eller Mozilla Thunderbird kan få åtkomst till dessa servrar och gör det möjligt för klienterna att användas med andra servrar .

E -postklienter som använder IMAP lämnar i allmänhet meddelanden på servern tills användaren uttryckligen tar bort dem. Detta och andra egenskaper hos IMAP -drift gör att flera klienter kan hantera samma brevlåda. De flesta e -postklienter stöder IMAP förutom Post Office Protocol (POP) för att hämta meddelanden. IMAP erbjuder åtkomst till postlagringen. Kunder kan lagra lokala kopior av meddelandena, men dessa anses vara en tillfällig cache.

Historia

IMAP designades av Mark Crispin 1986 som ett postlåda -protokoll för fjärråtkomst, till skillnad från den ofta använda POP, ett protokoll för att enkelt hämta innehållet i en brevlåda.

Det gick igenom ett antal iterationer före den nuvarande VERSION 4rev1 (IMAP4), enligt detaljerad nedan:

Original IMAP

Det ursprungliga Interim Mail Access Protocol implementerades som en Xerox Lisp Machine- klient och en TOPS-20- server.

Det finns inga kopior av den ursprungliga interimsprotokollspecifikationen eller dess programvara. Även om några av dess kommandon och svar liknade IMAP2 saknade interimprotokollet kommando/svarstaggning och dess syntax var därför inkompatibel med alla andra versioner av IMAP.

IMAP2

Interimprotokollet ersattes snabbt av Interactive Mail Access Protocol (IMAP2), definierat i RFC  1064 (1988) och uppdaterades senare av RFC  1176 (1990). IMAP2 introducerade kommandot/svarstaggen och var den första offentligt distribuerade versionen.

IMAP3

IMAP3 är en extremt sällsynt variant av IMAP. Det publicerades som RFC  1203 1991. Det skrevs specifikt som ett motförslag till RFC  1176 , som själv föreslog ändringar av IMAP2. IMAP3 accepterades aldrig av marknaden. Den IESG omklassificeras RFC1203 "Interactive Mail Access Protocol - Version 3" såsom ett historiskt protokoll 1993. IMAP arbetsgrupp används RFC 1176 (IMAP2) snarare än RFC 1203 (IMAP3) som dess startpunkt.

IMAP2bis

Med tillkomsten av MIME utvidgades IMAP2 till att stödja MIME -kroppsstrukturer och lägga till funktioner för postlådeshantering (skapa, ta bort, byta namn, överföra meddelanden) som saknades från IMAP2. Denna experimentella översyn kallades IMAP2bis; dess specifikation publicerades aldrig i icke-utkastform. Ett internetutkast till IMAP2bis publicerades av IETF IMAP Working Group i oktober 1993. Detta utkast baserades på följande tidigare specifikationer: opublicerat IMAP2bis.TXT -dokument, RFC  1176 och RFC  1064 (IMAP2). Den IMAP2bis.TXT utkast dokumenterade tillståndet för tillägg till IMAP2 i december 1992. Tidiga versioner av Pine var spridda med IMAP2bis support (Pine 4.00 och senare stöder IMAP4rev1).

IMAP4

En IMAP -arbetsgrupp som bildades i IETF i början av 1990 -talet tog över ansvaret för IMAP2bis -designen. IMAP WG beslutade att byta namn på IMAP2bis till IMAP4 för att undvika förvirring.

Fördelar jämfört med POP

Anslutna och frånkopplade lägen

När du använder POP ansluter klienter vanligtvis till e-postservern kort, bara så länge det tar att ladda ner nya meddelanden. När du använder IMAP4 håller klienterna ofta uppkoppling så länge användargränssnittet är aktivt och hämtar meddelandeinnehåll på begäran. För användare med många eller stora meddelanden kan detta IMAP4 -användningsmönster resultera i snabbare svarstider.

Flera samtidiga klienter

POP -protokollet kräver att den för närvarande anslutna klienten är den enda klienten som är ansluten till brevlådan. Däremot tillåter IMAP -protokollet specifikt samtidig åtkomst av flera klienter och tillhandahåller mekanismer för klienter för att upptäcka ändringar som görs i brevlådan av andra, samtidigt anslutna, klienter. Se till exempel RFC  3501 avsnitt 5.2 som specifikt citerar "samtidig åtkomst till samma brevlåda av flera agenter" som ett exempel.

Tillgång till MIME -meddelandedelar och delvis hämtning

Vanligtvis överförs all Internet-e-post i MIME- format, så att meddelanden kan ha en trädstruktur där bladnoderna är olika typer av enstaka innehållstyper och icke-bladnoder är olika i flera olika typer. IMAP4 -protokollet tillåter klienter att hämta någon av de enskilda MIME -delarna separat och även att hämta delar av antingen enskilda delar eller hela meddelandet. Dessa mekanismer gör det möjligt för klienter att hämta textdelen av ett meddelande utan att hämta bifogade filer eller att strömma innehåll när det hämtas.

Meddelandestatus

Genom att använda flaggor som definieras i IMAP4 -protokollet kan klienter hålla reda på meddelandestatus: till exempel om meddelandet har lästs, besvarats eller raderats. Dessa flaggor lagras på servern, så olika klienter som får åtkomst till samma brevlåda vid olika tidpunkter kan upptäcka tillståndsändringar som gjorts av andra klienter. POP tillhandahåller ingen mekanism för klienter att lagra sådan tillståndsinformation på servern, så om en enda användare får tillgång till en postlåda med två olika POP -klienter (vid olika tidpunkter) kan inte statlig information - till exempel om ett meddelande har öppnats - synkroniseras mellan kunder. IMAP4-protokollet stöder både fördefinierade systemflaggor och klientdefinierade nyckelord. Systemflaggor indikerar tillståndsinformation, till exempel om ett meddelande har lästs. Nyckelord, som inte stöds av alla IMAP -servrar, gör att meddelanden kan ges en eller flera taggar vars betydelse är upp till klienten. IMAP-nyckelord bör inte förväxlas med egna etiketter för webbaserade e-posttjänster som ibland översätts till IMAP-mappar av motsvarande egna servrar.

Flera brevlådor på servern

IMAP4 -klienter kan skapa, byta namn på och/eller ta bort postlådor (brukar presenteras för användaren som mappar) på servern och kopiera meddelanden mellan postlådor. Stöd för flera brevlådor gör det också möjligt för servrar att ge åtkomst till delade och offentliga mappar. Den IMAP4 Access Control List (ACL) Extension ( RFC  4314 ) kan användas för att reglera accessrättigheter.

Sökningar på serversidan

IMAP4 tillhandahåller en mekanism för en klient att be servern att söka efter meddelanden som uppfyller en mängd olika kriterier. Denna mekanism undviker att kräva att klienterna laddar ner alla meddelanden i brevlådan för att kunna utföra dessa sökningar.

Inbyggd förlängningsmekanism

Med avseende på erfarenheten av tidigare internetprotokoll definierar IMAP4 en tydlig mekanism genom vilken den kan utökas. Många IMAP4 -tillägg till basprotokollet har föreslagits och är vanligt förekommande. IMAP2bis hade ingen förlängningsmekanism och POP har nu en definierad av RFC  2449 .

Nackdelar

Medan IMAP åtgärdar många av POP: s brister, introducerar detta i sig ytterligare komplexitet. Mycket av denna komplexitet (t.ex. att flera klienter får åtkomst till samma brevlåda samtidigt) kompenseras av lösningar på serversidan som Maildir eller databasbackends.

IMAP -specifikationen har kritiserats för att vara otillräckligt strikt och tillåta beteenden som effektivt förnekar dess användbarhet. Till exempel står det i specifikationen att varje meddelande som lagras på servern har ett "unikt id" för att klienterna ska kunna identifiera meddelanden som de redan har sett mellan sessionerna. Men specifikationen gör det också möjligt att ogiltigförklara dessa UID utan några begränsningar, vilket praktiskt taget besegrar deras syfte.

Om inte e -postlagrings- och sökalgoritmerna på servern är omsorgsfullt implementerade kan en klient potentiellt konsumera stora mängder serverresurser vid sökning i massiva brevlådor.

IMAP4 -klienter måste upprätthålla en TCP/IP -anslutning till IMAP -servern för att kunna meddelas om ny e -post. Meddelande om postankomst sker via in-band-signalering , vilket bidrar till komplexiteten i IMAP-protokollhantering på klientsidan något. Ett privat förslag, push IMAP , skulle utöka IMAP till att genomföra push-e-post genom att skicka hela meddelandet istället för bara ett meddelande. Push IMAP har dock inte varit allmänt accepterat och nuvarande IETF -arbete har tagit upp problemet på andra sätt (se Lemonade -profilen för mer information).

Till skillnad från vissa proprietära protokoll som kombinerar sändnings- och hämtningsoperationer, för att skicka ett meddelande och spara en kopia i en mapp på serversidan med en IMAP-klient på basnivå, måste meddelandets innehåll sändas två gånger, en gång till SMTP för leverans och en andra gång till IMAP till lagra i en e -postmapp. Detta åtgärdas av en uppsättning tillägg som definieras av IETF Lemonade-profilen för mobila enheter: URLAUTH ( RFC  4467 ) och CATENATE ( RFC  4469 ) i IMAP och BURL ( RFC  4468 ) i SMTP-SUBMISSION. Utöver detta erbjuder Courier Mail Server en icke-standardiserad metod för att skicka med IMAP genom att kopiera ett utgående meddelande till en dedikerad utkorgsmapp.

säkerhet

För att kryptografiskt skydda IMAP -anslutningar kan IMAPS på TCP -port 993 användas, som använder SSL/TLS. Från och med januari 2018 är TLS den rekommenderade mekanismen.

Alternativt kan STARTTLS användas för att tillhandahålla säker kommunikation mellan MUA som kommunicerar med MSA eller MTA som implementerar SMTP -protokollet .

Dialogexempel

Detta är ett exempel på IMAP -anslutning från RFC 3501 avsnitt 8 : 

C: <open connection>

S:   * OK IMAP4rev1 Service Ready

C:   a001 login mrc secret

S:   a001 OK LOGIN completed

C:   a002 select inbox

S:   * 18 EXISTS
S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S:   * 2 RECENT
S:   * OK [UNSEEN 17] Message 17 is the first unseen message
S:   * OK [UIDVALIDITY 3857529045] UIDs valid
S:   a002 OK [READ-WRITE] SELECT completed

C:   a003 fetch 12 full

S:   * 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"))
      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
      ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
      "<B27397-0100000@cac.washington.edu>")
      BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
      92))
S:   a003 OK FETCH completed

C:   a004 fetch 12 body[header]

S:   * 12 FETCH (BODY[HEADER] {342}
S:   Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S:   From: Terry Gray <gray@cac.washington.edu>
S:   Subject: IMAP4rev1 WG mtg summary and minutes
S:   To: imap@cac.washington.edu
S:   cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S:   Message-Id: <B27397-0100000@cac.washington.edu>
S:   MIME-Version: 1.0
S:   Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S:   )
S:   a004 OK FETCH completed

C    a005 store 12 +flags \deleted

S:   * 12 FETCH (FLAGS (\Seen \Deleted))
S:   a005 OK +FLAGS completed

C:   a006 logout

S:   * BYE IMAP4rev1 server terminating connection
S:   a006 OK LOGOUT completed

Se även

Referenser

Vidare läsning