Posta elettronica
- Segnalazioni: È richiesto un livello medio di preparazione
- Hosting Fattispazio!: a cura di infocom.uniroma1
La posta elettronica (electronic mail) è un servizio di comunicazione Internet basato sulla consegna asincrona di PDU contenenti testo, e/o altri file allegati. I soggetti mittente e destinatario di una email sono individuati da URI applicative dal formato
Il Simple Mail Transfer Protocol (SMTP) viene definito nel 1982 dalla RFC 821, scritta da John Postel, e da allora aggiornata da altri documenti (RFC 2821 e molti altri, fino a RFC 5321). Il protocollo SMTP è attuato da una applicazione-demone, in ascolto delle connessioni TCP sulla porta 25. La consegna a destinazione di un messaggio avviene secondo uno schema di immagazzinamento e rilancio, ad opera dei server di posta indicati anche come agenti, ovvero intermediari, detti Mail Transfer Agent (MTA).
Questi dialogano tra loro in SMTP, e possono rivestire sia il ruolo di server, che quello di client, occupandosi di inoltrare il messaggio in direzione della destinazione.
Notiamo che come misura antispam, il ricevente può verificare (tramite DNS) che il nome a dominio dell'SMTP mittente si risolva effettivamente nell'indirizzo da cui risulta provenire la connessione, e in caso contrario, chiuderla. Poi, dopo alcune verifiche sull'effettiva esistenza dei destinatari, la transazione procede citando il mittente, i destinatari, e quindi il corpo del messaggio, eventualmente preceduto da altri header testuali, e terminato da una linea isolata, contenente un solo punto.
Il colloquio SMTP si svolge sia tra il MUA del mittente (che svolge un ruolo di client SMTP) ed il suo server SMTP di uscita, sia tra il server SMTP dell'ISP del mittente (trasformato in client), e quello del destinatario.
Riportiamo appresso il risultato di un capture, in cui le linee prefisse con S: e C: indicano rispettivamente le stringhe emesse da server e client.
Notiamo le seguenti cose.
Se in questa, infatti, compare la stringa ESMTP anziché SMTP, allora vuol dire che il server supporta le estensioni. Il client a sua volta, può manifestare l'intenzione di tentare di sfruttare qualcuna delle estensioni disponibili, asserendo a sua volta la stringa EHLO, a cui il server risponde con l'elenco delle estensioni disponibili, ognuna definita in una diversa RFC, come riportato presso IANA. Altrimenti, nel caso in cui il client si presenti con un semplice HELO, si procede con un comportamento strettamente conforme alla RFC 821. Tra le estensioni presenti nell'esempio sopra riportato, notiamo
Dato che invece gli header devono contenere sempre e comunque caratteri US-ASCII, e che a seguito dell'introduzione dello standard MIME, negli header è comunque presente l'informazione a riguardo delContent-Transfer-Encoding, si ottiene che l'ESMTP ricevente ha comunque modo di conoscere l'Encoding del body per questa via, e quindi l'uso di questo parametro è divenuto opzionale.
Si veda infatti questo capture, per un esempio di messaggio contenentele lettere accentate àèéìòù offerte dall'alfabeto ISO-8859-15, e trasferito ad 8 bit;
In origine, permetteva solo l'invio della password in chiaro, mentre le successive estensioni, permettono l'uso dei metodi SASL, e di TLS.
E' la contrazione di Web-based email, e consiste in un portale web da cui si può accedere alla propria casella di posta elettronica, in modo da poterla leggere anche da una postazione occasionale, tipicamente pubblica, permettendo inoltre di spedire posta. In questo caso l'unico protocollo che sembrerebbe essere in gioco, è il dialogo HTTP che si svolge tra il nostro browser, ed il server web che ci mostra le pagine del portale. In effetti, le pagine sono generate da un CGI, ossia un programma in esecuzione presso il computer che ospita il server web, e che a sua volta opera in modalità client nei confronti dei procolli email, ossia SMTP per spedire, ed IMAP per ricevere.
Dai tempi in cui venne definito il primo insieme di caratteri per telecomunicazioni (il codice Morse del 1840), l'associazione tra codici numerici e simboli linguistici si è via via estesa, fino alla definizione di un insieme (Universal Caracter Set, o UCS, o Unicode) che possa rappresentare in modo congiunto i simboli previsti da tutte le lingue del mondo, in modo da poter essere utilizzato per i contenuti da scambiare a livello planetario, come avviene in Internet. Ma andiamo con ordine.
Una codepage di largo uso in Europa, è stata la numero 850, indicata come Multilingual (Latin-1), poi sostituita con windows-1252, e quindi con la sua evoluzione ISO 8859-1, detto anche alfabeto Latin-1, definito da ISO e IEC, e mostrato nella tabella sottostante, in cui notiamo che i codici 00–1F, 7F, e 80–9F non sono assegnati a caratteri.
Questa è divenuta la codifica di default anche per le pagine distribuite dai server Web, e supporta: Africano, Basco, Catalano, Danese, Olandese, Inglese, Faeroese, Finlandese, Francese, Galizio, Tedesco, Islandese, Irlandese, Italiano, Norvegese, Portoguese, Scozzese, Spagnolo, e Svedese. Successivamente, l'ISO 8859-1 si è ancora evoluto in ISO 8859-15, o Latin-9, che sostituisce ad alcuni simboli molto poco usati (¤, ¦, ¨, ´, ¼, ½, e ¾) alcuni rari caratteri francesi e finlandesi, e il simbolo di valuta dell'euro €.
In tutti gli alfabeti ISO 8859-x, la codifica dei primi 127 caratteri (non di controllo) è la stessa dell'US-ASCII, quindi i files scritti con il secondo alfabeto, sono automaticamente validi anche nel primo.
In particolare, la trasformazione dell'ultima riga avviene interpretando il valore 0-63 dei gruppi di 6 bit riportati nella penultima riga, come un indice nella tabella di conversione riportata qui sotto, in cui compare un sottoinsieme di 64 caratteri stampabili dell'alfabeto US-ASCII.
Nel caso in cui il testo di partenza non abbia un numero complessivo di byte multiplo di 3, si aggiungono a destra tanti zeri, quanti ne servono per completare l'ultimo gruppo di 6 bit in entrata. Quindi, se il numero di simboli BASE64 ottenuti non è un multiplo di quattro, si aggiungono alla codifica fino a tre simboli di uguale (=), in numero pari al numero di simboli mancanti, in modo da segnalarlo al ricevitore.
è interpretabile come Subject: ¡Hola, señor!. Notiamo, in questo caso, che avendo adottato come charset utf-8, la codifica per i caratteri ¡ (punto esclamativo rovesciato) e ñ utilizza due bytes, che con il transfer-encoding di tipo quoted-printable, divengono 6 caratteri US-ASCII.
Ogni parte inizia con una sua propria intestazione Content-type, seguita da una eventuale Content-transfer-encoding, seguita dal corpo della parte. I client dei destinatari che aderiscono alla specifica MIME ignorano (non visualizzano) quanto è presente prima del primo confine, che contiene un messaggio rivolto appunto ai possessori di client che non aderiscono a MIME. Questi ultimi infatti visualizzano il messaggio per intero, così come l'abbiamo mostrato sopra, ed in cui compare in testa l'avvertimento rivolto loro.
Notiamo che quando, come in questo caso, l'intestazione Content-Disposition (RFC 2183) assume il valore inline, il client di posta ricevente è istruito a visualizzare l'immagine subito di seguito alla prima parte testuale. Viceversa, una intestazione Content-Disposition: Attachment avrebbe determinato l'attesa di una esplicita decisione umana su cosa fare. Di seguito all'intestazione Content-Disposition possono essere presenti diversi parametri, come ad esempio il nome del file, da usare come suggerimento qualora si voglia salvare la parte su disco, ma anche eventualmente, data di creazione e di modifica, e dimensione.
Tecnicamente, i diversi server NNTP comunicano tra loro secondo il principio di mantenere sincronizzato l'insieme dei messaggi che ogni server riceve da parte degli utenti che vi si connettono, con quello degli altri server NNTP. Presso i server sono definiti i diversi argomenti di discussione, detti newsgroup, organizzati in gerarchie che categorizzano gli argomenti stessi in sotto-argomenti, e sotto-sotto argomenti. Considerando che Usenet ha una propagazione mondiale, e che ogni popolo ha pur sempre il diritto di discutere nella propria lingua, possiamo restringere il campo alla gerarchia in lingua italiana.
Per partecipare ad Usenet, la maggior parte dei lettori email offre la possibilità di definire un nuovo account news (anzichè email), configurando il newsserver a cui ci si desidera collegare, che in generale, corrisponde a quello ospitato presso il proprio provider. Infatti, come avviene per i server SMTP, anche i server NNTP negano l'accesso ai client esterni alla propria rete. In alternativa, esistono svariate iniziative che, in analogia al servizio di webmail, offrono una interfaccia web ai newsgroup, come a esempio Google e Roar, o Mailgate, che è stato un caso storico, ma poi venne chiuso. Anche se l'utilizzo dei newsgroup mediante client personale è più completo, e privo della pubblicità inserita dal portale, l'accesso web ha il vantaggio di non dipendere dalla conoscenza del proprio server NNTP, e può aiutare a farsi una idea.
I Bullettin Board Services si sono sviluppati parallelamente ai Newsgroup, e sono ormai quasi del tutto tecnologicamente superati, ma rappresentato tuttora un ottimo esempio di comunicazione assolutamente autogestita. Si tratta infatti, ancora una volta, di una rete di computer che mantengono sincronizzate le rispettive basi di messaggi, ma i collegamenti tra computer non si avvalevano della rete Internet, ma del modem su rete telefonica commutata, rimuovendo qualunque forma di dipendenza da fornitori di connettività dati. Attualmente, molte BBS oltre a fornire ai propri utenti un accesso via modem, sono altresì accessibili (per ironia) via Internet, che spesso usano anche per sincronizzarsi con gli altri nodi. Sebbene diverse BBS si possano accordare per mettersi in rete tra di loro in modo del tutto autonomo, esiste una rete mondiale di BBS che cooperano a mantenere viva una distribuzione globale alternativa, chiamataFidoNet.
La maggior parte di queste applicazioni opera con una modalità client-server, in cui ogni client fa capo ad unico server centralizzato, che implementa il protocollo di comunicazione nei confronti di tutti i client. Inoltre, la politica più diffusa, è quella di ostacolare lo sviluppo di prodotti di terze parti che si possano connettere a queste reti, tentando di fidelizzare i propri utenti all'uso del proprio client, tramite il quale si possono più facilmente introdurre estensioni e nuove caratteristiche. Solo da poco, alcuni di questi provider stanno seguendo un approccio di "apertura" reciproca (come Yahoo e MSN, oppure AIM e ICQ), comunque sempre dettato da motivazioni commerciali.
Cionostante, vi sono applicazioni tipicamente dell'Open Source, come ad esempio
Jabber - XMPP
Lo IETF ha pubblicato come RFC 3920, 21, 22 e 23, le specifiche dell'Extensible Messaging and Presence Protocol (XMPP), alla base del funzionamento della piattaformaJabber, e che offre una gamma veramente molto vasta di estensioni, sia stabili, che in via di sviluppo, che allo stadio di proposte.
La architettura XMPP prevede l'esistenza di Gateway che interfacciano la rete Jabber con quelle basate sui diversi protocolli di Messagging, come ad es. MSN o ICQ, permettendo ad un client Jabber, di comunicare con tutti gli altri. Una volta che un client Jabber si connette ad un server che implementa il gateway verso la rete di messaggistica desiderata, deve comunicare al server jabber l'identità e le credenziali con le quali può accedere all'altra rete; a quel punto, il server Jabber si connetterà alla diversa rete impersonando l'identità del client, comportandosi come un proxy, e convertendo le primitive del protocollo di un lato del gateway, in quelle del protocollo dell'altro versante.
mailto:
che rappresentano la domiciliazione dell'utente paolo presso un dominio internet.
Sebbene la consegna delle email sia attuata mediante applicazioni client-server, non accade praticamente mai che il mittente comunichi direttamente con il destinatario. Invece, sono dislocati in rete dei nodi intermedi detti server di posta, che dialogano tra loro mediante un protocollo applicativo denominato SMTP, e tramite i quali viene inoltrato il messaggio. Il primo server della catena è concettualmente simile al default gateway dello strato IP, ed è quello a cui il mittente consegna (fiducioso) il messaggio da spedire.
Questo primo server, una volta chiusa la conessione TCP su cui avviene la prima transazione SMTP, può a sua volta inviare (trasformandosi in client) il messaggio verso un altro server SMTP di sua scelta, oppure direttamente verso il server che gestisce la posta per il dominio presso il quale risiede l'utente destinatario. Il messaggio rimarrà li in giacenza, finchè l'intestatario della URI di destinazione non lo preleverà, ricorrendo ad un diverso protocollo.
Il Simple Mail Transfer Protocol (SMTP) viene definito nel 1982 dalla RFC 821, scritta da John Postel, e da allora aggiornata da altri documenti (RFC 2821 e molti altri, fino a RFC 5321). Il protocollo SMTP è attuato da una applicazione-demone, in ascolto delle connessioni TCP sulla porta 25. La consegna a destinazione di un messaggio avviene secondo uno schema di immagazzinamento e rilancio, ad opera dei server di posta indicati anche come agenti, ovvero intermediari, detti Mail Transfer Agent (MTA).
Questi dialogano tra loro in SMTP, e possono rivestire sia il ruolo di server, che quello di client, occupandosi di inoltrare il messaggio in direzione della destinazione.
Il mittente (umano) compone il messaggio da spedire mediante un Mail User Agent (MUA), che si comporta come un client SMTP, ed invia l'email ad un primo MTA di transito, o di uscita, o Outbound: l'SMTP serverdell'ISP di partenza. Questo a sua volta, assumendo ora il ruolo di client, inoltra il messaggio verso l'SMTP server situato presso il destinatario, che (attuando la funzione di Mail Delivery Agent, o MDA) salva localmente il messaggio ricevuto, in attesa che il destinario (umano) lo prelevi (con il suo MUA) per mezzo del protocollo POP3 o IMAP, e lo legga.
Configurazione
Tipicamente il MUA usato dal mittente è lo stesso applicativo usato anche per la ricezione, e spesso deve essere configurato manualmente, inserendo l'indirizzo del server SMTP a cui inoltrare l'email in uscita: nella pratica, questo dovrà essere proprio il server SMTP disponibile presso l'ISP tramite il quale ci si collega ad Internet. Infatti, per limitare il fenomeno dello spamming, ogni ISP configura il proprio server SMTP in modo che questo accetti la posta da recapitare, solo se proveniente da computer collegati tramite la propria stessa rete.
Non solo: sempre per il controllo dello spam, i server SMTP che operano dal lato di destinazione del collegamento SMTP, verificano che l'IP del mittente non sia segnalato in una DNSBL, oppure che non appartenga a lotti di indirizzi che gli ISP assegnano dinamicamente (ad es., via DHCP) ai loro utenti.
Non solo: sempre per il controllo dello spam, i server SMTP che operano dal lato di destinazione del collegamento SMTP, verificano che l'IP del mittente non sia segnalato in una DNSBL, oppure che non appartenga a lotti di indirizzi che gli ISP assegnano dinamicamente (ad es., via DHCP) ai loro utenti.
D'altra parte, esistono casi in cui il Server SMTP usato da un mittente casalingo non è quello del proprio ISP: ad esempio, si tratta del caso di una email inviata tramite una interfaccia webmail come Gmail, oppure qualora il computer mittente usi un server SMTP residente sul mededimo computer (rischiando però di vedersi l'email bloccata dai meccanismi anti-spam), oppure anche nel caso in cui il server SMTP accetti mittenti remoti purché in grado di autenticarsi.
Protocollo SMTP
Allo scopo di individuare l'MTA di destinazione di una email, il server SMTP interroga il DNS (vedi figura) per conoscere i record MX relativi al dominio di destinazione; quindi, intrattiene una transazione SMTP con il server di destinazione, del tipo di quella riportata in quest'esempio.Notiamo che come misura antispam, il ricevente può verificare (tramite DNS) che il nome a dominio dell'SMTP mittente si risolva effettivamente nell'indirizzo da cui risulta provenire la connessione, e in caso contrario, chiuderla. Poi, dopo alcune verifiche sull'effettiva esistenza dei destinatari, la transazione procede citando il mittente, i destinatari, e quindi il corpo del messaggio, eventualmente preceduto da altri header testuali, e terminato da una linea isolata, contenente un solo punto.
Il colloquio SMTP si svolge sia tra il MUA del mittente (che svolge un ruolo di client SMTP) ed il suo server SMTP di uscita, sia tra il server SMTP dell'ISP del mittente (trasformato in client), e quello del destinatario.
Riportiamo appresso il risultato di un capture, in cui le linee prefisse con S: e C: indicano rispettivamente le stringhe emesse da server e client.
| S: 220 smtp-out4.libero.it ESMTP Service (7.3.120) ready C: EHLO [192.168.120.40] S: 250-smtp-out4.libero.it S: 250-DSN S: 250-8BITMIME S: 250-PIPELINING S: 250-HELP S: 250 SIZE 30000000 C: MAIL FROM:<>; SIZE=358 S: 250 MAIL FROM:<>; OK C: RCPT TO:<>; S: 250 RCPT TO:<>; OK C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Message-ID: <>; C: Date: Mon, 05 Mar 2007 17:06:20 +0100 C: From: alef <>; C: User-Agent: Mozilla Thunderbird 1.5.0.9 (X11/20070103) C: MIME-Version: 1.0 C: To: C: Subject: test di capture dell'SMTP C: Content-Type: text/plain; charset=ISO-8859-15 C: Content-Transfer-Encoding: 7bit C: C: salute a tutti C: C: Ale C: . S: 250 <45D9993D01232796> Mail accepted C: QUIT S: 221 smtp-out4.libero.it QUIT |
Oggetti email
La RFC 5321 distingue tra envelope e content. L'envelope è inviato come una serie di unità di protocollo SMTP, e consiste dell'origine (MAIL FROM, a cui possono essere inviati messaggi di errore), di uno o piùrecipienti (RCPT TO), e di eventuali riferimenti ad estensioni. Il contenuto è quello inviato mediante l'unità di protocollo DATA, definito invece dalla RFC 5322, e consiste di due parti, le intestazioni (header) ed il corpo (body), la cui definizione è spesso integrata in accordo alle specifiche MIME (RFC 2045). Sia header che body sono trasmessi usando caratteri a 7 bit, inseriti in byte con il bit più significativo a zero, ed appartenenti all'alfabeto US-ASCII, tranne per l'eccezione prevista dall'estensione 8BITMIME per il body, e dalla sintassi Encoded Word per gli headers. Il messaggio è composto da linee terminate dalla sequenzaCR/LF (0D 0A in esadecimale, 13 10 in decimale), e di lunghezza massima di 1000 bytes.
Codici di risposta
Ogni risposta del SMTP server è del tipo reason-code reason-phrase, ovvero un numero seguito da una frase. I codici numerici possono essere usati da un programma per capire la risposta, mentre la frase è a beneficio della leggibilità, per l'operatore umano. Il significato dei codici di risposta può essere classificato nell'ambito di 5 categorie, individuate dalla prima cifra del corrispondente codice numerico, in accordo allo schema| reason code | categoria | significato |
| 1xx | Positive Preliminary Reply | seguirà una risposta ulteriore, prima che il comando richiesto sia completato |
| 2xx | Positive Completion Reply | il comando è stato eseguito, e si può iniziare una nuova richiesta |
| 3xx | Positive Intermediate Reply | ci si aspetta altro input da parte del client |
| 4xx | Transient Negative Completion Reply | manifestano un errore temporaneo, offrendo la possibilità di ripetere il comando che ha causato l'errore |
| 5xx | Permanent Negative Completion Reply | il comando non è stato accettato, l'azione non è stata intrapresa, ed il client è scoraggiato a ritentare |
Extended SMTP
L'Extended SMTP è definito dalle RFC 1869 e RFC 2821, ed il server ne annuncia il supporto, mediante la sua risposta iniziale.Se in questa, infatti, compare la stringa ESMTP anziché SMTP, allora vuol dire che il server supporta le estensioni. Il client a sua volta, può manifestare l'intenzione di tentare di sfruttare qualcuna delle estensioni disponibili, asserendo a sua volta la stringa EHLO, a cui il server risponde con l'elenco delle estensioni disponibili, ognuna definita in una diversa RFC, come riportato presso IANA. Altrimenti, nel caso in cui il client si presenti con un semplice HELO, si procede con un comportamento strettamente conforme alla RFC 821. Tra le estensioni presenti nell'esempio sopra riportato, notiamo
- SIZE (RFC 1870) che indica la massima dimensione accettata, ed evita al MUA di iniziare a trasmettere qualcosa di più voluminoso;
- DSN (RFC 3461) - Delivery Status Notification per utilizzare l'SMTP al fine di ottenere anche una ricevuta di consegna;
- 8BITMIME (RFC 1652) - l'SMTP è definito per consegnare messaggi scritti con caratteri ascii a 7 bit, mentre questa estensione consente l'uso (per il body) di caratteri ad 8 bit, in accordo al formato MIME, qualora il client aggiunga il parametro BODY al comando SMTP MAIL:
C: MAIL FROM:<>; BODY=8BITMIME
Dato che invece gli header devono contenere sempre e comunque caratteri US-ASCII, e che a seguito dell'introduzione dello standard MIME, negli header è comunque presente l'informazione a riguardo delContent-Transfer-Encoding, si ottiene che l'ESMTP ricevente ha comunque modo di conoscere l'Encoding del body per questa via, e quindi l'uso di questo parametro è divenuto opzionale.
Si veda infatti questo capture, per un esempio di messaggio contenentele lettere accentate àèéìòù offerte dall'alfabeto ISO-8859-15, e trasferito ad 8 bit;
- STARTTLS (RFC 3207) permette di invocare i servizi di crittografia offerti dal Transport Layer Security;
- SMTP-AUTH (RFC 2554) permette di restingere l'uso dell'SMTP di partenza ai soli utenti in grado di autenticarsi, nel tentativo di mitigare il fenomeno dello SPAM. Ma dato che comunque, non risolve il problema dello SPAM in ingresso al server di destinazione, non viene particolarmente usato, se non nel caso dell'utenza roaming, ovvero quando l'SMTP server di partenza è collocato al difuori della sotto rete mediante la quale il MUA del mittente è connesso ad Internet.
Destinatari multipli
Nel caso in cui uno stesso messaggio sia destinato a più recipienti (RCPT), questi vengono tutti elencati dall'SMTP mittente, e poi viene inviata una unica copia del messaggio. Un server SMTP intermedio, se ha ricevuto un messaggio con destinatari molteplici, alcuni dei quali co-locati presso uno stesso dominio di destinazione, a sua volta invia al server SMTP di quel dominio una unica copia del messaggio, con tutti i RCPT(in quel dominio) raggruppati assieme.Intestazioni
Le opzioni dei protocolli analizzati finora (ARP, UDP, TCP, ICMP, DNS...), sono sempre state codificate in formato binario, e poste all'interno delle intestazioni delle PDU prodotte da quei protocolli: queste intestazioni sono esaminate direttamente dagli apparati di rete, oppure dal kernel o dalle librerie dei computer di destinazione. Nel caso attuale invece, l'SMTP è un protocollo di strato applicativo che opera direttamente tra entità pari, non più integrate dentro ad Internet, ma concettualmente disposte ai bordi della rete, ed in esecuzione nello User Space dei computer in comunicazione.
Questa profonda differenza fa sì che l'SMTP adotti una diversa modalità di rappresentazione delle proprie intestazioni di protocollo, così come accadrà anche nel caso dei diversi protocolli applicativi che esamineremo in seguito, e che prevede che le intestazioni di strato applicativo siano rappresentate in forma umanamente leggibile. Tali intestazioni sono state inizialmente definite in RFC 822, e quindi in RFC 2822: sono disposte una per linea, e composte da un nome, seguito da due punti, e quindi un valore; inoltre, sono separate dal body del messaggio vero e proprio mediante una linea vuota. Le uniche due intestazioni obbligatorie, sono
- Date: Mon, 05 Mar 2007 17:06:20 +0100 - inserita dallo UA di partenza
- From: Alessandro Falaschi <>; - il mittente, a cui inviare l'eventuale risposta
- Sender: segreteria <>; - chi materialmente invia il messaggio, per conto del mittente vero;
- Reply-to: scrivimi <>; - se presente, le risposte vanno qui, e non al From:
- To: - il destinatario, possono essere più d'uno;
- CC: - Carbon Copy, un altro destinatario da mettere in copia, possono essere più d'uno;
- BCC: - Blind Carbon Copy, ancora altro destinatario da mettere in copia, senza che gli altri destinatari lo sappiano; i BCC possono essere più d'uno
- Message-ID: <>; - inserito dallo UA come identificativo del particolare messaggio. Il suo valore può essere citato negli header In-Reply_To: e References: che, se presenti in una risposta, permettono di associare la stessa al messaggio uscente corrispondente
- User-Agent: Mozilla Thunderbird 1.5.0.9 (X11/20070103) - identifica il programa usato per l'invio
- Subject: test di capture dell'SMTP - identifica l'oggetto della comunicazione. È considerata buona educazione utilizzare questo campo, per aiutare il destinatario a capire velocemente il contenuto principale del messaggio, senza doverlo leggere per intero.
- MIME-Version: 1.0
- Content-Type: text/plain; charset=ISO-8859-15
- Content-Transfer-Encoding: 7bit
- Return-Path: <>;
- Received: from smtp-out4.libero.it (smtp-out4.libero.it [212.52.84.46]) by infocom.uniroma1.it (8.12.10/8.12.10) with ESMTP id l25GY4aW002416 for <>;; Mon, 5 Mar 2007 17:34:04 +0100
- Received: from localhost (172.31.0.51) by smtp-out4.libero.it (7.3.120) id 45D9992900FDB3E3 for ; Mon, 5 Mar 2007 17:06:20 +0100
- X-Scanned: with antispam and antivirus automated system at libero.it
- Received: from smtp-out4.libero.it ([172.31.0.40]) by localhost (asav-out10.libero.it [192.168.32.38]) (amavisd-new, port 10024) with ESMTP id ttPaRI2Q3Cle for <>;; Mon, 5 Mar 2007 17:06:20 +0100 (CET)
- Received: from [192.168.120.40] (151.41.242.192) by smtp-out4.libero.it (7.3.120) id 45D9993D01232796 for ; Mon, 5 Mar 2007 17:06:20 +0100
- il Return-Path: viene inserito dall'ultimo server SMTP della catena, quello relativo al destinatario, ed indica l'indirizzo a cui inviare eventuali messaggi di errore
- le intestazioni Received: sono aggiunte ognuna, dal basso verso l'alto, dai diversi server SMTP di transito, e possono tornare utili, per ricostruire il percorso che ha fatto il messaggio. Indicano l'SMTP mittente (from), il ricevente (by), se si è usato l'ESMTP, l'ID unico con il quale il messaggio è stato registrato nei file di log del ricevente, il destinatario (for) (potrebbe cambiare in transito, se elaborato da una mailing list), e la data e ora locali, più la correzione rispetto all'ora di Greenwitch. Qualora il numero di intestazioni Received: superi un determinato valore (ad es. 30), si presume che si sia verificato un loop anomalo, l'inoltro viene sospeso, e viene inviato un messaggio di errore al Return-Path:
- le intestazioni che iniziano per X- (es X-Scanned:) non sono definite da uno standard, ma possono veicolare informazioni speciali per lo UA di ricezione, o semplicemente per chi legge.
Ricezione dell'email
Una volta che l'email è giunta presso il computer indicato dal RR MX relativo al dominio di destinazione, questa può essere letta dal destinatario (la cui autenticazione stavolta è obbligatoria) sia in locale, se ha accesso fisico al computer di destinazione, sia da remoto, utilizzando una applicazione come ad es. Outlook, Thunderbird, Evolution, Opera, Eudora, KMail, Pine, Mutt. In questo secondo caso, si utilizza uno di due procolli, POP3 od IMAP, entrambi di tipo client-server, le cui differenze sostanziali sono illustrate nella figura che segue.POP3
Il Post Office Protocol, definito nella RFC 1939, essenzialemente è nato per permettere di scaricare sul proprio computer le email ricevute, ed anche se è prevista una opzione del tipo lascia sul server, questa è molto inefficiente nel caso di utilizzo di tipo nomadico.In origine, permetteva solo l'invio della password in chiaro, mentre le successive estensioni, permettono l'uso dei metodi SASL, e di TLS.
IMAP
L'Internet Message Access Protocol è definito dalla RFC 3501, ed offre diversi vantaggi rispetto all'uso del POP, come- la connessione con il server resta attiva per tutto il tempo che è aperto il programma di posta, risparmiando sui tempi di inizializzazione;
- un stessa mailbox può essere acceduta in contemporanea da parte di più client differenti;
- le diverse parti di un messaggio MIME possono essere scaricate (o meno) in modo indipendente le une dalle altre, permettendo ad esempio di rimandare la ricezione di un allegato voluminoso;
- i messaggi lasciati sul server possono essere etichettati con attibuti tali da permettere di riconoscere, ad esempio, i messaggi letti, e quelli a cui si è risposto;
- si possono creare cartelle presso il server in cui ordinare i propri messaggi, eventualmente condividendoli con altri;
- un client può richiedere al server di fare ricerche specifiche, senza dover scaricare i messaggi;
- un server può annunciare la disponibilità di particolari estensioni, che possono essere usate dai client che pure le supportano;
- tra queste estensioni c'è il supporto a SASL ed a TLS, che permette di aggiungere servizi di sicurezza;
Webmail
E' la contrazione di Web-based email, e consiste in un portale web da cui si può accedere alla propria casella di posta elettronica, in modo da poterla leggere anche da una postazione occasionale, tipicamente pubblica, permettendo inoltre di spedire posta. In questo caso l'unico protocollo che sembrerebbe essere in gioco, è il dialogo HTTP che si svolge tra il nostro browser, ed il server web che ci mostra le pagine del portale. In effetti, le pagine sono generate da un CGI, ossia un programma in esecuzione presso il computer che ospita il server web, e che a sua volta opera in modalità client nei confronti dei procolli email, ossia SMTP per spedire, ed IMAP per ricevere.Codifica dei caratteri
Il concetto che ad un byte corrisponda univocamente un carattere stampabile, e viceversa, non è per nulla corretto.Dai tempi in cui venne definito il primo insieme di caratteri per telecomunicazioni (il codice Morse del 1840), l'associazione tra codici numerici e simboli linguistici si è via via estesa, fino alla definizione di un insieme (Universal Caracter Set, o UCS, o Unicode) che possa rappresentare in modo congiunto i simboli previsti da tutte le lingue del mondo, in modo da poter essere utilizzato per i contenuti da scambiare a livello planetario, come avviene in Internet. Ma andiamo con ordine.
ASCII
L'insieme di caratteri più universalmente noto è il codice ASCII, standardizzato come X3.4-1986 da ANSI, come ISO 646 da ISO, e come US-ASCII da IANA, che definisce una tabella di corrispondenza tra i codici numerici 0-127 (e dunque rappresentabili con 7 bit) ed i caratteri stampabili. Questi codici rappresentano, per le prime 32 posizioni, i cosiddetti caratteri di controllo, e sono una eredità dell'epoca delletelescriventi. I restanti codici, sono invece associati ai cosidetti caratteri stampabili. Tra questi però non compaiono (ad esempio) le lettere accentate, cosicchè ci fu un periodo in cui a tale scopo vennero definite diverse mappature (dette codepage) dei restanti 128 caratteri ancora disponibili, settando ad 1 il bit più significativo di un byte.Codepage
Una Codepage è una tabella che stabilisce una corrispondenza tra i codici a 8 bit aventi il bit più significativo posto ad uno (che non rientrano nella tabella ASCII), e i simboli di un certo alfabeto, compresi anche i caratteri semi-grafici (mediante i quali si poteva produrre una qualche forma di disegno sullo schermo dei terminali di allora).Una codepage di largo uso in Europa, è stata la numero 850, indicata come Multilingual (Latin-1), poi sostituita con windows-1252, e quindi con la sua evoluzione ISO 8859-1, detto anche alfabeto Latin-1, definito da ISO e IEC, e mostrato nella tabella sottostante, in cui notiamo che i codici 00–1F, 7F, e 80–9F non sono assegnati a caratteri.
| ISO/IEC 8859-1 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | |
| 0x | unused | |||||||||||||||
| 1x | ||||||||||||||||
| 2x | SP | ! | " | # | $ | % | & | ' | ( | ) | * | + | , | - | . | / |
| 3x | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | : | ; | < | = | > | ? |
| 4x | @ | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O |
| 5x | P | Q | R | S | T | U | V | W | X | Y | Z | [ | \ | ] | ^ | _ |
| 6x | ` | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o |
| 7x | p | q | r | s | t | u | v | w | x | y | z | { | | | } | ~ | |
| 8x | unused | |||||||||||||||
| 9x | ||||||||||||||||
| Ax | NBSP | ¡ | ¢ | £ | ¤ | ¥ | ¦ | § | ¨ | © | ª | « | ¬ | SHY | ® | ¯ |
| Bx | ° | ± | ² | ³ | ´ | µ | ¶ | · | ¸ | ¹ | º | » | ¼ | ½ | ¾ | ¿ |
| Cx | À | Á | Â | Ã | Ä | Å | Æ | Ç | È | É | Ê | Ë | Ì | Í | Î | Ï |
| Dx | Ð | Ñ | Ò | Ó | Ô | Õ | Ö | × | Ø | Ù | Ú | Û | Ü | Ý | Þ | ß |
| Ex | à | á | â | ã | ä | å | æ | ç | è | é | ê | ë | ì | í | î | ï |
| Fx | ð | ñ | ò | ó | ô | õ | ö | ÷ | ø | ù | ú | û | ü | ý | þ | ÿ |
In tutti gli alfabeti ISO 8859-x, la codifica dei primi 127 caratteri (non di controllo) è la stessa dell'US-ASCII, quindi i files scritti con il secondo alfabeto, sono automaticamente validi anche nel primo.
Unicode
Nel 2004 il gruppo di lavoro di ISO/IEC responsabile della manutenzione delle codifiche di carattere ad 8 bit si è sciolto, e tutti gli sforzi si sono indirizzati verso lo Universal Character Set del consorzio Unicode, noto anche come ISO/IEC 10646, che contiene centinaia di migliaia di caratteri di tutte le lingue del mondo, ognuno identificato in modo non ambiguo da un nome, e da un numero chiamato il suo Code Point.
Ogni carattere Unicode viene rappresentato con la sequenza "U+", seguita da un numero esadecimale che indica il codepoint del carattere. I primi 256 caratteri, indicati come il blocco latin-script, coincidono con quelli dell'alfabeto ISO 8859-1, e ne condividono l'ordinamento, e quindi la rappresentazione numerica.
Piani
Sono definiti 17 piani di caratteri, ognuno comprendente 65,536 (= 216) possibili code points. Pertanto, un codepoint che compare in uno dei 17 piani può essere rappresentato da (16 + log217=) 21 bits. Ma come vedremo subito, sono definite della regole di trasformazione allo scopo di usare un numero variabile di bits, in modo da rendere la dimensione dei testi americani ed europei comparabile a quella "classica" che usava 1 byte per carattere.
Basic Multilingual Plane
I CodePoints da U+0000 a U+FFFF costituiscono il piano 0, noto anche come Basic Multilingual Plane (BMP), contenente la maggior parte delle assegnazioni eseguite finora, come risulta dalla mappa riportata qui sotto, in cui sono evidenziati gli utilizzi per tutti i singoli blocchi da 256 codepoints.
|
 |
Unicode Transformation Format
Consiste in un insieme di regole che consentono di rappresentare i caratteri associati alle sequenze numeriche identificate dai codepoint mediante un numero variabile di byte, allo scopo di minimizzare l'occupazione di memoria necessaria, e massimizzare la compatibilità con i testi preesistenti. Lo standard de facto è indicato come UTF-8, che usa da uno a quattro bytes per rappresentare un carattere Unicode. Altri formati di trasformazione sono l'UTF-16, anch'esso a lunghezza variabile, a multipli di 16 bit, e l'UTF-32, con lunghezza fissa pari a 32 bit. Dato che l'SMTP, come più volte ricordato, si basa su caratteri a 7 bit (a meno che il server non supporti l'estensione 8BITMIME), le trasformazioni citate, se utilizzate come valore del parametro charset della intestazione MIME Content-Type, devono subire un ulteriore processo di trasformazione, indicando un Content-Transfer-Encoding di tipo quoted-printable oppure base64, come ad esempio
| Content-Type: plain/text; charset=UTF-8 Content-Tranfer-Encoding: quoted-printable |
Onde evitare trasformazioni, è stato definito (ma sembra poco usato) un ulteriore formato di trasformazione, l'UTF-7, che rappresenta il testo Unicode come una stringa di caratteri ASCII.
UTF-8
Questo formato di trasformazione per l'Unicode, definito nella RFC 3629, è del tutto consistente con l'alfabeto US-ASCII, in quanto i primi 128 codepoint da U+0000 a U+007F sono rappresentati da un unico byte, in cui i sette bit diversi da zero rappresentano esattamente gli stessi simboli dell'alfabeto ASCII. Pertanto, tutti i files di testo ASCII sono perfettamente validi anche se interpretati come UTF-8. Per le lettere accentate ed i caratteri Latin-1, associati all'intervallo da U+0080 a U+07FF, corrispondente ai primi 2048 codepoint, occorrono due bytes, mentre ne occorrono tre per il resto del Basic Multilingual Plane (da U+0800 to U+FFFF); per caratteri appartenenti a qualunque altro piano di Unicode, occorrono 4 bytes. Passiamo quindi a descrivere questo schema di codifica.
Per i primi 127 codepoints UTF-8 utilizza un solo byte, con il bit più significativo posto a zero. Altrimenti, se occorre utilizzare N bytes per uno stesso codepoint, il primo byte ha il bit più significativo posto ad uno, seguito da N-1 bits posti anche essi ad uno, seguiti da uno zero (alla N+1-esima posizione), seguiti dai bit più significativi del codepoint. I bytes successivi, hanno una coppia di bit pari a 10 nella posizione più significativa, seguiti da 6 bit presi in sequenza dalla rappresentazione binaria del codepoint. Lo schema è riassunto nella tabella seguente, in cui la lettera x indica i bit disponibili per codificare il codepoint:
| Char. number range | n. of | UTF-8 octet sequence (hexadecimal) | bits | (binary) ----------------------+--------------------------------------------- 0000 0000 - 0000 007F | 7 | 0xxxxxxx 0000 0080 - 0000 07FF | 11 | 110xxxxx 10xxxxxx 0000 0800 - 0000 FFFF | 16 | 1110xxxx 10xxxxxx 10xxxxxx 0001 0000 - 0010 FFFF | 21 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
La RFC 3629 riporta alcuni esempi di codifica. Proviamo qui ora ad individuare la codifica per la parola cioè. Le prime tre lettere, che appartengono all'alfabeto ascii, producono un byte ciascuna, pari a 0x63 0x69 0x6F. Alla lettera è compete un codepoint pari a U+00E8, lo stesso che risulta per ISO 8859-1, e che in binario si rappresenta come 11101000. In accordo alla seconda riga della tabella soprastante, occorrono due bytes, ed i bit che compaiono nel codepoint vengono riscritti da destra a sinistra al posto delle x, ponendo a zero le tre x più significative, ottenendo il risultato 110(00011) 10(101000), ossia 0xC3 0xA8. Pertanto, esprimendo in esadecimale il risultato finale della codifica UTF-8 di cioè, si ottiene 0x63 0x69 0x6F 0xC3 0xA8.
MIME
Il Multipurpose Internet Mail Extensions (MIME) estende il formato delle email, permettendo- l'uso di caratteri diversi dall'insieme US-ASCII,
- di allegare i documenti più disparati, anche diversi da file di testo,
- di spedire messaggi composti da più parti, e
- di usare caratteri non-ASCII nei valori degli header, come il Subject:
Queste specifiche sono usate anche in ambiti diversi dal traffico email, come per i protocolli HTTP e SIP, e sono descritte dai documenti RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289, RFC 2077, RFC 2231,RFC 3676.
Intestazioni principali
L'intestazione| MIME-Version: 1.0 |
indica allo User Agent di ricezione che il messaggio aderisce alle specifiche MIME, e viene semplicemente ignorato da uno UA non aggiornato, e non in grado di interpretarlo correttamente.
Content-Type
La presenza di| Content-Type: text/plain; charset=ISO-8859-15 |
indica il tipo di contenuto presente, nel formato tipo/sottotipo; parametro=valore, e fornisce allo UA un suggerimento su come visualizzare o riprodurre correttamente il contenuto ricevuto. Il parametropermette di specificare una particolare caratteristica del tipo/sottotipo indicato, ed in questo esempio, stabilisce che il body dell'email contiene caratteri appartenenti all'insieme ISO-8859-15. Nel caso invece in cui si tratti di un contenuto non direttamente visualizzabile da parte del lettore di email, ossia non testuale, occorre eseguire un applicativo idoneo (ad es., un player multimediale per contenuto audio o video), associato al MIME-Type che lo descrive. La lista dei tipi e sottotipi possibili è registrata presso IANA, comprendendo tra gli altri i seguenti casi particolari:
- Tipo application: contenuti da aprire con programmi appositi
- application/javascript: codice JavaScript; definito nella RFC 4329
- application/octet-stream: contenuto binario generico, che può anche essere un programma eseguibile. Se presente nel messaggio ricevuto, il programma ricevente può visualizzare la proposta di salvarlo su disco. La RFC 2046 lo imposta come il tipo di default per sottotipi non riconosciuti, e per questi motivi, presenta rischi di sicurezza.
- application/pdf: definita da RFC 3778
- application/vnd.ms-powerpoint: definita da Sukvinder S. Gill. vnd sta per vendor e identifica formati proprietari
- application/xml (RFC 3023): i dati sono strutturati in formato XML, e possono codificare informazioni che necessitano di ulteriore elaborazione per poter essere usate
- Tipo audio
- Tipo image
- Tipo multipart: questo tipo permette a MIME di inviare messaggi strutturati ad albero, in cui le singole parti possono essere foglie, con a loro volta un unico Content-Type, oppure essere altri componenti di tipo multipart. In questo modo, si possono ad esempio inviare allegati, come approfondito più avanti. Definito in RFC 2045 e RFC 2046.
- Tipo text
- text/plain: dati testuali visualizzabili direttamente dallo UA, definito in RFC 2046 e RFC 3676, che raccomanda l'uso del set di caratteri US-ASCII se non specificato diversamente, attribuendo al parametro charset un valore opportuno (come as es., ISO-8859-15). In caso di assenza di sottotipo, l'allegato è da intendersi plain
- text/html: un file HTML che può essere visualizzato con un browser web o dallo UA stesso; definito da RFC 2854, che suggerisce di specificare il charset mediante l'uso dell'apposito parametro
- text/xml (RFC 3023): i dati sono strutturati in formato XML, e possono essere visualizzati da un ricevente generico, come fosse un testo semplice
- Tipo video
- video/mpeg: video in formato MPEG-1 multiplato assieme con audio, definito in RFC 2045 and RFC 2046
- video/mp4: video MP4, definito in RFC 4337
- video/quicktime: video QuickTime, registrato presso IANA
- video/x-ms-wmv: video Windows Media, documentato presso Microsoft KB 288102
Content-Transfer-Encoding
A meno che non sia disponible l'estensione ESMTP di tipo 8BITMIME, le email devono contenere solamente caratteri US-ASCII, con il bit più significativo di ogni byte posto a zero. Questo contrasta con l'uso di set di caratteri esteso, come gli alfabeti ISO-8859-x, e con l'invio di allegati contenenti dati binari qualsiasi. Per questo, lo standard MIME prevede l'uso della intestazione Content-Transfer-Encoding, come ad esempio
| Content-Transfer-Encoding: 7bit |
che stabilisce un metodo di codifica del body tale da convertire il suo vero contenuto, qualsiasi, in una diversa rappresentazione, tale che nel flusso di byte risultante il bit più significativo sia posto a zero. Il lato trasmittente, una volta noto il formato accettabile dal server SMTP, converte al volo l'email, ed aggiunge questo header, per indicare la trasformazione effettuata. Il lato ricevente, noto il Transfer-Encodingutilizzato, provvede quindi ad invertirne la rappresentazione, in modo da ristabilire il flusso binario originario. La RFC 2045 definisce i valori che possono essere assunti dalla intestazione Content-Transfer-Encoding:, che sono:
adatti all'SMTP normale:
-
7bit - è il valore di default, assunto vero se Content-Transfer-Encoding non è presente, e prevede la trasmissone di fino a 998 byte per linea, con codici di carattere nell'intervallo 1..127, ed in cui la sequenza CR e LF (codici 13 e 10) indica la fine di una linea;
-
quoted-printable- trasforma i caratteri ad 8 bit ed i caratteri non stampabili eventualmente presenti, nella sequenza di 3 caratteri =HH, in cui le due cifre esadecimali HH (0-9 o A-F) corrispondono al codice binario (in base al charset utilizzato) del carattere trasformato. Il risultato è ancora direttamente leggibile per la sua parte stampabile, ed anche se uno UA non supporta la trasformazione inversa, la codifica dei caratteri trasformati può essere visualizzata senza danno. Ad esempio:
- il carattere US-ASCII form feed (decimale 12) viene rappresentato come =0C
- il carattere é dell'alfabeto ISO-8859-1 (decimale 233, corrispondente ad una e con accento acuto), si rappresenta con la sequenza =E9
- la parola cioè (in ISO-8859-1) è rappresentata come cio=E8
- base64- trasforma tutti i byte presenti, raggruppando i byte a tre a tre (per un totale di 24 bit), e rappresentandoli con 4 caratteri stampabili, ognuno dei quali rappresenta una codifica di 6 dei 24 bit complessivi, come in questo esempio in cui si mostrano i passaggi necessari a rappresentare la sequenza esadecimale 0x010203 nella sua rappresentazione base64 AQID:
| 1 2 3 00000001 00000010 00000011 / \ / \ / \ 000000 01 0000 0010 00 000011 |----| |------| |-----| |----| 000000 010000 001000 000011 0 16 8 3 A Q I D |
| NUM ASCII NUM ASCII NUM ASCII NUM ASCII 0 A 16 Q 32 g 48 w 1 B 17 R 33 h 49 x 2 C 18 S 34 i 50 y 3 D 19 T 35 j 51 z 4 E 20 U 36 k 52 0 5 F 21 V 37 l 53 1 6 G 22 W 38 m 54 2 7 H 23 X 39 n 55 3 8 I 24 Y 40 o 56 4 9 J 25 Z 41 p 57 5 10 K 26 a 42 q 58 6 11 L 27 b 43 r 59 7 12 M 28 c 44 s 60 8 13 N 29 d 45 t 61 9 14 O 30 e 46 u 62 + 15 P 31 f 47 v 63 / |
Nel caso in cui il testo di partenza non abbia un numero complessivo di byte multiplo di 3, si aggiungono a destra tanti zeri, quanti ne servono per completare l'ultimo gruppo di 6 bit in entrata. Quindi, se il numero di simboli BASE64 ottenuti non è un multiplo di quattro, si aggiungono alla codifica fino a tre simboli di uguale (=), in numero pari al numero di simboli mancanti, in modo da segnalarlo al ricevitore.
Ad esempio, mostriamo la codifica della parola cioé, quando inizialmente rappresentata in ISO-8859-1. In tal caso, la parola si esprime mediante la sequenza esadecimale 0x63 0x69 0x6F 0xE8 (eseguireman ascii e man iso_8859_1 per verificarlo), che in binario diviene 01100011 01101001 01101111 11101000, e che si suddivide in gruppi di 6 bit come 011000 110110 100101 101111 111010 000000, in cui gli ultimi 4 bit sono stati aggiunti, e posti a zero. Riscrivendo l'ultima sequenza in decimale, otteniamo 24 54 37 47 58 00, che in accordo alla tabella precedente, fornisce una rappresentazione BASE64 pari a Y2lv6A==, dove i due simboli = finali sostituiscono i due gruppi di 6 bit mancanti nella penultima sequenza.
Esistono alcuni siti che calcolano la trasformazione on-line, come quelli qui indicati; inoltre su Linux è disponibile il comando base64.Adatto ad un server ESMTP che supporta l'estensione 8BITMIME:
- 8bit - fino a 998 bytes per linea, con la sequenza CR e LF (codici decimali 13 e 10) che appare solo alla fine di una linea;
Adatto ad un server ESMTP che supporta l'estensione BINARYMIME (RFC 3030):
- binary - qualunque sequenza di bytes.
Encoded Word
Le intestazioni MIME Content-Type e Content-Transfer-Encoding stabiliscono alfabeto e codifica del body della email, ma per usare un alfabeto diverso da US-ASCII nel valore di una intestazione, come ad esempio nel Subject, si ricorre ad un diverso espediente, noto come Encoded Word (RFC 2047), che definisce una sintassi tale da indicare, in un sol colpo
- il charset originario,
- il transfer-encoding usato,
- il risultato della trasformazione.
=?charset?encoding?encoded text?= |
- charset può essere qualunque, purché registrato presso IANA e tipicamente, sarà lo stesso charset del body
- encoding può essere sia "
Q", ossia quoted-printable, oppure "B", ossia base64 - encoded text è il risultato della trasformazione.
| Subject: =?utf-8?Q?=C2=A1Hola, se=C3=B1or!?= |
Multipart Content Type
Un messaggio MIME multiparte è il formato tipico in cui sono realizzate le email che contengono allegati, o contenuti di tipo diverso dal text/plain. In questo caso, il body del messaggio è suddiviso mediante una stringa speciale detta confine (boundary), definita nella intestazione Content-type:, e che non deve comparire in nessuna delle parti: per questo motivo, il confine tipicamente assume l'aspetto di una sequenza di simboli casuali. Il confine è inserito oltre che tra le diverse parti, allo scopo di demarcare la loro separazione, anche all'inizio ed alla fine del corpo del messaggio, come segue:
| Content-type: multipart/mixed; boundary="frontier" MIME-version: 1.0 This is a multi-part message in MIME format. --frontier Content-type: text/plain This is the body of the message. --frontier Content-type: application/octet-stream Content-transfer-encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier-- |
Multipart Subtypes
Il Content-type multipart può essere di diversi sottotipi, che specificano la natura delle parti, e le loro relazioni reciproche. I sottotipi più comuni sono:
- Mixed - usato per inviare files allegati, con Content-Type differenti dal testo del messaggio. Se il tipo di una sottoparte è ad esempio una immagine, molti client email saranno in grado di mostrarla direttamente, altrimenti proporranno di eseguire una applicazione specifica. Definito nella RFC 2046, sezione 5.1.3
- Alternative - Il sottotipo multipart/alternative indica che ogni parte è una versione alternativa dello stesso contenuto, ognuna in un formato diverso, come indicato dall'header Content-Typecorrispondente. I formati sono ordinati in base al grado di aderenza all'originale, con il meno aderente per primo, ed il più aderente per ultimo. In tal modo, il client può scegliere la migliore rappresentazione che è in grado di visualizzare, come l'ultima parte che è in grado di interpretare. Per questo, il formato text/plain viene posto per primo, in quanto il meno aderente possibile, consentendo ai client non in grado di interpretare i messaggi multiparte, di visualizzare comunque qualcosa di leggibile. Definito nella RFC 2046, Sezione 5.1.4
- Related - Questo sottotipo è usato per indicare che le parti del messaggio non devono essere considerate individualmente, ma piuttosto come parti di uno stesso aggregato. Il messaggio consiste di una parteradice (la prima), che referenzia in-linea le altre parti, per mezzo dell'header Content-ID presente nelle diverse parti. Un uso tipico del sottotipo Related, è quello che permette di inviare per email una pagina web, completa di tutte le immagini che contiene. Definito nella RFC 2387
- Report - E' il sottotipo usato da un server SMTP per comunicare (via email) eventi di errore, e indica la presenza di dati formattati in modo che possano essere letti da parte di un mail server; tipicamente, il messaggio è suddiviso in una parte di tipo text/plain, ed una di tipo message/delivery-status. Definito nella RFC 3462
- Digest - Multipart/digest è un modo semplice per allegare ad una email, un diverso messaggio email. Il content-type di default per ogni parte è message/rfc822. Definito nella RFC 2046, sezione 5.1.5
- Signed - Questo sottotipo è usato per allegare una firma digitale al messaggio, che una volta firmato, contiene due parti, un body ed una signature. Tutto il body, inclusi gli header MIME, è usato per creare la parte con la firma, prodotta in uno di diversi modi possibili, come indicato dall'header Content-Type presente nella parte con la firma, che ad es. può riportare application/pgp-signature, oapplication/x-pkcs7-signature. Definito in RFC 1847, sezione 2.1
- Encrypted - In questo caso, il messaggio è composto di due parti, dove la prima contiene le informazioni di controllo necessarie per decrittare la seconda, di tipo application/octet-stream. Definito in RFC 1847, Section 2.2
- Form Data - Come implica il nome, questo sottotipo è usato per esprimere valori immessi mediante un modulo di inserimento dati (form), tipicamente compilato mediante una pagina web. Definito in RFC 2388
Content-Disposition
Illustriamo l'uso di questa intestazione nell'ambito dei commenti al seguente capture, in cui le risposte delserver SMTP sono visualizzate in corsivo, e che corrisponde all'invio di una email contenente in allegato una immagine jpeg, codificata con il metodo base64.| 220 smtp-out2.libero.it ESMTP Service (7.3.120) ready EHLO [192.168.120.40] 250-smtp-out2.libero.it 250-DSN 250-8BITMIME 250-PIPELINING 250-HELP 250 SIZE 30000000 MAIL FROM:<>; SIZE=11599 250 MAIL FROM:<>; OK RCPT TO:<>; 250 RCPT TO:<>; OK DATA 354 Start mail input; end with <CRLF>.<CRLF> Message-ID: <>; Date: Mon, 05 Mar 2007 20:30:12 +0100 From: alef <>; User-Agent: Mozilla Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Subject: prova invio con allegato Content-Type: multipart/mixed; boundary="------------060708020103050401060503" This is a multi-part message in MIME format. --------------060708020103050401060503 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit vediamo come parte l'allegato --------------060708020103050401060503 Content-Type: image/jpeg; name="logoalef.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="logoalef.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/4QAWRXhpZgAATU0AKgAAAAgAAAAAAAD//gAXQ3JlYXRl ZCB3aXRoIFRoZSBHSU1Q/9sAQwADAgIDAgIDAwMDBAMDBAUIBQUEBAUKBwcGCAwKDAwLCgsL DQ4SEA0OEQ4LCxAWEBETFBUVFQwPFxgWFBgSFBUU/9sAQwEDBAQFBAUJBQUJFA0LDRQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU/8AAEQgAZAGk AwEhAAIRAQMRAf/EABwAAQADAQEBAQEAAAAAAAAAAAABCAkHBgUEA//EAFUQAAAEBAMEBwIH CQsMAwAAAAABAgMEBhRhBQcRCBITFwkhMVFWldIVcRkiQYGUtNQWIzJVZGWRssQYM0JEYpKh oqOz0yVDRlJTV2Nyc4KTpabB5P/EABwBAQACAgMBAAAAAAAAAAAAAAABBQQGAgMHCP/EADsR AAEDAwECCwYFBAMBAAAAAAABAhEDBBIFIZEUFUFRUlRhcZKx0QYTMTIzwSIjYoHwcqGy8RYk . ..... molte linee omesse . DaSHCT3AMlHCSHCTqIkSo4Se4TwkhIlRwk9wjhJCRKjhJDhJ7gkSo4SQ4adOwSMlHCT3Bwkh IlRwkhw06dgCVHCT3Bwk9XUEiVBNJ7gNtPcAlRw09wnhJ7hEiVINtJBwk9wkSo4ST+QDbSAl Rwkhwk9wgSo4SQ4aQJlQbaSLsAmk9wSRKjhJ17A4aevqEkyo4adOwOEnXsAjJRwk9wcJIiRk o4SQ4adOwJEqfsgiJLR6d4DivxMV3zH/2Q== --------------060708020103050401060503-- . 250 <45D997EE01267F19> Mail accepted QUIT 221 smtp-out2.libero.it QUIT |
Sicurezza
Questo concetto si applica a diverse fasi dell'invio delle email, e cioè- autenticazione di colui che invia, presso il server di partenza
- propagazione della informazione di autenticazione verso il server di arrivo
- notifica al destinatario, se il mittente è autenticato o meno
- autenticazione del destinatario della email, per il suo prelievo via POP/IMAP
- crittografia del contenuto del messaggio (confidenzialità)
- garanzia a riguardo che il messaggio ricevuto è proprio quello trasmesso (integrità)
- firma digitale dell'autore del messaggio (autenticità) (non repudiabilità)
Ognuno dei passi elencati può essere svolto in accordo ad uno o più protocolli, che si basano su concetti e algoritmi che sono discussi in una sezione apposita. Nel seguito, illustriamo direttamente le soluzioni adottate, rimandando alla sezione sulla sicurezza per gli approfondimenti. Infine, dedichiamo la prossima sezione al tema dello spam.
Autenticazione
Osserviamo subito che verificare l'autenticità di qualcuno/qualcosa, è diverso dall'accordare allo stesso soggetto il potere di fare qualcosa, ovverosia, autorizzarlo. Ma in ciò che segue, i due concetti si fondono, in quanto lo scopo dell'autenticazione è ristretto alle necessità della applicazione che la richiede, e quindi l'autenticazione implica il permesso ad operare. Ma in generale, si può dire soltanto il viceversa, e cioè che un processo di autorizzazione, sottintende un prerequisito di autenticazione. Wikipedia dedica una categoria a parte sull'argomento della autenticazione delle email.
SASL
Il processo di autenticazione viene realizzato con l'ausilio dei meccanismi offerti dalla libreria SASL, sia nel momento dell'invio della email (punto 1), abilitatandolo presso il server SMTP di Outbound, sia nel momento della ricezione della stessa (punto 4), abilitandolo presso il server POP3 o IMAP dell'ISP del destinatario. Nel primo caso (opzionale), ci si avvale della estensione SMTP-AUTH, e può essere aggiunto un header che dichiara l'avvenuta autenticazione. Nel secondo, si ricade nella definizione standard del protocollo di prelievo email. Una variante si ha quando la lettura della email avviene mediante una interfaccia di tipo Webmail: in tal caso, l'utente viene autenticato dalla applicazione web, che poi opera in veste di agente, usando le credenziali dell'utente per autenticarsi al suo posto, ed accedere alle email giacenti presso un server IMAP, impersonando l'utente.
SMTP-AUTH
La RFC 2554 definisce una estensione di SMTP, indicata come SMTP-AUTH, che permette di ottemperare ai primi tre punti espressi nell'elenco di cui sopra. Infatti, consente di condizionare l'accettazione di un nuovo messaggio al buon esito di un processo preliminare di autenticazione, in cui il server di partenza si accerta della reale identità del soggetto che invia il messaggio. Ciò permette agli utenti abilitati di usare questo server SMTP anche quando si collegano (in roaming) da una postazione esterna alla rete del proprio provider; al tempo stesso, però, si introduce un rischio di sicurezza, perchè un attaccante, indovinando (ad esempio, mediante un metodo di forza bruta) la password di un utente autorizzato, potrebbe poi usare il server SMTP per inoltrare SPAM. Inoltre, sebbene mediante SMTP-AUTH il server SMTP di partenza puòinformare quello di arrivo che il mittente è stato correttamente autenticato, in generale non esiste un rapporto di fiducia tra i due server, e così il destinatario non sarà mai rassicurato con certezza in tal senso. Per questi motivi, l'estensione SMTP-AUTH non è molto usata. Ad ogni modo, esaminiamo come appare una sessione che fa uso di questa estensione:
| S: 220 smtp.example.com ESMTP server ready C: EHLO jgm.example.com S: 250-smtp.example.com S: 250 AUTH CRAM-MD5 DIGEST-MD5 C: AUTH FOOBAR S: 504 Unrecognized authentication type. C: AUTH CRAM-MD5 S: 334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== S: 235 Authentication successful. |
Dopo che il server ESMTP ha annunciato la disponibilità della estensione AUTH, assieme ad una lista dei meccanismi SASL supportati (nell'esempio, CRAM-MD5 e DIGEST-MD5), il client manifesta l'intenzione di usarne uno. Il CRAM-MD5 è tra quelli supportati, ed il server risponde inviando lo challenge, che viene però (reversibilmente) codificato come base64. Il client da parte sua, dopo aver calcolato l'HMAC-MD5 concatenando lo challenge alla password dell'utente, ed avere prefisso il risultato con l'identificativo dell'utente stesso, codifica la stringa risultante in base64, e reinvia il tutto al server. La trasformazione via base64 viene prescritta dalla RFC 4422 (SASL), in modo che se challenge e/o password contengono caratteri non ASCII, per questi venga usata la codifica Unicode, con trasformazione UTF-8, e quindi poi il tutto sia rappresentato con caratteri a 7 bit, appunto mediante codifica base64.
Confidenzialità, integrità e autenticità
Gli ultimi tre punti dell'elenco posso essere soddisfatti appieno solo se le trasformazioni crittografiche avvengono da estremo ad estremo del collegamento, adottando uno degli standard noti come PGP ed S/MIME. Tuttavia, esiste la possibilità di effettuare ogni singolo trasferimento dal mittente al primo server SMTP, e poi tra server SMTP intermedi fino a quello di destinazione, su collegamenti resi sicuri mediante TLS, come permesso in base alla estensione STARTTLS dell'SMTP.
StartTLS
Il Transport Layer Security (TLS) è definito nella RFC 4346, ed offre alle applicazioni una modalità di comunicazione sicura. L'estensione STARTTLS di SMTP, descritta nella RFC 3207, permette ad un client SMTP di negoziare con il server i servizi di crittografia ottenibili via TLS, tali da impedire la lettura (da parte di un intercettatore) dei contenuti in transito, ottemperando quindi ai requisiti di confidenzialità. Questo però avviene solo di tratta in tratta, sempre che tutte le tratte lo permettano, e scelgano di usarlo: questa variabilità ne vanifica in parte gli scopi, per quanto rimane comunque un valido meccanismo di protezione nella comunicazione tra il client, ed il server SMTP del proprio provider. Inoltre, dato che l'attivazione di TLS precede l'autenticazione basata su SASL (vedi esercitazioni), l'uso di TLS si dimostra una soluzione valida, per utilizzare il meccanismo plaintext, dato che la password non viene inviata in chiaro, ma crittografata dal TLS.
Spam e contromisure
Il fenomeno dello spamming della posta elettronica è noto a tutti, e consiste nell'invio di una grande quantità di posta elettronica a destinatari sparsi in tutto il mondo, e che non la vogliono ricevere. Meno nota, è l'origine di questo termine: SPAM è una marca di carne in scatola, la cui invadenza è stata oggetto di uno schetch televisivo dei Monty Pyhton (video).
Il fenomeno dello spamming si basa sull'uso di OpenRelay e OpenProxy, ovvero host che rilanciano i messaggi email ricevuti mediante il protocollo SMTP, senza discriminare la loro provenienza. Mentre la configurazione di un server SMTP ufficiale come OpenRelay può, ai giorni nostri, avvenire solo a causa di una grave disattenzione del suo amministratore, spesso gli OpenProxy sono ospitati da host di utenti connessi ad Internet, inconsapevolmente infetti da un virus, che appunto fa da intermediario tra lo spammer, e il server SMTP che l'utente stesso utilizza di diritto.
Il contrasto di questo fenomeno può avvenire dal lato ricevente, mediante filtri e regole usati per analizzare le email arrivate, ed eventualmente decidere per il loro spostamento nella cartella dello spam; tali filtri possono essere di tipo euristico, nel caso vadano a cercare particolari parole contenute nella email (ad es., Viagra), o di tipo statistico o Bayesiano, nel caso in cui il risultato del filtraggio sia una valore di probabilità che l'email sia spam. D'altra parte, il filtraggio può avvenire più vicino al mittente, o presso il server SMTP di transito o di destinazione, in modo da evitare completamente che l'email di spam raggiunga il destinatario.
Alcune applicazioni antispam in esecuzione sull'MTA di ricezione, come ad esempio SpamAssassin, applicano più strategie in parallelo, come ad esempio i filtri descritti sopra, assieme alle tecniche spiegate appresso, in modo da avere più basi su cui prendere una decisione. L'esito delle verifiche produce l'aggiunta di un ulteriori header email, come ad esempio Authentication-Results: definito nella RFC 7001, in base ai quali lo User Agent ricevente può decidere come classificare ogni messaggio.
Anti-Spam DNS Blackhole Lists
Questa tecnica di difesa dallo spam molto efficace fa uso del DNS per distribuire in rete una lista nera (detta Blackhole List o DNSBL) di indirizzi IP da cui è stato ripetutamente segnalato prevenire spam, come ad esempio realizzato da SpamHaus. Le segnalazioni che pervengono a carico di quei server SMTP che sono origine di spam sono spesso relative ad un OpenProxy, ma possono anche riguardare server SMTP legittimamente usati da utenti malevoli dell'ISP che lo gestisce. Tale tecnica si basa sul fatto che quando un server SMTP riceve una connessione TCP, può interrogare il socket per conoscere l'indirizzo IP mittente, ed interrogare la DNSBL per sapere se il mittente è tra i cattivi oppure no. L'interrogazione avviene mediante una richiesta di risoluzione DNS, nel seguente modo:
- l'indirizzo IP del client SMTP viene riscritto con i byte invertiti da destra a sinistra — ad esempio 192.168.1.254 diventa 254.1.168.192;
- il dominio della oganizzazione che gestisce la DNSBL viene concatenato all'indirizzo IP invertito, ad es. 254.1.168.192.spammers.example.net;
- viene effettuata una query DNS (di tipo A) per l'host name così ottenuto, a cui risponde in modo autorevole il DNS di tale organizzazione. Se la risposta ricevuta è un indirizzo IP (ad es 127.0.0.2), il client è listato, mentre se la risposta è NXDOMAIN (No such domain) il client è buono
Le risposte a tali interrogazioni vengono salvate nei DNS intermedi che effettuano la ricorsione, in modo che le email di spam successive, e provenienti dallo stesso OpenProxy, vengono rifiutate senza interrogare di nuovo il DNS autorevole di chi gestisce il servizio di DNSBL. Qualora il server SMTP di uscita di un provider finisca elencato nella DNSBL, probabilmente a causa di un suo utente che ha prodotto un volume di spam tale da provocarne la segnalazione, dovrà prima eliminare la causa di spam (ovvero sospendere l'account dello spammer, o correggere la configurazione dei propri server SMTP di uscita)e quindi contattare gli amministratori della lista richiedendo la propria rimozione.
Sender Policy Framework
Molto spesso le email di spam arrivano con una intestazione From: falsa, nel senso che lo spammer non usa un proprio indirizzo mittente, ma uno inventato, oppure preso a prestito da un qualunque altro utente Internet. Il controllo denominato Sender Policy Framework (SPF) e descritto nella RFC 4408 viene svolto a carico dell'indirizzo email dichiarato dall'SMTP mittente nell'envelope come argomento del MAIL FROM, detto anche bounce address, e che nella maggior parte delle volte ricalca il From: delle intestazioni del contenuto. L'SPF consiste nella verifica che l'IP origine della email rientri tra quelli che l'intestatario del dominio del mittente ha pubblicamente dichiarato come ammissibili, mediante l'inserimento di un apposito Resource Record di tipo SPF (o TXT) nel file di zona relativo al proprio dominio. Ad esempio, se nel MAIL FROM viene dichiarata l'email , la verifica inizia con il richiedere il RR SPF presso topolinia.com, a cui potrebbe corrispondere la risposta
| topolinia.com. IN SPF "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all" |
in cui si dichiara che l'indirizzo IP 198.51.100.123 e quelli nella sottorete 192.0.2.0/24 sono autorizzati ad inviare posta per mittenti @topolinia.com: in tal caso, se l'IP dell'SMTP di origine non ricade tra i casi ammessi, l'email dovrebbe essere rifiutata. In realtà il programma antispam che effettua questa verifica ne usa il risultato assieme agli altri controlli che esegue, per poi prendere una decisione complessiva. Di fatto, il responso delle verifiche SPF permette di realizzare un sistema di reputazione relativo al dominio mittente, mentre nel caso delle DNSBL la reputazione è quella dell'IP di origine.
In effetti questo metodo presenta degli svantaggi, come ad esempio l'obbligo per gli utenti di un ISP di utilizzare come SMTP di uscita quello del provider, rendendone problematico l'utilizzo in caso nomadico, anche se questo aspetto è controbilanciato dalla diffusione di interfaccie di tipo Webmail, per le quali l'SMTP di invio è sempre quello del provider stesso.
DomainKey Identified Mail
Chi riceve spam e vuol protestare, può scrivere al servizio di gestione degli abusi del proprio provider, o del provider intestatario del dominio da cui sembra provenire il traffico di spam. E' quindi interesse dei provider aderire a strumenti di controllo che permettano loro di dimostrare la propria estraneità al traffico spam, anche se in apparenza proveniente dal proprio dominio. Anche per questo, la RFC 6376 descrive la tecnica DKIM che consiste nella possibilità per il MTA di orgine di aggiungere alla email in partenza l'header DKIM-Signature: in cui inserire, tra le altre cose, la firma digitale del messaggio inviato, o almeno di alcune sue intestazioni come From: e Subject:, e dell'inizio del body. Chi riceve il messaggio può verificare tale firma disponendo la chiave pubblica del dominio che ha apposto la firma, reperita mediante una interrogazione al DNS usando come chiave, appunto il dominio firmatario.
In questo modo il provider che invia le email si dimostra come il vero autore di questa operazione di firma, mentre le email di spam che sembrano provenire dal dominio, ma sono state inviate mediante altri server, non disponendo di tale firma, possono essere scoperte più facilmente, e le segnalazioni al team anti abuso evitate, in quanto evidente che sono uscite da altri provider. D'altra parte, nessuno impedisce ad un utente legittimo del provider che implementa DKIM di produrre spam, regolarmente firmato: in tal caso sarà il team anti abuso a doversi attivare, pena la perdita di reputazione del provider intestatario del dominio.Altre architetture di telecomunicazione testuale
Prima della definizione del World Wide Web, il mondo di Internet funzionava principalmente in formato testo, ed anche così, molte persone scoprivano un mondo del tutto nuovo, e delle formidabili potenzialità di telecomunicazione con gli altri individui in rete. Probabilmente a quei tempi, gli individui che si affacciavano ad Internet erano effettivamente i più progressisti ed aperti ai cambiamenti, oppure era solo un effetto generato dalla curiosità per la novità e per la cosa che sta crescendo, oppure ancora gli utenti erano accomunati dallo stesso spirito pionieristico, ma fatto sta che la comunicazione era più ricca ed entusiasta. Citiamo nel seguito, cinque architetture di comunicazione testuale, di gruppo (e non): Mailing list, Newsgroup, BBS, Internet Relay Chat, e Instant Messenger.
Mailing List
Le mailing list non sono altro che liste di indirizzi email, usate in congiunzione ad un meccanismo, tale che uno stesso messaggio email venga distribuito automaticamente a tutti gli indirizzi che compaiono nella lista. Questo può avvenire in modo molto banale, configurando staticamente un server SMTP in modo da associare un singolo nome di utente fittizio (detto alias, o riflettore) alla lista, facendo si che le email dirette all'alias vengano in realtà ricevute da tutti. Il problema in questo caso, è che se nella lista si verificano avvicendamenti frequenti, diventa oltremodo noioso modificare a mano la lista dei componenti.
Automazione
Per questo, sono sviluppati dei programmi appositi, detti anche mail robot, o mailbot, che vengono eseguiti a seguito della ricezione di una email diretta a speciali indirizzi di gestione, grazie alla modifica del filealiases, in modo da redirigire il contenuto delle email, verso lo standard input dei mailbot. Se nella email sono individuati comandi particolari, come ad esempio la richiesta di iscrizione, o il desiderio di visionare l'elenco degli iscritti, questi comandi sono eseguiti dal mailbot, e l'esito inviato via email al richiedente.
Gestori
Un esempio celebre di questo genere di meccanismo è majordomo, così chiamato inspirandosi al latino major domus, ossia maestro della casa. Ora che Internet è quasi sinonimo di Web, diventa poco sensato amministrare una mailing list via email, e l'applicazione in assoluto più diffusa per la gestione delle mailing list, è Mailman, scritta in Python, e che permette una personalizzazione molto spinta sia da parte dei singoli iscritti, che da parte dell'amministratore della lista. E' appena il caso di menzionare il fatto che tutto il lavoro preparatorio di discussione per quanto riguarda lo sviluppo degli standard Internet da parte di IETF, avviene per mezzo di mailing lists.
Archiviazione
E' possibile archiviare la mailing list, in modo che i messaggi che vi transitano siano accessibili tramite interfaccia web. Ciò può essere realizzato o dallo stesso programma che gestisce la ML (come in effetti fa Mailman), oppure utilizzando un servizio di terze parti. Se poi l'interfaccia web all'archivio permette a chi legge anche di scrivere, allora si ottiene un risultato simile a quello del Newsgroup, a partecipazione aperta. Esempi di questo approccio sono Gmane, MARC, Nabble, Google Groups, Yahoo Groups.
Netiquette
E' una parola derivata dalla contrazione del vocabolo inglese net (rete) e quello di lingua francese étiquette (buona educazione), e descrive un insieme di regole di buona condotta, che dovrebbero disciplinare il comportamento di un utente di Internet nel rapportarsi agli altri, mediante meccanismi quali newsgroup, mailing list, forum, e-mail, o in genere, mediante qualunque tipo di comunicazione scritta. In questo contesto, assume significato l'uso degli emoticon, (compresi quelli in stile asiatico) per veicolare in modo esplicito il proprio stato d'animo, e disambiguare le circostanze in cui il lettore può equivocare che una frase scherzosa, possa invece essere ritenuta offensiva.
Newsgroup
Anzichè discutere mediante lo strumento delle mailing list, permettendo solo agli aderenti di partecipare, perché non permettere anche a terze persone di visionare ciò che è descritto dagli altri, e prendere parte alla discussione? Probabilmente per soddisfare questo desiderio, fu definito il protocollo NTTP (Network News Transfer Protocol, RFC 3977, che aggiorna la RFC 977), che ha dato vita al servizio indicato comeUsenet, a significare il possesso della rete da parte degli utenti: in effetti, partecipare a Usenet è l'equivalente virtuale dello scendere in piazza e discutere liberamente con gli altri dei fatti e dei temi che si desidera, e ciò rappresenta inequivocabilmente un elemento di democrazia.
Tecnicamente, i diversi server NNTP comunicano tra loro secondo il principio di mantenere sincronizzato l'insieme dei messaggi che ogni server riceve da parte degli utenti che vi si connettono, con quello degli altri server NNTP. Presso i server sono definiti i diversi argomenti di discussione, detti newsgroup, organizzati in gerarchie che categorizzano gli argomenti stessi in sotto-argomenti, e sotto-sotto argomenti. Considerando che Usenet ha una propagazione mondiale, e che ogni popolo ha pur sempre il diritto di discutere nella propria lingua, possiamo restringere il campo alla gerarchia in lingua italiana.
Per partecipare ad Usenet, la maggior parte dei lettori email offre la possibilità di definire un nuovo account news (anzichè email), configurando il newsserver a cui ci si desidera collegare, che in generale, corrisponde a quello ospitato presso il proprio provider. Infatti, come avviene per i server SMTP, anche i server NNTP negano l'accesso ai client esterni alla propria rete. In alternativa, esistono svariate iniziative che, in analogia al servizio di webmail, offrono una interfaccia web ai newsgroup, come a esempio Google e Roar, o Mailgate, che è stato un caso storico, ma poi venne chiuso. Anche se l'utilizzo dei newsgroup mediante client personale è più completo, e privo della pubblicità inserita dal portale, l'accesso web ha il vantaggio di non dipendere dalla conoscenza del proprio server NNTP, e può aiutare a farsi una idea.
BBS
I Bullettin Board Services si sono sviluppati parallelamente ai Newsgroup, e sono ormai quasi del tutto tecnologicamente superati, ma rappresentato tuttora un ottimo esempio di comunicazione assolutamente autogestita. Si tratta infatti, ancora una volta, di una rete di computer che mantengono sincronizzate le rispettive basi di messaggi, ma i collegamenti tra computer non si avvalevano della rete Internet, ma del modem su rete telefonica commutata, rimuovendo qualunque forma di dipendenza da fornitori di connettività dati. Attualmente, molte BBS oltre a fornire ai propri utenti un accesso via modem, sono altresì accessibili (per ironia) via Internet, che spesso usano anche per sincronizzarsi con gli altri nodi. Sebbene diverse BBS si possano accordare per mettersi in rete tra di loro in modo del tutto autonomo, esiste una rete mondiale di BBS che cooperano a mantenere viva una distribuzione globale alternativa, chiamataFidoNet.Internet Relay Chat
Le chat offerte da siti web e da applicazioni di Instant Messaging sono tutte evoluzioni delle chat con cui chi si collegava via modem ad una BBS, poteva dialogare con il gestore (sysop) della BBS stessa. Queste ultime forme di comunicazione, hanno a loro volta tratto ispirazione dal comando talk, in cui lo schermo del terminale viene suddiviso in due zone, ed i caratteri immessi dall'interlocutore, appaiono uno alla volta.
L'IRC (Internet Relay Chat) è la standardizzazione Internet dello stesso concetto, ed è basato su di un network di server chat, interconnessi a formare uno spanning tree, in modo da propagare in modo efficiente i messaggi che ogni server riceve dagli utenti connessi allo stesso. La formalizzazione IETF del protocollo di IRC è la RFC 1459, a cui sono da affiancare le successive evoluzioni, anche se le diverse implementazioni del server IRC tendono sempre a divergere un pò. Ad esempio, fin dall'inizio non si è previsto alcun supporto per i caratteri non-ASCII, con il risultato che possono coesistere clients che usano contemporaneamente codifiche diverse ed incompatibili (ad es. ISO 8859-1 e UTF-8).
La comunicazione su IRC avviene nell'ambito dei cosiddetti canali, che possono essere locali ad un certo server, oppure propagati a tutti i server che fanno parte delle rete IRC. Di reti IRC, al mondo ne esistono migliaia, e quella italiana più diffusa, è Azzurra, mentre quella con più utenti è IRCnet, a distribuzione mondiale; infine, Freenode offre principalmente supporto ai progetti OpenSource. Ci si collega con una vasta scelta di client.
Instant Messaging
Le applicazioni di Messaggistica istantanea hanno guadagnato una grande popolarità in virtù della visibilità di cui godono i service provider a cui fanno riferimento i rispettivi programmi client, ed i cui maggiori esponenti sono
- AIM - America On Line Instant Messenger - interopera con ICQ
- ICQ - gioco di parole con I seek You (ti sto cercando) - Creato da Mirabilis, venne acquista da AOL, poi fusasi con Time Warner
- Windows Live Messenger - indissolubilmente legato a Microsoft, è l'evoluzione del Windows Messenger
- Yahoo! Messenger - interopera con MSN
- Gtalk - Contrazione di Google talk ed integrato con Gmail, adotta standard aperti come XMPP
- C6 - l'unico pienamente Italiano - interopera con XMPP
- QQ - più di 160 milioni di persone lo usano in Cina
Ognuna di queste applicazioni consta di una popolazione di utenti, e tutti assieme individuano una community di utilizzatori, la cui numerosità stimata complessiva ammonta a diverse centinaia di milioni di individui.
Topologia e interlavoro
La maggior parte di queste applicazioni opera con una modalità client-server, in cui ogni client fa capo ad unico server centralizzato, che implementa il protocollo di comunicazione nei confronti di tutti i client. Inoltre, la politica più diffusa, è quella di ostacolare lo sviluppo di prodotti di terze parti che si possano connettere a queste reti, tentando di fidelizzare i propri utenti all'uso del proprio client, tramite il quale si possono più facilmente introdurre estensioni e nuove caratteristiche. Solo da poco, alcuni di questi provider stanno seguendo un approccio di "apertura" reciproca (come Yahoo e MSN, oppure AIM e ICQ), comunque sempre dettato da motivazioni commerciali.Client multiprotocollo
Cionostante, vi sono applicazioni tipicamente dell'Open Source, come ad esempio- Empathy - uno dei più completi, "vede" anche facebook, per linux
- Trillian - shareware ma dal sorgente chiuso
- Pidgin - precedentemente noto come Gaim, funziona anche su piattaforme non-Microsoft
- Kopete - permette l'uso di una webcam con gli utenti MSN e Yahoo
- Miranda - solo per Win
- Adium - solo per Mac
Standard aperti
In contrapposizione alle reti proprietarie sopra descritte, i servizi di messaggistica possono essere realizzati anche in accordo a specifiche pubbliche.Jabber - XMPP
Lo IETF ha pubblicato come RFC 3920, 21, 22 e 23, le specifiche dell'Extensible Messaging and Presence Protocol (XMPP), alla base del funzionamento della piattaformaJabber, e che offre una gamma veramente molto vasta di estensioni, sia stabili, che in via di sviluppo, che allo stadio di proposte.Architettura
La rete Jabber non prevede un unico server centralizzato, ma ogni utente è individuato da una URI del tipo di quelle previste per l'email, ed i messaggi che gli sono diretti,transitano per il server associato alla parte dominio della proprio indirizzo, proprio come avviene per le e-mail.
Interoperabilità
La architettura XMPP prevede l'esistenza di Gateway che interfacciano la rete Jabber con quelle basate sui diversi protocolli di Messagging, come ad es. MSN o ICQ, permettendo ad un client Jabber, di comunicare con tutti gli altri. Una volta che un client Jabber si connette ad un server che implementa il gateway verso la rete di messaggistica desiderata, deve comunicare al server jabber l'identità e le credenziali con le quali può accedere all'altra rete; a quel punto, il server Jabber si connetterà alla diversa rete impersonando l'identità del client, comportandosi come un proxy, e convertendo le primitive del protocollo di un lato del gateway, in quelle del protocollo dell'altro versante.SIMPLE
Il WG IETF SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) definisce come il protocollo SIP, progettato per il VoIP, possa offrire il supporto alle funzioni di Presenza e Messaggistica Istantanea, a loro volta definite nella RFC 2778. In particolare, nelle RFC 3265 e 3856, viene descritto il supporto a queste funzioni, mentre in un recente Draft, si riassume l'intreccio delle specifiche di cui tenere conto. Piuttosto che addentrarci in dettagli, esponiamo i concetti base coinvolti.
Presence
La funzione di Presenza è definibile come la gestione di una informazione di stato, relativa ad una entità definibile come Presentity, che viene resa nota ad un insieme di altre entità, definibili come Watchers.
| +---------------------------+ | PRESENCE SERVICE | +---------------------------+ ^ | | | | v +------------+ +------------+ | PRESENTITY | | WATCHER | +------------+ +------------+ |
Tipicamente una Presentity, di propria volontà, mentiene informato il gestore del servizio di presenza a riguardo dei propri cambiamenti di stato, mentre un Watcher può interrogare periodicamente il servizio di presenza, oppure (preferibilmente) sottoscrivere (Subscribe) il servizio, e ricevere delle notifiche (Notify) ogni qualvolta l'informazione sia cambiata.
La derivazione di queste definizioni, a partire dal tradizionale comportamento di una applicazione di messaggistica, in grado di mostrarci lo stato dei nostri contatti, è più che evidente. La possibilità di trasmettere a distanza, oltre ai propri scritti, oltre alla propria voce e/o immagine, anche la propria propensione alla comunicazione, apre un nuovo modo di intendere le telecomunicazioni, che meriterebbe senz'altro una approfondita analisi psico-sociale.
Rimanendo invece sul piano tecnico, notiamo come la formalizzazione delle funzioni di Presenza e Messaggistica Istantanea espressa nel contesto della RFC 2778, ha consentito di definire nella RFC 3859 un Common Profile for Presence (CPP), in modo tale che le applicazioni che aderiscono al CPP, abbiano buone possibilità di poter interoperare, e scambiarsi questo tipo di informazione.Social Networks
Di diffusione piuttosto recente, i loro punti di forza possono essere individuati nella possibilità di mantenere in contatto gruppi di persone legate da interessi comuni, e nella capacità di integrare in uno stesso contesto comunicativo contenuti mutuati da altre fonti Internet (come fa ad es. Facebook). Allo stesso tempo, i servizi di social network inglobano anche altre teconologie particolari come la chat multiutente e l'informazione di stato, che se aggiornata molto frequentemente diviene essa stessa una sorta di chat, come per Twitter.
All'aumentare del numero di utenti di una piattaforma di social network, crescono le tariffe proposte agli inserzionisti pubblicitari, replicando così un business model nato con la stampa, ed evolutosi con la televisione, in cui il bene venduto dell'editore è l'attenzione catturata ai propri lettori. Con la differenza che ora gli inserti pubblicitari possono non essere gli stessi per tutti gli utenti, ma possono invece essere differenziati in base alle caratteristiche presunte o desunte per ogni singolo utente.
Open Mobile Alliance
Effettivamente, il lavoro sviluppato del WG SIMPLE aderisce al CPP, così come vi aderiscono le specifiche emesse dall'Open Mobile Alliance (OMA), che definisce standard aperti per l'industria della telefonia mobile. Vi fanno parte tutti i maggiori produttori di telefonini e loro derivati, operatori mobili, e produttori di software, ed intrattiene relazioni con le altre organizzazioni di standardizzazione, come 3GPP, 3GPP2, IETF,W3C. E cosa dire, allora, di Open Handset Alliance? (video)
Funzioni Telemediali
Senza dover necessariamente ricorrere a tutti i costi al telefonino, le stesse applicazioni di messaggistica supportano funzioni audio-video del tutto equivalenti, se non superiori, a quelle offerte dagli operatori telefonici, ad un costo assai inferiore, al punto che i telefonini stessi, sono in procinto di saltare sul carro dell'accesso WiFi ad Internet. Infatti, oltre alle applicazioni storicamente ed esplicitamente nate per ilVoice over IP (VoIP) come H.323, SIP o Skype, anche i messenger nati per il solo supporto alla comunicazione testuale si stanno dotando di funzionalità di comunicazione audio e video, al punto da coniare per questi il termine di Voice over Instant Messaging (VoIM), mentre qualcuno prova ad usare il termine di CoIP-Communication over IP (video), a rimarcare la funzione di collante tra testo, voce e dati, svolta dalle applicazioni di messaggistica.
Mentre MSN, Yahoo, AIM e ICQ, al solito, adottano soluzioni proprietarie, Gtalk adotta libjingle, una estensione di XMPP. Inoltre, è da segnalare l'iniziativa di Gtalk2VoIP, che offre un gateway per le chiamate audio tra le reti MSN, Yahoo, AIM, ICQ, Gtalk, SIP e PSTN.
- —