| IMAP | |
|---|---|
| Navn | Internet Message Access Protocol |
| Niveau (ifølge OSI-modellen ) | Anvendt |
| Familie | TCP / IP |
| Oprettet i | 1986 |
| Port/ID | 143/ TCP , 993/TCP (IMAP over SSL) |
| Formål med protokollen | Adgang til postkasser |
| Specifikation | RFC 3501 |
| Vigtigste implementeringer (klienter) | MUA ( Outlook Express , Opera , Mozilla Thunderbird , The Bat!, Claws Mail , mutt osv.) |
| Kerneimplementeringer ( servere ) | UW IMAP , Courier , Cyrus , Dovecot |
IMAP ( Internet Message Access Protocol ) er en applikationslagsprotokol til at få adgang til e-mail .
Den er baseret på TCP -transportprotokollen og bruger port 143, mens IMAPS (IMAP over SSL ) bruger port 993. IMAP fungerer kun med beskeder og kræver ingen pakker med specielle overskrifter [1] .
IMAP giver brugeren rig mulighed for at arbejde med postkasser placeret på mailserveren . Et mailprogram, der bruger denne protokol, får adgang til korrespondancelageret på serveren , som om denne korrespondance er placeret på modtagerens computer. E- mails kan manipuleres fra brugerens computer ( klient ), uden at det fulde indhold af e-mails konstant sendes frem og tilbage fra serveren .
SMTP -protokollen bruges normalt til at sende beskeder , da den oprindelige IMAP-sendkommando, kaldet APPEND, ikke indeholder en mekanisme til overførsel af tjenesteinformation [1] .
For postkassenavne ( mappe ) med tegn uden for ASCII -området bruges en modificeret version af UTF-7- kodningen [1] .
IMAP-protokollen er et alternativ til POP med rudimentære afsendelsesmuligheder.
Den første version af POP -protokollen havde en række mangler, og den mest alvorlige af dem var manglen på evne til at styre bevægelse og lagring af meddelelser på serveren. I POP downloades beskeder fra mailserveren på én gang, hvorefter de slettes fra serveren, det vil sige, at der ikke er mulighed for at vælge beskeder at modtage.
For at løse problemerne forbundet med denne funktion af POP , i 1986, oprettede Mark Crispin ( eng. Mark Crispin ), der dengang arbejdede ved Stanford University , en ny protokol til at modtage mail fra serveren [2] .
Den nye protokol gjorde det muligt for brugere at modtage e-mail flere steder fra den samme postkasse. Brugeren får mulighed for at administrere beskeder i sin postkasse og yderligere funktioner til servicering af postkasser på serveren.
I fremtiden blev POP -protokollen færdiggjort, i POP3 (POP version 3) er det muligt at modtage udvalgte beskeder fra serveren og efterlade udvalgte beskeder på serveren. I nyere versioner mellem IMAP og POP er den største forskel for brugeren, at IMAP4 kan tilgå breve i forskellige mailmapper på serveren og flytte bogstaver mellem dem, mens POP3 tilgår bogstaver på serveren ved tal i en lineær liste (dvs. det virker med kun én mail-mappe).
Versioner af IMAP-protokollen [2]Når du bruger POP3 , opretter klienten kun forbindelse til serveren i den tid, det tager at downloade nye meddelelser. Når du bruger IMAP, afbrydes forbindelsen ikke, mens brugergrænsefladen er aktiv, og beskeder downloades kun, når klienten anmoder om det. Dette reducerer responstiden for brugere, der har mange store beskeder i deres postkasser.
POP - protokollen kræver, at den nuværende klient er den eneste, der er tilsluttet boksen. IMAP giver flere klienter adgang til en postkasse på samme tid og giver klienten mulighed for at spore ændringer foretaget af andre klienter, der er tilsluttet på samme tid.
Takket være flagsystemet defineret i IMAP4 kan klienten spore status for en meddelelse (læst, besvaret, slettet osv.); flagdata gemmes på serveren.
IMAP4-klienter kan oprette, omdøbe og slette postkasser og flytte beskeder mellem postkasser. Alternativt kan du bruge "IMAP4 Access Control List ( ACL ) Extension" ( RFC 4314 ) til at administrere postkasseadgangsrettigheder.
Beskeder søges på serversiden.
IMAP4 har en eksplicit forlængelsesmekanisme. [3]
IMAP fungerer kun med beskeder og kræver ingen pakker med specielle overskrifter. Hver besked har flere attributter tilknyttet. Disse attributter kan defineres individuelt eller i kombination med andre attributter.
Hver besked er tildelt en 32-bit kode , som, når den bruges sammen med en unik identifikator, danner en 64-bit sekvens, der garanterer en unik identifikation af beskeden i postkassen. Jo senere beskeden ankom, jo større er dens UID.
Et UID er knyttet til en postkasse og sendes som en uidvalidity (ok) svarkode under postkasseudvælgelsesfasen. Hvis UID'et fra den forrige session af en eller anden grund ikke kan bruges, skal UID'et øges.
En meddelelses UID bør ikke ændres inden for en session, og den bør heller ikke ændre sig fra session til session. Men hvis det ikke er muligt at gemme meddelelsens UID i en efterfølgende session, skal hver efterfølgende session have en ny unik identifikationskode, som skal være større end nogen tidligere brugt UID.
Sekvensnummeret for en meddelelse i en postkasse starter ved 1. Hver meddelelse, startende fra den anden, har et sekvensnummer, der er nøjagtigt 1 større end det, der gik forud.
Det er tilladt at ændre sekvensnummeret på en besked under en session. For eksempel, når en besked slettes fra en postkasse, ændres numrene på alle efterfølgende beskeder.
Denne attribut er en liste over nul eller flere navngivne tokens forbundet med den givne besked. Flaget indstilles ved at tilføje det til denne liste og nulstilles ved at fjerne det. Der er to typer flag i IMAP 4.1. Flaget kan kun være permanent eller aktivt i denne sessions varighed.
Et systemflag er et flag, hvis navn er defineret i protokolspecifikationen. Alle systemflag starter med en \.
Følgende systemflag er i øjeblikket defineret:
Tid og dato, hvor beskeden blev modtaget. Hvis beskeden blev leveret via SMTP-protokollen , dato og tidspunkt for levering til den endelige destination. For meddelelser leveret af kopikommandoen, den interne dato og klokkeslæt for afsenderen af meddelelsen. Når du bruger kommandoen append , dato og klokkeslæt angivet af kommandoparametrene.
En IMAP 4.1-forbindelse involverer etablering af en forbindelse mellem en klient og en server . Klienten sender kommandoer til serveren, serveren sender data og meddelelser om status for anmodningen til klienten. Alle meddelelser, både klient og server, er i form af strenge, der afsluttes af en speciel sekvens.
Enhver procedure begynder med klientens kommando. Enhver klientkommando begynder med et identifikationspræfiks (normalt en kort alfanumerisk streng såsom , A0001osv. A0002) kaldet et tag. For hver kommando genererer klienten sin egen etiket.
Der er to tilfælde, hvor strengen sendt af klienten ikke repræsenterer en komplet kommando. I den første leveres kommandoargumentet med en kode, der bestemmer antallet af oktetter i strengen. I det andet kræver kommandoargumenterne et svar fra serveren. I begge tilfælde sender serveren en kommandofortsættelsesanmodning, der starter med tegnet +.
Klienten skal fuldføre afsendelsen af en kommando, før den sender en anden.
Serverens protokolmodtager læser kommandostrengen modtaget fra klienten, analyserer den, udtrækker parametrene og sender dataene til serveren. Når kommandoen er fuldført, sender serveren et svar.
Data, der transmitteres af serveren til klienten, samt statussvar, der ikke indikerer fuldførelsen af kommandoen, er foranstillet * og kaldes ikke-taggede svar.
Data kan sendes af serveren som svar på en klientkommando eller på eget initiativ. Dataformatet afhænger ikke af årsagen til afsendelsen.
Svaret angiver succes/fejl af operationen. Den bruger den samme etiket som klientkommandoen, der startede proceduren. Således, hvis mere end én kommando udføres, peger serveretiketten på den kommando, der forårsagede svaret. Der er tre slags servertermineringssvar: ok(succes), no(fejl), bad(protokolfejl, f.eks. kommando ikke genkendt eller syntaksfejl opdaget).
IMAP 4.1-klientprotokollytteren læser svarstrengen fra serveren og foretager handling i henhold til det første *eller tegn +.
Klienten skal til enhver tid være klar til at acceptere ethvert svar fra serveren. Serverdataene skal skrives, så klienten direkte kan bruge dem uden at sende opslagsanmodninger til serveren.
IMAP 4.1-serveren er i en af fire tilstande.
De fleste kommandoer kan kun bruges i visse tilstande.
I den ikke- godkendte tilstand skal klienten angive et brugernavn og en adgangskode, før de fleste kommandoer er tilgængelige for den. Overgang til denne tilstand foretages, når en forbindelse er etableret uden forudgående godkendelse.
I den autentificerede tilstand identificeres klienten og skal vælge en postkasse, hvorefter kommandoer til at arbejde med beskeder bliver tilgængelige for ham. Overgang til denne tilstand sker, når en forbindelse med præ- godkendelse er etableret , når alle nødvendige identifikationsdata er udstedt, eller når en postkasse er valgt ved en fejl.
Systemet går i valgtilstand , når postkassen er valgt.
Systemet går i udgangstilstand , når forbindelsen afbrydes som følge af en klientanmodning eller på grund af en uafhængig beslutning fra serveren.
| URI- ordninger | |
|---|---|
| Officiel | |
| uofficiel | |
| Grundlæggende TCP / IP-protokoller efter lag af OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliseret | |
| netværk | |
| Transportere | |
| session | |
| Repræsentation | |
| Anvendt | |
| Andet anvendt | |
| Liste over TCP- og UDP-porte | |