Bibliografia:
Computer Networking. Cap. 3. Autori: James F. Kurose (University of Massachusetts, Amherst) Keith W. Ross (Polytechnic Institute of NYU).
La posta elettronica è stata usata fin dalla nascita di Internet. È stata l'applicazione più popolare quando Internet era ancora agli albori, ed è diventata sempre più sofisticata e potente nel corso degli anni. Rimane una delle più importanti ed utilizzate applicazioni di Internet.
Come per la posta ordinaria, la posta elettronica è un mezzo di comunicazione asincrono - la gente invia e legge messaggi quando è disponibile, senza doversi coordinare con gli orari delle altre persone. Rispetto alla posta ordinaria, la posta elettronica è veloce, facile da distribuire, e poco costosa. La posta elettronica moderna ha molte caratteristiche, un messaggio può avere gli allegati, i collegamenti ipertestuali, il testo in formato HTML, e le foto incorporate.
In questa sezione, vengono esaminati i protocolli del livello applicazione che sono usati dalla posta elettronica. La Figura presenta una visione del sistema di posta Internet. Ci sono tre componenti principali: gli User-Agent, i server di posta, e il Simple Mail Transfer Protocol (SMTP). Il ruolo di ciascuno di questi componenti verrà descritto ipotizzando che un mittente, Alice, invia un messaggio di posta elettronica a un destinatario, Bob. Gli User-Agent permetteranno agli utenti di leggere, rispondere, inoltrare, salvare e comporre messaggi.
Microsoft Outlook e Apple Mail sono esempi di User-Agent per e-mail. Quando Alice ha terminato di comporre il suo messaggio, il suo User-Agent lo invia al suo server di posta, qui il messaggio viene inserito nella coda dei messaggi in uscita del server di posta. Quando Bob vuole leggere un messaggio, il suo User-Agent recupera il messaggio dalla sua casella di posta nel suo server di posta. I server di posta formano il nucleo del sistema di posta elettronica. Ogni destinatario, come Bob, ha una casella postale situata su un server di posta. La casella di posta di Bob gestisce e mantiene i messaggi che sono stati inviati a lui. Un messaggio tipico inizia il suo viaggio nello User-Agent del mittente, si reca al server di posta del mittente, e viaggia al server di posta del destinatario, dove viene depositato nella cassetta postale del destinatario.
Quando Bob vuole accedere ai messaggi nella sua casella di posta, il server di posta autentica Bob (con username e password). Il Server di posta di Alice deve essere in grado di riconoscere errori nel server di posta di Bob. Se il server di Alice non può consegnare la posta al server di Bob, il server di Alice conserva il messaggio in una coda di messaggi e tenta di trasferire il messaggio più tardi. I nuovi tentativi sono spesso fatti ogni 30 minuti circa; se non vi è alcun successo dopo diversi giorni, il server rimuove il messaggio e notifica la mancata consegna al mittente (Alice) con un messaggio di posta elettronica.
SMTP è il principale protocollo del livello applicazione per la posta elettronica. Utilizza il servizio di trasferimento dati affidabile di TCP per trasferire la posta dal server di posta del mittente al server di posta del destinatario. Come con tutti i protocolli del livello applicazione, SMTP ha un lato client, che viene eseguito sul server di posta del mittente, e un lato server, che viene eseguito sul server di posta del destinatario. Entrambi le componenti di SMTP funzionano su un server di posta. Quando un server di posta invia la posta ad altri server di posta, agisce come un client SMTP. Quando un server di posta riceve la posta da altri server di posta, agisce come un server SMTP.
Nel dicembre 1995, solo pochi anni dopo che il Web fu inventato, Sabeer Bhatia e Jack Smith visitarono l'Internet venture capitalist Draper Fisher Jurvetson e proposero lo sviluppo di un sistema di e-mail gratuito basato sul web. L'idea era di dare un account di posta elettronica gratuita a chiunque lo volesse, e rendere gli account accessibili dal web. In cambio del 15 per cento della società, Draper Fisher Jurvetson finanziarono Bhatia e Smith, che costituirono una società denominata Hotmail.
Con tre persone a tempo pieno e 14 persone part-time che hanno lavorato per le stock option, sono stati in grado di sviluppare e lanciare il servizio nel luglio 1996. Meno di un mese dopo il lancio, avevano 100.000 abbonati. Nel dicembre 1997, meno di 18 mesi dopo il lancio del servizio, Hotmail ha oltre 12 milioni di abbonati ed è stata acquisita da Microsoft per 400 milioni di dollari. Il successo di Hotmail è attribuito al suo "vantaggio della prima mossa" e alla intrinseca diffusione di avvisi pubblicitari, anche involotaria, della posta elettronica.
La posta elettronica sul Web continua a prosperare, diventando più sofisticata e potente ogni anno. Uno dei servizi più popolari oggi è gmail di Google, che offre un gigabyte di spazio di archiviazione gratuito, rilevamento e filtraggio dello spam e un'avanzata protezione da virus, offre anche la crittografia (utilizzando SSL), il recupero della posta dai servizi di posta elettronica di terze parti, e una interfaccia orientata alla ricerca. Anche la Messaggistica asincrona all'interno delle reti sociali, come Facebook, è diventata popolare negli ultimi anni.
SMTP, definito nella RFC 5321, è il cuore della posta elettronica. Come accennato in precedenza, SMTP trasferisce i messaggi provenienti dai server di posta dei mittenti ai server di posta dei destinatari. SMTP è molto più vecchio di HTTP. Anche se SMTP ha numerose qualità, è una tecnologia vecchia, che possiede alcune caratteristiche arcaiche.
Ad esempio, nel corpo (non solo nelle intestazioni) di tutti i messaggi di posta elettronica si usa la codifica ASCII a 7 bit. Questa limitazione aveva un senso nei primi anni '80, quando la capacità di trasmissione era scarsa e nessuno spediva allegati di grandi dimensioni come i file audio, video, ecc. Ma oggi, nell'era multimediale, la restrizione dei codici a 7 bit è inammissibile. Non conviene che i dati multimediali binari vengano codificati in ASCII prima di essere inviati tramite SMTP; al ricevitore il messaggio ASCII dovrebbe tornare in binario dopo il trasporto SMTP.
Per illustrare il funzionamento di base di SMTP, si esamini un caso comune. Si supponga che Alice vuole inviare a Bob un messaggio di testo.
Alice richiama il suo User-Agent di posta elettronica, fornisce l'indirizzo e-mail di Bob (per esempio, bob@scuola.edu), compone un messaggio, e incarica l'User-Agent di inviare il messaggio.
Lo User-Agent di Alice invia il messaggio al suo server di posta, dove viene collocato in una coda di messaggi.
Il lato client di SMTP in esecuzione sul server di posta di Alice, vede il messaggio nella coda di messaggi e apre una connessione TCP con il server SMTP, in esecuzione sul server di posta di Bob.
Dopo l'handshaking iniziale, il client SMTP invia il messaggio di Alice sulla connessione TCP.
Al server di posta di Bob, il lato server SMTP riceve il messaggio. Il server di posta di Bob poi inserisce il messaggio nella casella di posta di Bob.
Quando ne ha la possibilità, Bob richiama il suo User-Agent per leggere il messaggio.
È importante osservare che SMTP normalmente non usa server di posta intermedi per inviare la posta, anche quando i due server di posta sono situati alle estremità opposte del mondo. Se il server di Alice è a Hong Kong e il server di Bob è a St. Louis, la connessione TCP è una connessione diretta tra i server di Hong Kong e di St. Louis. In particolare, se il server di posta di Bob è spento, il messaggio rimane nel server di posta di Alice, in attesa di un nuovo tentativo, il messaggio non viene inserito in alcun mail server intermedio.
Ma in che modo SMTP trasferisce un messaggio da un server di posta mittente ad un server di posta destinatario? Il protocollo SMTP ha molte analogie con i protocolli utilizzati nell'interazione diretta tra le persone.
In primo luogo, il client SMTP (in esecuzione su un server di posta mittente) deve stabilire una connessione TCP sulla porta 25 del server SMTP (in esecuzione sulla macchina server di posta ricevente). Se il server è inattivo, il client riprova più tardi. Una volta stabilita la connessione, i processi applicativi del server e del client eseguono una fase di handshake, proprio come le persone si presentano prima di scambiarsi informazioni. I client e i server SMTP si presentano prima di trasferire informazioni. Durante questa fase di handshaking SMTP, il client SMTP indica l'indirizzo e-mail del mittente (la persona che ha generato il messaggio) e l'indirizzo e-mail del destinatario. Una volta che il client e il server SMTP si sono sincronizzati, il client invia il messaggio.
SMTP può contare sul servizio di trasferimento dati affidabile di TCP per consegnare il messaggio al server senza errori. Il client quindi ripete questo processo sulla stessa connessione TCP, se ha altri messaggi da inviare al server; in caso contrario, chiede al TCP di chiudere la connessione. Adesso si entri nel dettaglio della fase di trascrizione dei messaggi scambiati tra un client SMTP (C) e un server SMTP (S). L'hostname del client è crepes.fr e il nome host del server è hamburger.edu. Nel seguente esempio, le righe di testo ASCII precedute da C: sono esattamente le linee che il client invia nel suo socket TCP, e le linee di testo ASCII precedute da S: sono esattamente le linee che il server invia nel suo socket TCP. Il seguente dialogo inizia appena viene stabilita la connessione TCP.
S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr ... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Ti piace il ketchup? C: Che ne dici dei sottaceti? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection
Nell'esempio precedente il client invia un messaggio ("Ti piace il ketchup? Che ne dici dei sottaceti?") Dal server di posta crepes.fr al server di posta hamburger.edu. Nell'ambito del dialogo, il client ha emesso cinque comandi: HELO (abbreviazione di HELLO), MAIL FROM, RCPT TO, DATA, e QUIT. Questi comandi sono auto esplicativi. Il client invia anche una linea costituita da un unico punto, che indica la fine del messaggio al server. (In gergo ASCII, ogni messaggio si conclude con CRLF.CRLF, dove CR e LF sono i codici per il ritorno a capo e avanzamento riga, rispettivamente. Il server risponde ad ogni comando. In ogni risposta inserisce un codice di risposta e alcune (opzionali) spiegazioni in inglese. Si ricordi che SMTP usa connessioni persistenti: se il server di posta di invio ha diversi messaggi da inviare allo stesso server di posta ricevente, può inviare tutti i messaggi sulla stessa connessione TCP. Per ogni messaggio, il client inizia il processo con una nuova MAIL FROM: crepes.fr, indica la fine del messaggio con un punto, e genera QUIT solo dopo che tutti i messaggi sono stati inviati.
Si consiglia vivamente di utilizzare Telnet per svolgere un dialogo diretto con un server SMTP. Per svolgere questo esercizio scrivere telnet servername 25 dove ServerName è il nome di un server di posta locale. Quando si esegue questa operazione, si sta semplicemente stabilendo una connessione TCP tra l'host locale e il server di posta. Dopo aver digitato questa riga, si dovrebbe ricevere immediatamente la risposta 220 dal server. Quindi inviare i comandi SMTP: HELO, MAIL FROM, RCPT TO, DATA, CRLF.CRLF, e QUIT al momento opportuno. Si suggerisce di documentarsi sulla possibilità di costruire, in un linguaggio di programmazione di propria conoscenza, un semplice User-Agent che implementa il lato client di SMTP, con il quale si potrà inviare un messaggio di posta elettronica a un destinatario arbitrario tramite un server di posta locale.
Adesso si confronterà brevemente SMTP con HTTP. Entrambi i protocolli sono usati per trasferire file da un host ad un altro: HTTP trasferisce file (chiamati anche oggetti) da un server Web a un client Web (di solito un browser); SMTP trasferisce file (cioè messaggi di posta elettronica) da un server di posta a un altro server di posta. Quando si trasferiscono i file, HTTP e SMTP utilizzano connessioni persistenti. Tuttavia, ci sono differenze importanti. In primo luogo, HTTP è principalmente un protocollo che comunica in una sola direzione, qualcuno carica le informazioni su un server Web e gli utenti utilizzano HTTP per estrarre le informazioni dal server secondo le proprie necessità. In particolare, la connessione TCP viene avviata dalla macchina che desidera ricevere il file.
SMTP è principalmente un protocollo che trasferisce il file dal server di posta sorgente al server di posta ricevente. In particolare, la connessione TCP viene avviata dalla macchina che vuole inviare il file.
Una seconda differenza, come accennato in precedenza, SMTP richiede che ogni messaggio, compreso il corpo di ciascun messaggio, sia in formato ASCII a 7 bit. Se il messaggio contiene caratteri che non sono ASCII (per esempio, caratteri con accenti) o contiene dati binari (come ad esempio un file immagine), il messaggio deve essere codificato in 7 bit ASCII. HTTP non impone questa limitazione ai dati.
Una terza differenza importante riguarda come un documento composto da testo e immagini (con eventualmente altri tipi di media) viene gestito. HTTP incapsula ogni oggetto nel suo messaggio di risposta HTTP. La Posta Internet pone tutti gli oggetti del messaggio in un unico messaggio.
Quando Alice scrive una lettera ordinaria a Bob, può includere tutti i tipi di informazioni ausiliarie sulla busta della lettera, come l'indirizzo di Bob, il suo indirizzo di ritorno. Analogamente, quando un messaggio di posta elettronica viene inviato da una persona all'altra, un'intestazione contenente informazioni ausiliarie precede il corpo del messaggio stesso. Queste informazioni ausiliarie sono contenute in una serie di righe di intestazione, che sono definite in RFC 5322. Le linee di intestazione e il corpo del messaggio sono separate da una riga vuota (cioè da CR+LF). RFC 5322 specifica il formato esatto per le linee di intestazione di posta così come il loro significato. Come con HTTP, ciascuna riga di intestazione contiene il testo in chiaro, costituito da una parola chiave seguita da due punti, e da un valore. Alcune delle parole chiave sono obbligatorie e altre sono facoltative. Ogni intestazione deve avere un campo From: e una riga header A:; L'header può contenere anche una riga di Subject:, così come altre linee di intestazione opzionali. È importante notare che queste righe di intestazione sono diverse dai comandi SMTP già visti (anche se contengono alcune parole comuni come "from" e "to"). I comandi in quella sezione erano parte del protocollo di sincronizzazione SMTP; le linee di intestazione esaminate in questa sezione fanno parte del messaggio di posta stesso.
Una tipica intestazione del messaggio potrebbe essere la seguente:
From: alice@crepes.fr To: bob@hamburger.edu Subject: Considerazioni sul significato della nostra esistenza.
L'intestazione del messaggio è seguita da una riga vuota e poi dal corpo del messaggio (in ASCII). È necessario utilizzare Telnet per inviare un messaggio a un server di posta che contiene alcune righe di intestazione, tra cui la riga di intestazione Subject:. Per fare questo, scrivere telnet servername 25, come discusso nella sezione precedente.
Una volta che SMTP recapita il messaggio dal server di posta di Alice al server di posta di Bob, il messaggio viene inserito nella casella di posta di Bob. Nel corso di questa discussione è stato tacitamente assunto che Bob legge la sua posta elettronica autenticandosi sul server e quindi usando un lettore di posta in esecuzione su tale host. Fino ai primi anni '90 questo era il modo standard. Ma oggi, l'accesso alla posta utilizza un'architettura client-server - un utente legge le e-mail con un client che viene eseguito sul sistema terminale dell'utente, per esempio, su un PC dell'ufficio, un computer portatile o uno smartphone. Eseguendo un client di posta su un PC locale, gli utenti godono di un ricco set di funzionalità, tra cui la possibilità di visualizzare i messaggi multimediali e gli allegati.
Dato che Bob (il destinatario) esegue il suo User-Agent sul proprio PC locale, è naturale pensare che il server di posta si trovi sul proprio PC locale. Con questo approccio, il server di posta di Alice dovrebbe dialogare direttamente con il PC di Bob. C'è un problema con questo approccio, però. Si ricordi che un server di posta gestisce le caselle postali e gestisce il lato client e il lato server di SMTP. Se il server di posta di Bob dovesse risiedere sul suo PC locale, allora il PC di Bob dovrebbe rimanere sempre acceso e connesso a Internet per ricevere nuova posta, che può arrivare in qualsiasi momento. Questo è impraticabile per molti utenti di Internet. Invece, un utente tipico esegue un programma User-Agent sul PC locale e accede alla sua casella di posta memorizzata su un server di posta condiviso sempre attivo. Questo server di posta è condiviso con altri utenti e viene in genere gestito dall'ISP dell'utente (ad esempio, università o società).
Si segua, adesso, il percorso seguito da un messaggio di posta elettronica quando viene inviato da Alice a Bob. Si è appena appreso che, ad un certo punto, lungo il percorso, il messaggio di posta elettronica deve essere depositato nel server di posta di Bob. Questo potrebbe essere fatto semplicemente facendo inviare il messaggio direttamente dall'User-Agent di Alice al server di posta di Bob. E questo potrebbe essere fatto con SMTP - in pratica, SMTP è stato progettato per trasferire le e-mail da un host all'altro. Tuttavia, in genere l'User-Agent del mittente non dialoga direttamente con il server di posta del destinatario. Invece, come mostrato in Figura, l'User-Agent di Alice utilizza SMTP per depositare il messaggio di posta elettronica nel suo server di posta, quindi il server di posta di Alice utilizza il protocollo SMTP (come un client SMTP) per inoltrare il messaggio di posta elettronica al server di posta di Bob. Perchè la procedura avviene in due fasi? Soprattutto perchè senza l'inoltro attraverso il server di posta di Alice, l'User-Agent di Alice non potrebbe ricevere l'eventuale notifica che il server di posta di destinazione è irraggiungibile. Avendo Alice depositato prima l'e-mail nel proprio server di posta, il server di posta di Alice può ripetutamente provare a inviare il messaggio al server di posta di Bob, ad esempio ogni 30 minuti, fino a quando il server di posta di Bob diventa operativo. (E se il server di posta di Alice è spento, deve lamentarsi con il suo amministratore di sistema!). La RFC definisce come i comandi SMTP possono essere utilizzati per trasmettere un messaggio su più server SMTP.
Ma c'è ancora un elemento da prendere in considerazione. Come fa un destinatario come Bob, che usa un User-Agent sul proprio PC locale, ad ottenere i suoi messaggi, che risiedono su un server di posta all'interno dell'ISP di Bob? Si noti che l'User-Agent di Bob non può utilizzare il protocollo SMTP per ottenere i messaggi perchè ottenere i messaggi è un'operazione di prelievo, mentre SMTP è un protocollo di inserimento. Il problema viene risolto con l'introduzione di un apposito protocollo di accesso alla posta che trasferisce i messaggi dal server di posta di Bob al suo PC locale. Attualmente ci sono una serie di protocolli di accesso alla posta, tra cui Post Office Protocol - versione 3 (POP3), Internet Mail Access Protocol (IMAP) e HTTP. La Figura fornisce un riepilogo dei protocolli utilizzati per la posta Internet: SMTP è utilizzato per trasferire la posta dal server di posta del mittente al server di posta del destinatario; SMTP è utilizzato anche per trasferire la posta dall'User-Agent del mittente al server di posta del mittente. Un protocollo di accesso alla posta, come POP3, viene utilizzato per trasferire la posta dal server del destinatario all'User-Agent del destinatario.
POP3 è un protocollo di accesso alla posta estremamente semplice. Esso è definito in [RFC 1939], che è breve e abbastanza leggibile. Poichè il protocollo è così semplice, la sua funzionalità è piuttosto limitata. POP3 inizia quando l'User-Agent (client) apre una connessione TCP con il server di posta (server) sulla porta 110. Con la connessione TCP stabilita, POP3 progredisce attraverso tre fasi: l'autorizzazione, la transazione e l'aggiornamento.
Durante la fase di autorizzazione, l'User-Agent invia il nome utente e la password (in chiaro) per autenticare l'utente. Durante la fase di transazione l'User-Agent recupera i messaggi, e può anche contrassegnare i messaggi per l'eliminazione, rimuovere i segni di cancellazione, e ottenere statistiche di posta. La terza fase, l'aggiornamento, si verifica dopo che il client ha emesso il comando quit, che termina la sessione POP3; in questo momento, il server di posta elimina i messaggi che sono stati contrassegnati per l'eliminazione.
In una transazione POP3, l'User-Agent invia comandi e il server risponde ad ogni comando con un messaggio. Ci sono due possibili risposte: +OK (a volte seguita dai dati da server a client), utilizzata dal server per indicare che il comando precedente era stato correttamente interpretato; e -ERR, utilizzata dal server per indicare che c'era qualcosa di sbagliato nel comando precedente.
La fase di autorizzazione ha due comandi principali: <username> user e pass <password>. Per illustrare questi due comandi, si consiglia di avviare una sessione telnet direttamente in un server POP3, utilizzando la porta 110, e scrivendo questi comandi. Siuspponga che mailserver è il nome del server di posta. Si vedrà qualcosa di simile:
telnet mailServer 110 +OK POP3 server ready user bob +OK pass hungry +OK user successfully logged on
Se si sbaglia l'ortografia di un comando, il server POP3 risponderà con il messaggio -ERR.
Adesso si illustra brevemente la fase di transazione. Un User-Agent che utilizza POP3 spesso può essere configurato (dall'utente) per "scaricare ed eliminare" o per "scaricare e conservare". La sequenza di comandi emessi da un User-Agent POP3 dipende da quale di questi due modi è in funzione sull'User-Agent. In modalità download-and-delete, l'User-Agent emetterà i comandi list, retr, e dele. Come esempio, si supponga che l'utente abbia due messaggi nella sua casella di posta. Nel dialogo qui sotto, C: (che sta per Client) è l'User-Agent e S: (sta per Server) è il server di posta.
L'operazione avrà un aspetto simile:
C: list S: 1 498 S: 2 912 S: . C: retr 1 S: (blah blah ... S: ................. S: ..........blah) S: . C: dele 1 C: retr 2 S: (blah blah ... S: ................. S: ..........blah) S: . C: dele 2 C: quit S: +OK POP3 server signing off
Il programma utente prima chiede al server di posta di elencare le dimensioni di ciascuno dei messaggi memorizzati. L'User-Agent recupera ed elimina ogni messaggio dal server. Si noti che dopo la fase di autorizzazione, l'User-Agent impiega solo quattro comandi: list, retr, dele, e quit. La sintassi per questi comandi è definita nella RFC 1939. Dopo aver elaborato il comando quit, il server POP3 entra nella fase di aggiornamento e rimuove i messaggi 1 e 2 dalla casella postale.
Un problema con questa modalità download-and-delete è che il destinatario, Bob, ogni volta che consulta la sua posta potrebbe usare macchine diverse, per esempio, il suo PC in ufficio, il suo PC domestico e il suo computer portatile. La modalità download and delete partiziona i messaggi di posta di Bob su queste tre macchine; in particolare, se Bob legge un messaggio nuovo sul suo PC in ufficio, egli non sarà in grado di rileggere il messaggio dal suo portatile a casa. In modalità scarica e mantieni, l'User-Agent lascia i messaggi sul server di posta dopo averli scaricati. In questo caso, Bob può rileggere i messaggi da macchine diverse; può accedere ad un messaggio dal PC di ufficio e accedervi più tardi nel corso della settimana da casa.
Durante una sessione POP3 tra un User-Agent e il server di posta, il server POP3 mantiene alcune informazioni sullo stato; in particolare, tiene traccia dei messaggi che gli utenti hanno contrassegnato "da eliminare". Tuttavia, il server POP3 non trasporta informazioni sullo stato tra le sessioni POP3. Questa mancanza di informazioni sullo stato tra le sessioni semplifica notevolmente l'implementazione di un server POP3.
Con l'accesso POP3, una volta che Bob ha scaricato i suoi messaggi sulla macchina locale, può creare cartelle di posta e spostare i messaggi scaricati nelle cartelle. Bob può quindi eliminare i messaggi, spostare messaggi tra cartelle e ricercare i messaggi (per nome del mittente o per oggetto). Ma questo paradigma, cioè le cartelle e i messaggi nella macchina locale, pone un problema per l'utente che non usa una postazione fissa e che preferisce mantenere una gerarchia di cartelle su un server remoto, a cui può accedere da qualsiasi computer. Questo non è possibile con POP3, il protocollo POP3 non prevede alcun mezzo per un utente di creare cartelle remote e conservare messaggi nelle cartelle.
Per risolvere questo e altri problemi, è nato il protocollo IMAP, definito in RFC 3501. Come POP3, IMAP è un protocollo di accesso alla posta. Ha molte più funzioni rispetto a POP3, ma è anche molto più complesso, di conseguenza lo sono le implementazioni lato client e lato server. Un server IMAP assocerà ogni messaggio con una cartella; quando un primo messaggio arriva al server, è associato alla cartella "Posta in arrivo" del destinatario. Il destinatario può quindi spostare il messaggio in una nuova cartella creata dall'utente, leggere il messaggio, eliminare il messaggio, e così via. Il protocollo IMAP fornisce comandi per permettere agli utenti di creare cartelle e spostare i messaggi da una cartella ad un'altra. IMAP fornisce anche i comandi che consentono agli utenti di cercare nelle cartelle remote i messaggi che corrispondono a criteri specifici. Si noti che, a differenza di POP3, un server IMAP mantiene informazioni sullo stato dell'utente tra le sessioni IMAP. Per esempio, i nomi delle cartelle e quali messaggi sono associati con le cartelle.
Un'altra caratteristica importante di IMAP è che ha comandi che consentono ad un User-Agent di ottenere i componenti dei messaggi. Ad esempio, un User-Agent può ottenere solo l'intestazione di un messaggio o solo una parte di un messaggio MIME. Questa funzione è utile quando vi è una connessione a bassa larghezza di banda (ad esempio, un collegamento modem a bassa velocità) tra l'User-Agent e il relativo server di posta. Con una connessione a bassa larghezza di banda, l'utente può decidere di non scaricare tutti i messaggi nella sua casella di posta, in particolare evita messaggi lunghi che potrebbero contenere, ad esempio, una clip audio o video.
Sempre più utenti utilizzano la posta elettronica attraverso i browser web. Hotmail ha introdotto un accesso basato sul Web a metà degli anni '90. Ora si sono diffusi servizi di e-mail accessibili via Web forniti da Google, Yahoo!, così come quasi tutte le principali università e società. Con questo servizio, l'User-Agent è un comune browser, e l'utente comunica con la sua casella e-mail remota via HTTP. Quando un destinatario, come Bob, vuole accedere a un messaggio nella sua casella di posta, il messaggio di posta elettronica viene inviato dal server di posta di Bob al browser di Bob utilizzando il protocollo HTTP anzichè il protocollo POP3 o IMAP. Quando un mittente, come Alice, vuole inviare un messaggio di posta elettronica, questo viene inviato dal proprio browser al suo server di posta su HTTP anzichè su SMTP. Alice, però, continua a inviare messaggi e a ricevere messaggi da altri server di posta tramite SMTP.