Questo sito usa cookies, anche di terze parti. Se continui a navigare nel sito, presti il consenso all'uso dei cookies.
Se non sei d'accordo o necessiti di ulteriori informazioni, consulta la nostra Privacy Policy.

Venerdì, 08 Aprile 2011 00:00

Posta Elettronica Certificata: cosa è e a cosa serve veramente, come funziona e come se ne possono minimizzare i limiti

LA SITUAZIONE AD OGGI

In Italia si parla di Posta Elettronica Certificata ormai dal “lontano” 2005, quando un DPRpiuttosto coraggioso (come dimostrato dal numero di critiche ricevute in seguito) tentò di disciplinare giuridicamente l’invio di messaggi di posta elettronica ed equipararli, in determinate circostanze, alle comunicazioni cartacee inviate a mezzo posta raccomandata.

Da allora sono trascorsi poco più di 5 anni, un intervallo di tempo che se per un tecnico informatico corrisponde più o meno ad un’era glaciale, per la burocrazia italiana è a malapena necessario per iniziare a tirare le somme. In realtà la cosa non dovrebbe stupire più di tanto: in fondo parliamo di due mondi basati l’uno sulla flessibilità e la rapidità del mercato globale, l’altro sulla rigidità necessaria nella definizione di leggi e procedure che siano applicabili nel contesto forse ridotto, ma estremamente più eterogeneo, di un Paese come il nostro… figuriamoci quando si tratta di mettere d’accordo l’intera UE! 

Una delle maggiori critiche, a questo proposito, è quella che accusa la PEC di aver “reinventato la ruota”, creando un sistema complesso e limitato alla realtà italiana quando lo stesso obiettivo si sarebbe potuto raggiungere utilizzando standard internazionali e tecnologie già disponibili da tempo, che avrebbero tra l’altro semplificato l’interoperabilità con il resto del mondo. La verità è che da una parte, gli standard già esistenti sono tutti di tipo esclusivamente tecnico2 e quindi non necessariamente accettabili ai fini legali in quanto probabilmente non hanno superato un iter di certificazione tale da validarne l’affidabilità da un punto di vista legislativo; dall’altra, non è detto che la nostra PEC non diventi a breve essa stessa uno standard tecnico internazionale di riferimento (è stato abbozzato un draft di RFC a questo scopo3, anche se il progetto sembra essere ad un punto morto).

In quest’ottica, l’idea di definire prima l’aspetto giuridico – seppur partendo ovviamente da standard tecnici di base già consolidati (in fondo si parla sempre di posta elettronica) –, di individuare ed adeguare la tecnologia e quindi tornare a fare le correzioni necessarie alla normativa, appare probabilmente la più sensata, anche se inevitabilmente richiede che i tecnici lavorino con tempi e modalità cui non sono abituati.

C’è da dire in effetti che le critiche indirizzate al sistema PEC negli ultimi anni (almeno quelle fondate) sono state in genere ascoltate ed hanno portato a diverse integrazioni4 nelle regole tecniche divulgate da DigitPA, nonché a modifiche nella normativa volte a venire incontro alle esigenze tecniche di utenti e gestori. Oggi di fatto la PEC italiana, con oltre 2,2 milioni di caselle in 110 mila domini e quasi 53 milioni di messaggi certificati scambiati in un bimestre5, costituisce l’unico sistema istituzionalizzato per la certificazione legale dell’invio e della ricezione di messaggi di posta elettronica. Nonostante questo, il sistema PEC odierno non è ancora perfetto: alcuni problemi come la mancata certificazione del contenuto del messaggio, la possibilità che un messaggio certificato ricevuto da un utente non venga letto dal destinatario entro i tempi previsti dalla legge e, dal punto di vista del Gestore, le difficoltà di implementazione e di gestione di una piattaforma PEC rallentano tutt’oggi l’adozione del sistema da parte di tutti i cittadini – complice anche una non proprio trascinante campagna pubblicitaria.

LE INFRASTRUTTURE PEC

In una trasmissione PEC, ciò che viene certificato è quindi l’invio (e la ricezione) di un messaggio, non il contenuto della comunicazione stessa. In altre parole, come avviene nel caso di una raccomandata postale con ricevuta di ritorno, a fare fede sono le ricevute di invio e di ritorno.

Ciò che rende certificabili l’avvenuta ricezione ed i riferimenti temporali di un messaggio PEC sono infatti le ricevute generate dai sistemi coinvolti nella trasmissione: quando un utente PEC invia un’email ad un altro utente, riceve prima una “Ricevuta di Accettazione” da parte del proprio gestore per certificare l’invio del messaggio, quindi una “Ricevuta di Avvenuta Consegna” da parte del Gestore del destinatario che garantisce l’effettivo inserimento del messaggio nella casella dell’utente.

