| IMAP | |
|---|---|
| namn | Internet Message Access Protocol |
| Nivå (enligt OSI-modellen ) | Applicerad |
| Familj | TCP / IP |
| Skapad i | 1986 |
| Port/ID | 143/ TCP , 993/TCP (IMAP över SSL) |
| Syftet med protokollet | Tillgång till brevlådor |
| Specifikation | RFC 3501 |
| Huvudsakliga implementeringar (klienter) | MUA ( Outlook Express , Opera , Mozilla Thunderbird , The Bat!, Claws Mail , mutt , etc.) |
| Kärnimplementationer ( servrar ) | UW IMAP , Courier , Cyrus , Dovecot |
IMAP ( Internet Message Access Protocol ) är ett applikationslagerprotokoll för åtkomst till e-post .
Den är baserad på TCP- transportprotokollet och använder port 143, medan IMAPS (IMAP över SSL ) använder port 993. IMAP fungerar bara med meddelanden och kräver inga paket med speciella rubriker [1] .
IMAP ger användaren stora möjligheter att arbeta med postlådor som finns på e -postservern . Ett e-postprogram som använder detta protokoll kommer åt korrespondenslagringen på servern som om denna korrespondens finns på mottagarens dator. E- postmeddelanden kan manipuleras från användarens dator ( klient ) utan att hela innehållet i e-postmeddelandena ständigt skickas fram och tillbaka från servern .
SMTP- protokollet används vanligtvis för att skicka meddelanden , eftersom det inbyggda IMAP-sändningskommandot, kallat APPEND, inte innehåller en mekanism för att överföra tjänstinformation [1] .
För brevlådenamn ( mappnamn ) med tecken utanför ASCII -intervallet används en modifierad version av UTF-7- kodningen [1] .
IMAP-protokollet är ett alternativ till POP med rudimentära sändningsmöjligheter.
Den första versionen av POP- protokollet hade ett antal brister, och den allvarligaste av dem var bristen på förmåga att hantera förflyttning och lagring av meddelanden på servern. I POP laddas meddelanden ner från e-postservern på en gång, varefter de raderas från servern, det vill säga det finns ingen möjlighet att välja meddelanden att ta emot.
För att lösa problemen i samband med denna funktion av POP skapade 1986 Mark Crispin ( eng. Mark Crispin ), som då arbetade vid Stanford University , ett nytt protokoll för att ta emot e-post från servern [2] .
Det nya protokollet gjorde det möjligt för användare att ta emot e-post på flera platser från samma brevlåda. Användaren ges möjlighet att hantera meddelanden i sin brevlåda och ytterligare funktioner för att serva brevlådor på servern.
I framtiden slutfördes POP- protokollet, i POP3 (POP version 3) är det möjligt att ta emot utvalda meddelanden från servern och lämna utvalda meddelanden på servern. I nyare versioner mellan IMAP och POP är den största skillnaden för användaren att IMAP4 kan komma åt brev i olika e-postmappar på servern och flytta bokstäver mellan dem, medan POP3 kommer åt bokstäver på servern med siffror i en linjär lista (det vill säga, det fungerar med bara en e-postmapp ).
Versioner av IMAP-protokollet [2]När du använder POP3 ansluter klienten till servern endast under den tid det tar att ladda ner nya meddelanden. När du använder IMAP avbryts inte anslutningen medan användargränssnittet är aktivt, och meddelanden laddas bara ned när klienten begär det. Detta minskar svarstiden för användare som har många stora meddelanden i sina brevlådor.
POP - protokollet kräver att den nuvarande klienten är den enda som är ansluten till boxen. IMAP tillåter flera klienter att komma åt en brevlåda samtidigt och ger klienten möjlighet att spåra ändringar som görs av andra klienter som är anslutna samtidigt.
Tack vare flaggsystemet som definieras i IMAP4 kan klienten spåra statusen för ett meddelande (läst, svarade på, raderad, etc.); flaggdata lagras på servern.
IMAP4-klienter kan skapa, byta namn på och ta bort postlådor och flytta meddelanden mellan postlådor. Alternativt kan du använda "IMAP4 Access Control List ( ACL ) Extension" ( RFC 4314 ) för att hantera postlådeåtkomsträttigheter.
Meddelanden söks på serversidan.
IMAP4 har en explicit förlängningsmekanism. [3]
IMAP fungerar bara med meddelanden och kräver inga paket med speciella rubriker. Varje meddelande har flera attribut kopplade till sig. Dessa attribut kan definieras individuellt eller i kombination med andra attribut.
Varje meddelande tilldelas en 32-bitars kod , som, när den används tillsammans med en unik identifierare, bildar en 64-bitars sekvens som garanterar unik identifiering av meddelandet i brevlådan. Ju senare meddelandet kom, desto större är dess UID.
Ett UID är associerat med en brevlåda och skickas som en uidvalidity (ok) svarskod under brevlådevalsfasen. Om UID från föregående session av någon anledning inte kan användas, måste UID ökas.
UID för ett meddelande bör inte ändras inom en session och inte heller från session till session. Men om det inte är möjligt att lagra UID för meddelandet i en efterföljande session, måste varje efterföljande session ha en ny unik identifieringskod, som måste vara större än något UID som tidigare använts.
Sekvensnumret för ett meddelande i en brevlåda börjar på 1. Varje meddelande, från och med det andra, har ett sekvensnummer som är exakt 1 större än det som föregick det.
Det är tillåtet att ändra sekvensnumret för ett meddelande under en session. Till exempel, när ett meddelande raderas från en brevlåda, ändras numren på alla efterföljande meddelanden.
Detta attribut är en lista med noll eller fler namngivna tokens som är associerade med det givna meddelandet. Flaggan ställs in genom att lägga till den i denna lista och återställas genom att ta bort den. Det finns två typer av flaggor i IMAP 4.1. Flaggan kan vara permanent eller aktiv endast under den här sessionen.
En systemflagga är en flagga vars namn är definierat i protokollspecifikationen. Alla systemflaggor börjar med en \.
Följande systemflaggor är för närvarande definierade:
Tid och datum då meddelandet togs emot. Om meddelandet levererades via SMTP-protokollet , datum och tid för leverans till slutdestinationen. För meddelanden som levereras med kopieringskommandot, interna datum och tid för avsändaren av meddelandet. När du använder kommandot append , datum och tid som anges av kommandoparametrarna.
En IMAP 4.1-anslutning innebär att en anslutning upprättas mellan en klient och en server . Klienten skickar kommandon till servern, servern skickar data och meddelanden om status för begäran till klienten. Alla meddelanden, både klient och server, är i form av strängar som avslutas av en speciell sekvens.
Varje procedur börjar med klientens kommando. Alla klientkommandon börjar med ett identifierarprefix (vanligtvis en kort alfanumerisk sträng som , A0001etc. A0002) som kallas en tagg. För varje kommando genererar klienten sin egen etikett.
Det finns två fall där strängen som skickas av klienten inte representerar ett fullständigt kommando. I det första tillförs kommandoargumentet en kod som bestämmer antalet oktetter i strängen. I det andra kräver kommandoargumenten ett svar från servern. I båda fallen skickar servern en kommandofortsättningsbegäran som börjar med tecknet +.
Klienten måste slutföra att skicka ett kommando innan ett annat skickas.
Serverns protokollmottagare läser kommandosträngen som tas emot från klienten, analyserar den, extraherar parametrarna och skickar data till servern. När kommandot är klart skickar servern ett svar.
Data som sänds av servern till klienten, såväl som statussvar som inte indikerar slutförandet av kommandot, har prefix * och kallas otaggade svar.
Data kan skickas av servern som svar på ett klientkommando eller på eget initiativ. Dataformatet beror inte på orsaken till sändningen.
Svaret indikerar framgång/misslyckande av operationen. Den använder samma etikett som klientkommandot som startade proceduren. Således, om mer än ett kommando exekveras, pekar serveretiketten på kommandot som orsakade svaret. Det finns tre typer av serveravslutningssvar: ok(framgång), no(misslyckande), bad(protokollfel, t.ex. kommando känns inte igen eller syntaxfel upptäckts).
IMAP 4.1 klientprotokollavlyssnaren läser svarssträngen från servern och vidtar åtgärder enligt det första *eller tecknet +.
Klienten måste vara redo att acceptera alla svar från servern när som helst. Serverdatan måste skrivas så att klienten direkt kan använda den utan att skicka uppslagsförfrågningar till servern.
IMAP 4.1-servern är i ett av fyra tillstånd.
De flesta kommandon kan endast användas i vissa tillstånd.
I det oautentiserade tillståndet måste klienten ange ett användarnamn och lösenord innan de flesta kommandon är tillgängliga för den. Övergång till detta tillstånd görs när en anslutning upprättas utan föregående autentisering.
I det autentiserade tillståndet identifieras klienten och måste välja en brevlåda, varefter kommandon för att arbeta med meddelanden blir tillgängliga för honom. Övergång till detta tillstånd sker när en anslutning med förautentisering upprättas , när alla nödvändiga identifieringsdata utfärdas eller när en brevlåda väljs av misstag.
Systemet går in i valstatus när brevlådan har valts.
Systemet går in i utgångsläge när anslutningen avbryts som ett resultat av en klientförfrågan eller på grund av ett oberoende beslut från servern.
| URI- scheman | |
|---|---|
| Officiell | |
| inofficiell | |
| Grundläggande TCP / IP-protokoll efter lager av OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliserad | |
| nätverk | |
| Transport | |
| session | |
| Representation | |
| Applicerad | |
| Annat ansökt | |
| Lista över TCP- och UDP-portar | |