Posta elettronica - Confidenzialità, integrità, 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.

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.

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.

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:

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.

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

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.

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.