Lo schema sottostante evidenzia il dettaglio delle azioni effettuate durante lo scambio di un messaggio PEC.

 

 

Step

Azione Raccomandata AR

Azione E-mail PEC

1

Il mittente spedisce la lettera.

L’Utente A (il mittente) invia la mail.

2

L’ufficio postale consegna la ricevuta dell’invio.

Il Gestore salva la Ricevuta di Accettazione nella casella del mittente.

3

Il servizio postale recapita la lettera all’ufficio più vicino al destinatario.

L’e-mail viene consegnata via protocollo SMTP all’MTA di destinazione.

4

n.d.

Il Gestore del destinatario invia la Ricevuta di Presa in Carico all’MTA mittente.

5

La lettera viene consegnata all’indirizzo del destinatario. Contestualmente il destinatario firma la ricevuta e la consegna al postino.

L’e-mail viene salvata nella casella del destinatario.

6

Il servizio postale recapita la ricevuta di ritorno all’ufficio postale più vicino al mittente.

Il Gestore del destinatario genera la Ricevuta di Avvenuta Consegna e la trasmette via protocollo SMTP all’MTA mittente.

7

Il servizio postale consegna la ricevuta di ritorno al mittente.

Il Gestore del mittente salva la Ricevuta di Avvenuta Consegna nella casella del mittente.

8

n.d.

L’Utente B accede alla propria casella e prende visione del messaggio e delle ricevute generate dal sistema.

 

Uno dei punti di forza della PEC è la compatibilità con la posta elettronica standard: dal punto di vista tecnico, un’infrastruttura PEC è infatti composta fondamentalmente da un sistema di posta ordinaria opportunamente configurato e da un modulo di firma, che si occupa della verifica e della certificazione dei messaggi attraverso un apparato HSM, oltre che della generazione delle ricevute e degli avvisi previsti dalla normativa.

La comunicazione su internet è basata sul protocollo SMTP standard6, che utilizza i record MX impostati sui server DNS dei vari domini per inoltrare i messaggi al server che ne gestisce la posta certificata. Questo consente agli utenti PEC di inviare messaggi certificati ad indirizzi di posta elettronica ordinaria (PEO) e viceversa, anche se in questo caso cadono ovviamente i presupposti per la certificazione legale in quanto un sistema ordinario non è in grado di generare le ricevute di consegna.

Per certificare che tutte le e-mail e le notifiche non abbiano subito modifiche durante la trasmissione e che siano effettivamente state processate da un Gestore accreditato (e per garantire quindi l’identità del mittente e del destinatario), DigitPA mantiene un Indice dei Gestori PEC (IGPEC) in cui sono censite le chiavi pubbliche utilizzate da ciascuno di essi e la lista dei domini PEC gestiti. Ogni Gestore, infatti, è tenuto a creare una coppia di chiavi crittografiche la cui componente pubblica deve essere sottomessa al DigitPA per la firma da parte dell’apposita Certification Authority. All’atto della presa in carico, il testo dei messaggi viene incapsulato sotto forma di allegato in una nuova e-mail, chiamata “Busta di Trasporto”, il cui hash7 complessivo viene immediatamente firmato con il certificato digitale del Gestore; la stessa procedura viene applicata anche a tutti gli avvisi e le notifiche generate dal Gestore stesso, e garantisce che il messaggio ricevuto dal destinatario non sia stato modificato durante la trasmissione.

Ciascun Gestore è inoltre tenuto a conservare la propria chiave privata in un apparato hardware (HSM) certificato secondo standard di sicurezza internazionali8 per evitarne il furto o la contraffazione. Un’altra delle caratteristiche fondamentali della PEC consiste nella gestione delle anomalie e delle relative notifiche. Nel caso in cui occorrano errori durante la trasmissione del messaggio viene infatti inviato al mittente un apposito “Avviso”, rispettivamente:

• Avviso di Non Accettazione (per errori o problemi tecnici in carico al Gestore del mittente)

• Avviso di Mancata Consegna (nel caso in cui il destinatario non riceva il messaggio entro le 24 ore dall’invio)

Infine, nel caso in cui il Gestore del destinatario rilevi un errore nel protocollo PEC (come ad esempio l’impossibilità di verificare la firma elettronica contenuta nel messaggio), l’email viene consegnata sotto forma di “Anomalia”. In questo modo il destinatario riceverà comunque la comunicazione, ma saprà che quest’ultima non è stata trasmessa in conformità al protocollo PEC e quindi non ne possiede il valore legale: i messaggi inviati da un sistema di posta ordinaria ad un indirizzo PEC, e viceversa, rientrano in questa casistica.

L’insieme delle operazioni in carico al server di firma costituisce quindi il flusso che deve seguire un messaggio PEC per essere correttamente certificato e per garantire l’interoperabilità tra gestori diversi. DigitPA stabilisce questo flusso e ne verifica periodicamente l’adesione da parte di tutti i Gestori accreditati, imponendo quando necessario modifiche o, in caso di violazione grave che potrebbe compromettere le garanzie proprie del sistema PEC, sospendendo l’erogazione del servizio da parte del Gestore finché non sia risolto il problema.

