Nei sabati uggiosi capita di giocare con le tecnologie. Questo esercizio serve a tenersi “sul pezzo” come “makers” , nel senso che non mi piacciono gli architetti di sistema che si mettono a scrivere le cose su Powerpoint e basta. Ma a volte capita di fare “mescolanze”. Per “mescolanza” intendo il gesto di mescolare una tecnologia molto vecchia con una nuova. E’ divertente perche’ vi fa capire “come poteva essere il mondo se”.
Prendiamo i vecchi protocolli del passato: NNTP, detto anche “news” o “usenet”. Si trattava di servizi che scrivevano su una precisa directory, che era in genere /var/spool/news, (a meno di sistemi piu’ sofisticati capaci di usare dischi e file in modalita’ raw) e che furono i primi “forum” della rete. Chi ha meno di 15 anni di vita su internet probabilmente non li ricorda, oggi sopravvivono ancora quelli di mane, ma non e’ questo il punto.
Avete mai configurato un server news? Di per se’ non era difficile. O meglio, la parte locale era quasi banale. Il problema vero era il trasporto. Oh, niente di trascendentale, nel senso che alla fine ci si riusciva. Il problema era l’infrastruttura. Essa era cosi’ centralizzata in pochi servers , che venivano gestiti da chi aveva servers con IP statico (normalmente ISP) che alla fine quando gli ISP decisero di uccidere il protocollo, non ci fu nulla da fare.
Era si’ possibile che qualche volontario si mettesse a tenere un server news, ma la piccola quantita’ di persone che potevano tenere una macchina con un server NNTP era limitante. Infatti, Usenet mori’.
Ma adesso supponiamo per ipotesi che ci sia interesse.
Abbiamo detto che le news sono tenute in una precisa cartella, /var/spool/news/*
E abbiamo dei software che permettono di replicare dei filesystem, come per esempiosyncthing
Allora, che succede se replichiamo la cartella su un portatile linux (armato che so io di un sn o di un leafnode) e tutti usiamo un lettore come pan , puntato su “localhost”?
Beh, e’ semplice: che abbiamo ricreato un’infrastruttura Usenet senza bisogno di IP statici. E senza bisogno di complessi meccanismi come uucp da configurare: quando un messaggio viene postato su localhost, se ne va a spasso per tutto il cluster di syncthing.
Ora, io ricordo il periodo della Satrapia di Usenet, quando tutti dipendevano da pochi tiranni che a volte concedevano la grazia di darvi un qualche tipo di liberta’ di espressione. E ricordo bene quale fosse la fonte del loro potere: l’infrastruttura. Essi possedevano l’unica infrastruttura capace di avere server nntp. Se i newsgroups fossero sopravvissuti sino ad ora, o meglio se fosse sopravvissuto l’interesse verso di essi, oggi i “ribelli” avrebbero gia’ costruito la propria infrastruttura usenet, semplicemente usando btsync, o syncthing.
Adesso proviamo a fare un passo indietro.
La posta che viene scaricata sui miei serverINI di casa arriva in un folder di tipo MAILDIR, dentro ~/mail , cioe’ in una cartella contenuta dentro la mia directory di base. Allora devo usare una vpn e configurare un server IMAP se la voglio leggere.
Ma non e’ indispensabile che le cose vadano cosi’.
Riprendiamo in mano btsync o syncthing. Mettiamoli a girare sui server che ricevono la posta.
Poi replichiamo , usando DHT o BEP, la cartella su un altro portatile (per fare un esempio).
A questo punto, vi bastera’ settare il vostro programma di email (es. thunderbird) per leggere una cartella locale, e avete fatto: non avete piu’ bisogno del trasporto IMAP o POP3 per scaricare.
Stessa cosa succede col server smtp. Uso un server locale, che cerca di usare un relay inesistente. Poiche’ non riesce ad usare un relay che non si risolve sui DNS, la posta rimane in coda, nello spool. Ma lo spool e’ duplicato sul server smtp che gira sul raspberry di casa. E da li’ la posta puo’ uscire.
Questo sistema bypassa anche i DNS, e i loro campi MX, per dire. Se configuriamo il server SMTP “pippo” per rispondere ad alcuni domini inventati come se fossero locali, tipo
tuamadre.sesso
quando sul server SMTP “pluto” il messaggio viene inviato verso “[email protected]” esso rimane in coda, per il tempo che abbiamo ordinato al server di aspettare per la ricomparsa del relay. Ora , nel momento in cui la directory di spool di “pluto” viene duplicata sul server “pippo”, che invece crede di dover ricevere la mail per il dominio “tuamadre.sesso” , la posta viene mandata alla cartella locale “hitler”.
In questo modo, cioe’, abbiamo completamente bypassato la necessita’ dei campi MX sui server: se vogliamo che i server comunichino, e vogliamo crearci la nostra rete privata di email, non dobbiamo fare altro che accordarci sui nomi da configurare sui server, e poi iniziare a condividere la posta.
Chiaramente il sistema ha un problema di sicurezza, nel senso che se il serber SMTP “gambadilegno” ha deciso di prendere la posta per “tuamadre.sesso”, una copia di questa email finira’ nella cartella locale di “gambadilegno”. Motivo per cui una simile infrastruttura funziona bene solo a patto di usare qualcosa come GPG.
In definitiva, cioe’, potremmo creare una completa struttura di email “alternativa” solo usando programmi opensource, ancora in uso, e sopra metterci sopra una bella infrastruttura DHT o BEP, evitando tutti i protocolli di trasporto, e pure la tirannia del DNS.
Perche’ questo esercizio e’ importante?
Perche’ vi fa capire una cosa: che moltissimi dei “grandi genii”, moltissime tecnologie come “il cloud” , spesso sono li’ per pura coincidenza.
Sono li’ soltanto perche’ i protocolli DHT si sono sempre usati per condividere dei meri file, e pochi si sono accorti del fatto che, alla fine, “duplicare file” su Unix e’ una cosa potentissima, se non onnipotente.
E’ assolutamente possibile, ripeto, costruire una infrastruttura MOBILE e NASCOSTA di email, semplicemente installando un server smtp locale con un relay inventato, condividere la directory di spool per la posta in uscita (in questo caso, anche quella in bouncing se pensiamo a postfix) , e quando la coda viene duplicata su un server che invece ha istruzioni di ricevere posta per quel dominio, finira’ nella cartella locale.
Questo si puo’ fare su qualsiasi portatile perche’ oggi i portatili maneggiano potenze non indifferenti, e in questo modo si possono creare infrastrutture potenti , distribuite, e praticamente anonime.
Procedendo in questo modo su vasta scala, e pacchettizzandolo in un .deb, e’ possibile costruire una infrastruttura di email completamente parallela, anonima, replicata, mobile, senza dipendenze da provider e DNS.
Ma specialmente, senza possedere nessuna infrastruttura propria. Potrei fare il pacchetto .deb domani, con dentro postifx configurato come non-relay, una copia di btsync configurata per un dato cluster, la configurazione di Thunderbird con localhost come smtp server e come /var/mail/username come destinazione, e un dialogo che proponga di scegliere il nome di dominio.
Sicuramente questo e’ il punto di vista del sistemista: se fossi un programmatore accanito potrei pensare ad un ibrido tra syncthing e un server SMTP, capace di ricevere posta su localhost, metterla in uno spool, condividere lo spool, ricevere gli spool condivisi, ed eventualmente i domini coincidano, mettere la cartella nelle caselle locali.
E con un solo software, avreste un sistema di email clandestino, intracciabile (tutti scaricano una copia dello spool, ma solo alcuni ne fanno uso in locale, e non c’e’ modo di sapere chi da fuori) .
Perche’ questo volo pindarico? Per dire che e’ una pura fortuna che Gmail sia nato prima dei vari BEP e DHT. Se fossero arrivati prima loro, e ci fosse stato qualcuno a proporre l’idea, probabilmente adesso avreste la vostra mail svincolata dai DNS e dal bisogno di IP statici.
E’ cosi’ diverso da quanto fatto da google? Apparentemente si, ma in realta’ non troppo: in fondo, anche google ha preso due protocolli “legacy” e li ha migliorati sbattendoci sopra un’altra feature, che era l’interfaccia web, un pochino piu’ moderna. Se un’altra azienda avesse pensato di usare il protocollo di Torrent per farvi scaricare la posta, probabilmente oggi non ci sarebbe Gmail.
Molti dei social network non ci sarebbero se qualcuno avesse avuto l’idea di usare un sistema come btsync per condividere /var/spool/news, dal momento che, avendo un prodotto del genere, sarebbero proliferati i server news, anche sui PC domestici, e la gente non sarebbe fuggita dai satrapi delle gerarchie “ufficiali”.
Giocare con la mescolanza di vecchi e nuovi protocolli vi mostra, in realta’, quanto sia stato un caso che i grandi di oggi siano grandi. In realta’ hanno migliorato cose esistenti, ma questo miglioramento e’ arrivato solo qualche istante prima di un altro, che avrebbe potuto salvare la tecnologia esistente.
