Essendo il più grande fornitore al mondo di email crittografata, lavorare con IMAP (Internet Message Access Protocol) è qualcosa che facciamo quotidianamente. IMAP è fondamentale per l’app Proton Mail Bridge, che ti permette di aggiungere la crittografia di Proton Mail a client di posta elettronica standard, come Outlook, Thunderbird o Apple Mail.
Ma IMAP va oltre Proton Mail. È uno dei due protocolli standard di recupero email (l’altro è POP) che quasi ogni app di posta elettronica utilizza per accedere e gestire le tue email. Quindi, in sostanza, alimenta la posta elettronica a livello globale.
Oggi presentiamo Gluon(new window), una nuova libreria IMAP scritta nel linguaggio di programmazione Go, progettata per essere ad alte prestazioni, affidabile, amichevole per gli sviluppatori e, soprattutto, open-source.
Insieme al lancio di Gluon, stiamo anche rilasciando una nuova versione del Proton Mail Bridge che è alimentata da Gluon. Come risultato delle innovazioni sottostanti, il nuovo Proton Mail Bridge è 1000% più veloce, molto più affidabile e compatibile anche con più client di posta elettronica.
Perché creare una nuova libreria IMAP?
La posta elettronica deve essere affidabile, ma deve anche essere ad alte prestazioni, soprattutto perché la dimensione tipica della casella di posta è cresciuta notevolmente nell’ultimo decennio. Molte implementazioni IMAP open-source tendono ad ottimizzare per uno e non per l’altro, portando a compromessi o bug piuttosto significativi.
Gluon cerca di colmare questa lacuna e superare i limiti nelle esistenti librerie IMAP open-source, che spesso sono scarsamente mantenute o non completamente scalabili. Gluon fa ciò utilizzando un’architettura che si basa su un sistema di “istantanee”.
I client IMAP si riferiscono tipicamente ai messaggi tramite il loro “numero di sequenza”, la posizione del messaggio nella casella di posta. Il primo messaggio ha il numero di sequenza “1”, il secondo “2”, e così via. Se un client vuole segnare un messaggio come “letto”, invierà un comando al server come “segna il messaggio 5 come letto”. Ma cosa succede se un altro client ha cancellato il quarto messaggio nella casella di posta? I numeri di sequenza di tutti i messaggi successivi al messaggio cancellato verranno spostati in basso di uno; il client che ha inviato il comando “segna il messaggio 5 come letto” ora si riferisce a un messaggio diverso da quello inteso.
I server IMAP (che includono applicazioni come il Proton Mail Bridge) devono essere in grado di gestire questa situazione. Quando un client sposta messaggi dentro o fuori da una casella di posta, il server deve notificare tutti gli altri client delle modifiche in modo che possano aggiornare la propria visione della casella di posta. E fino a quando i client non hanno ricevuto l’aggiornamento, il server deve ricordare cosa ogni client crede che la casella di posta sembri per interpretare correttamente i comandi del client.
Nell’esempio precedente, il server deve sapere che il client che ha inviato il comando “segna il messaggio 5 come letto”, si riferisce al messaggio che era originariamente in posizione 5, non al messaggio che attualmente si trova in posizione 5.
Questo tipo di scenario può verificarsi più frequentemente nell’uso moderno della posta elettronica, dove l’utente potrebbe utilizzare Proton Mail sul web su un dispositivo, utilizzare le app mobili in movimento e poi utilizzare un client desktop tramite Proton Mail Bridge su un desktop, tutti i quali potrebbero non essere online contemporaneamente.
Un altro scenario è quello delle app di posta elettronica che spesso utilizzano più connessioni simultanee alla tua casella di posta per velocizzare le cose, ma questo può poi portare a problemi di concorrenza. Utilizzando un sistema di istantanee, Gluon assegna a ogni client IMAP la propria “istantanea” della casella di posta selezionata. Ogni istantanea mantiene la visione unica del client della casella di posta, permettendo al server di interpretare esattamente a quale messaggio il client si riferisce in qualsiasi momento, indipendentemente dalle azioni eseguite da altri client. Questo garantisce un’esperienza email stabile e coerente per l’utente.
Come abbiamo scritto Gluon
Il nostro primo passo nella scrittura di Gluon è stato generare un parser IMAP dalla sintassi fornita in RFC3501(new window). Abbiamo usato ANTLR4(new window), un popolare generatore di parser, per creare un parser che potesse analizzare comandi e risposte IMAP secondo le specifiche. Questo ci ha permesso di concentrarci sull’implementazione della logica del protocollo IMAP piuttosto che sull’analisi e validazione degli input.
Una volta ottenuto il parser, abbiamo scritto il tipo base di server per Gluon. Il tipo di server attende connessioni TCP in entrata e avvia una “sessione IMAP” eseguita in una goroutine separata (un thread leggero e verde usato nel linguaggio di programmazione Go) per gestire ogni connessione.
La sessione ha un compito semplice:
- Leggere un comando del cliente.
- Analizzare il comando.
- Chiamare il gestore del comando corretto.
- Infine, inviare le risposte necessarie al cliente.
Questo design consente inoltre a Gluon di gestire più connessioni client contemporaneamente, con ogni sessione che gestisce il proprio stato.
Una delle sfide principali nell’implementazione di un server IMAP è la gestione sia degli stati persistenti che degli stati per sessione delle caselle di posta. Lo stato persistente si riferisce ai messaggi che sono effettivamente presenti in una casella di posta selezionata, mentre lo stato per sessione si riferisce ai messaggi che ogni cliente crede siano attualmente in una casella di posta selezionata.
In Gluon, utilizziamo un database SQL per memorizzare lo stato IMAP persistente, come le caselle di posta e i messaggi che un utente possiede. Inoltre, il database SQL consente una gestione più rapida ed efficiente dei comandi grazie all’intelligente pre-caricamento e indicizzazione.
Gestire lo stato per sessione è stato più complicato, in quanto dipende interamente dalle risposte IMAP inviate a un cliente in un dato momento. Per modellare ciò, abbiamo definito un tipo che tiene in memoria un elenco di ID messaggi, UID e flag. Questo elenco viene popolato dal database quando un cliente seleziona per la prima volta una casella di posta. Questo approccio ci permette di gestire in modo efficiente lo stato per sessione e di gestire molti comandi IMAP interamente in memoria senza richiedere letture su disco, portando a prestazioni molto più veloci.
Per sincronizzare lo stato per sessione tra più client connessi, Gluon utilizza un sistema di “risponditori”. Questi sono tipi che incapsulano un cambiamento di stato e, quando eseguiti, vengono convertiti in risposte IMAP. Quando un cliente esegue un’azione (come segnare un messaggio come letto) che cambierebbe lo stato di un altro cliente, il backend crea un risponditore per l’azione e lo spinge allo stato interessato. Lo stato interessato rimane invariato fino a quando il risponditore viene eseguito, a quel punto viene aggiornato e viene inviata una corrispondente risposta IMAP al cliente. Questo approccio consente a Gluon di gestire in modo efficiente lo stato per sessione garantendo al contempo la coerenza tra più client.
Nel costruire il supporto di Gluon per ogni comando IMAP, abbiamo utilizzato lo sviluppo guidato dai test. Abbiamo creato un framework di test che ci ha permesso di specificare come dovrebbe apparire un’intera sessione IMAP, indicando i comandi del cliente e le risposte del server attese.
Abbiamo prima scritto un test per ogni comando IMAP (spesso copiato direttamente da RFC3501) e poi implementato la gestione del comando per fare in modo che il test fosse superato. Inoltre, per garantire la correttezza e l’affidabilità di Gluon, abbiamo usato Dovecot(new window), il server IMAP più popolare al mondo, come implementazione di riferimento, e abbiamo eseguito test di correttezza utilizzando lo strumento di test di Dovecot, imaptest(new window).
L’ultimo passo è stato integrare Gluon nel Proton Mail Bridge. Abbiamo progettato Gluon affinché integrarlo in qualsiasi applicazione fosse semplice come implementare la sua interfaccia “Connector”. Il Connector mantiene sincronizzati Gluon e gli stati esterni (lo stato Proton).
Ad esempio, quando un client IMAP segna un messaggio come letto, il connector segna quel medesimo messaggio come letto sul server Proton. Quando il server Proton riceve un messaggio, il connector lo scarica, lo decrittografa e lo inserisce nella giusta casella di posta Gluon.
Questo design estensibile rende possibile utilizzare Gluon con quasi ogni applicazione che richiede IMAP.
Privacy senza compromettere le prestazioni
All’inizio di quest’anno, abbiamo messo in beta testing la nuova versione 3 del Proton Mail Bridge (potenziato da Gluon), e il feedback degli utenti è stato in linea con i nostri test di prestazione che indicano un miglioramento della velocità del 1000%. Speriamo che rilasciando Gluon come software open-source, possiamo abilitare una nuova generazione di software per email moderni più capaci di gestire le esigenze degli utenti contemporanei.
Come azienda open-source, invitiamo altri a utilizzare, esaminare e contribuire al codice e, come con altri progetti open-source che Proton mantiene(new window), ci impegniamo a mantenere questa libreria a lungo termine.
La nostra missione è rendere la privacy accessibile e ampiamente disponibile online, e un Proton Mail Bridge potenziato da Gluon che rende l’email crittografata end-to-end disponibile su qualsiasi applicazione di posta elettronica desktop è un passo importante verso il raggiungimento di questo obiettivo.
Come sempre, grazie per il tuo supporto e non dimenticare di condividere il tuo feedback e i tuoi pensieri con noi su Reddit(new window), e Twitter(new window).
Questo lavoro è stato condotto da James Houlahan, Leander Beernaert, Jakub Cúth, Xavier Michelon, Romain Le Jeune, Gjorgji Slamkov, Alexander Khusanov, Gabor Meszaros e Andrzej Szafranski del team Proton Mail.