LA SOLUZIONE MAILWARE PEC DI BABEL

Sebbene per i problemi strettamente normativi non si possa fare altro che attendere aggiornamenti da parte di DigitPA, dal punto di vista tecnico è possibile implementare una soluzione che venga incontro al Gestore, dal punto di vista della flessibilità e dell’amministrazione del sistema, ed all’utente, per quanto riguarda la sicurezza, l’affidabilità e la fruibilità del sistema.

Mailware PEC (MW:PEC), un prodotto aziendale, è la suite che combina un server di firma compliant alla normativa vigente con il consolidato sistema di messaging & collaboration Mailware Collaboration Suite (MCS). Essendo basato sul progetto open source Apache James Server, MW:PEC dispone di una componente server SMTP affidabile utilizzata per ricevere i messaggi dal sistema di frontend e di un meccanismo di accodamento (“queing”) per garantire che non vengano persi per nessun motivo, una volta presi in carico. E’ anche possibile sviluppare moduli specifici chiamati mailet per soddisfare eventuali esigenze particolari.

MW:PEC offre inoltre due importanti feature progettate analizzando i problemi precedentemente descritti: la funzionalità di archiviazione consente infatti di tenere traccia del contenuto delle e-mail certificate (il Gestore è tenuto ad archiviare esclusivamente i log e le ricevute) salvando automaticamente tutti i messaggi gestiti dal sistema in un filesystem dedicato (per il recupero manuale) o in un server IMAP49  dedicato, che può essere acceduto dagli utenti attraverso un client standard o un’apposita interfaccia web; il forward su PEO invece aiuta quegli utenti che sono abituati ad utilizzare un solo account di posta ordinaria e rischierebbero di perdere delle comunicazioni importanti ricevute nella propria casella PEC: il sistema consente infatti di inoltrare automaticamente i messaggi ricevuti verso una qualunque casella email esterna. Entrambe le funzionalità possono essere abilitate per singoli utenti attraverso attributi gestiti in un directory server LDAP, e permettono di specificare nel dettaglio quali tipi di messaggi devono essere archiviati e/o inoltrati.

Grazie all’utilizzo di standard consolidati, il modulo MW:PEC può essere affiancato da sistemi di posta elettronica diversi da MCS, purché includano i seguenti componenti (v. immagine):

• Un sistema di posta elettronica basato su protocolli di comunicazione standard per la trasmissione e l’archiviazione delle e-mail (SMTP, IMAP4) o Postfix, Dovecot, Courier-imap, Oracle Communications Suite, …

• Un directory server LDAP standard per il database degli utenti o Fedora 389, Oracle Directory Server EE, OpenLDAP, …

• Un database per il tracciamento e l’archiviazione dei log o MySql, Microsoft SQL Server, …

• Un HSM certificato FIPS 140-2 che supporti lo standard PKCS#11 o Oracle SCA6000 PCI card, SafeNet LUNA, AEP Series K, …

• Un sistema antivirus in grado di inserire un header personalizzato nel messaggio in caso di rilevazione di virus o ClamAV, Sophos PureMessage, …

MW:PEC offre inoltre una serie di tool integrati per ottemperare gli obblighi del Gestore quali l’aggiornamento dell’Indice dei Gestori, la comunicazione periodica delle statistiche e la possibilità di impostare delle notifiche di errore personalizzate destinate agli amministratori del servizio.

 

1 v. DPR 11 febbraio 2005, n.68 http://archivio.cnipa.gov.it/site/_files/DPR%2011%20febbraio%202005%20n.68.pdf
2 v. RFC3798 – Message Disposition Notification
3 v. http://www.ietf.org/id/draft-gennai-smime-cnipa-pec-08.txt
4 v. http://www.digitpa.gov.it/pec/normativa
5 Dati DigitPA aggiornati al 31/12/2010
6 v. RFC821 e successivi aggiornamenti – Simple Mail Transfer Protocol
7 Funzione matematica non reversibile utilizzata per produrre una stringa (sequenza di caratteri) di lunghezza fissa partendo da qualunque file o testo.
8 Il requisito minimo è la certificazione FIPS (Federal Information Processing Standards) 140-2 rilasciata dal NIST (National Institute of Standards and Technology)
9 v. RFC3501 – Internet Message Access Protocol v.4 rev.1
Claudio Tassini

Con il ruolo di Solutions Architect ha lavorato ad alcuni dei più importanti progetti di integrazione curati dall'azienda, supportando l'area di presales nella definizione dei dettagli tecnici dell'offerta e, come Project Manager, curando i rapporti con il cliente durante la fase di delivery.