Full thesis PDF

POLITECNICO DI MILANO
Facoltà di Ingegneria dell’Informazione
POLO REGIONALE DI COMO
Corso di Laurea Specialistica in
Ingegneria Informatica
CONFIGURAZIONE,TESTING E
DEPLOYMENT DI UNA
INFRASTRUTTURA DI POSTA
ELETTRONICA CERTIFICATA
Relatore: Prof. Marco Brambilla
Correlatore: Ing. Florian Daniel
Tesi di laurea di: Mauro Carlo Angiolini
matr. 667873
Anno Accademico 2006/2007

1. INTRODUZIONE ........................................................................................................ 7
1.1. Obiettivi dello stage ............................................................................................ 8
1.2. Struttura della tesi ............................................................................................. 8
2. DALLA RACCOMANDATA TRADIZIONALE ALLA POSTA ELETTRONICA CERTIFICATA 11
2.1. La raccomandata cartacea ................................................................................. 11
2.2. La raccomandata “online” .................................................................................. 11
2.3. Costi della raccomandata tradizionale .................................................................. 13
2.4. La Posta Elettronica Certificata ........................................................................... 14
2.5. Caratteristiche della Posta Elettronica Certificata ................................................... 15
2.6. I gestori di PEC ................................................................................................ 16
2.7. Elementi di diritto e PEC .................................................................................... 18
2.7.1. Innovazione, pubblica amministrazione e diritto .................................................... 18
2.7.2. Posta Elettronica Certificata : origini e normative .................................................. 20
3. REGOLE TECNICHE DEL SERVIZIO DI TRASMISSIONE DI DOCUMENTI INFORMATICI
MEDIANTE POSTA ELETTRONICA CERTIFICATA [5] ....................................................... 22
3.1. Definizioni ....................................................................................................... 22
3.2. Elaborazione dei messaggi ................................................................................. 25
3.3. Logging .......................................................................................................... 27
3.4. Punto di accesso .............................................................................................. 27
3.4.1. Controlli formali sui messaggi in ingresso ........................................................... 29
3.4.2. Avviso di non accettazione per eccezioni formali ................................................... 29
3.4.3. Ricevuta di accettazione .................................................................................... 30
3.4.4. Busta di trasporto ............................................................................................. 31
3.4.5. Avviso di mancata consegna per superamento dei tempi massimi previsti ................. 32
3.5. Punto di ricezione ............................................................................................. 33
3.5.1. Ricevuta di presa in carico ................................................................................. 35
3.5.2. Busta di anomalia ............................................................................................. 36
3.5.3. Avvisi relativi alla rilevazione di virus informatici ................................................... 37
3.5.3.1. Avviso di non accetazione per virus informatico.................................................... 37
3.5.3.2. Avviso di rilevazione virus informatico ................................................................ 38
3.5.3.3. Avviso di mancata consegna per virus informatico ................................................ 39
3.5.4. Punto di consegna ............................................................................................ 40
3.5.4.1. Verifiche sui messaggi in ingresso ...................................................................... 40
3.5.4.2. Ricevute di avvenuta consegna .......................................................................... 40
3.5.4.2.1. Ricevuta completa di avvenuta consegna .......................................................... 40
3.5.4.2.2. Ricevuta di avvenuta consegna breve ............................................................... 41
3.5.4.2.3. Ricevuta sintetica di avvenuta consegna ........................................................... 44
3.5.4.3. Avviso di mancata consegna ............................................................................. 45
3.6. Formati ........................................................................................................... 45
3.6.1. Riferimenti temporali ........................................................................................ 45
3.6.2. Formato data/ora utente ................................................................................... 46
3.7. Specifiche degli allegati ..................................................................................... 46
3.7.1. Corpo del messaggio ......................................................................................... 46
3.7.2. Messaggio originale .......................................................................................... 47
3.7.3. Dati di certificazione ......................................................................................... 47
3.8. Schema dei dati di certificazione ......................................................................... 47
3.9. Schema indice dei gestori di PEC ....................................................................... 49
3.10. Aspetti relativi alla sicurezza .............................................................................. 53
3.10.1. Firma ............................................................................................................. 53
3.10.2. Autenticazione ................................................................................................. 53
3.10.3. Colloquio sicuro ............................................................................................... 54
3.10.4. Virus .............................................................................................................. 54
3.10.5. Indice dei gestori di PEC .................................................................................... 55
3.11. Schema logico di funzionamento ......................................................................... 56
3.11.1. Interazione fra due domini di posta certificata ...................................................... 56
3

3.11.1.1. Busta di trasporto corretta e valida con consegna avente esito positivo .................. 56
3.11.1.2. Busta di trasporto corretta contenente virus informatico non rilevato dal gestore
mittente e consegna avente errore di consegna ............................................................... 57
3.11.1.3. Messaggio originale con virus informatico rilevato dal gestore mittente e avviso di non
accettazione ............................................................................................................... 58
3.11.2. Interazione fra un dominio di posta convenzionale (mittente) ed un dominio di posta
certificata (ricevente) ................................................................................................... 59
3.11.3. Interazione fra un dominio di posta certificata (mittente) ed un dominio di posta
convenzionale (ricevente) ............................................................................................. 60
4. SVILUPPO E TEST DI UN'INFRASTRUTTURA DI SUPPORTO PER LA PEC .................. 61
4.1. Introduzione al lavoro svolto .............................................................................. 61
4.2. Descrizione preliminare del lavoro ....................................................................... 61
4.3. Aspetti più significativi della messa in essere dell’infrastruttura ............................... 63
4.3.1. La virtualizzazione dell’infrastruttura ................................................................... 63
4.3.1.1. Microsoft Virtual Server 2005 ............................................................................ 64
4.3.1.2. Architettura delle macchine virtuali .................................................................... 66
4.3.1.3. Architettura delle reti virtuali ............................................................................. 67
4.3.1.4. Funzionalità per la gestione e utilizzo di Virtual Server .......................................... 68
4.3.2. Il laboratorio PEC ............................................................................................. 76
4.3.2.1. Macchina 1 : Domain Controller / logging PEC ................................................... 77
4.3.2.2. Macchina 2 : Frontend di Exchange ................................................................. 80
4.3.2.3. Macchina 3 – 4 : Nodi del cluster di Backend di Exchange ...................................... 81
4.3.3. Lo sviluppo delle componenti software ................................................................ 84
4.3.3.1. Procedura di deploy ......................................................................................... 84
4.3.3.2. Testing della soluzione ..................................................................................... 85
4.4. Conclusioni e visioni future ................................................................................ 86
5. METODO DI PROGETTO ........................................................................................... 88
5.1. Metodo di progetto a cascata ( Waterfall Model ) ................................................... 88
5.1.1. Definizione ...................................................................................................... 89
5.1.2. Fasi ................................................................................................................ 90
5.1.3. Punti di forza ................................................................................................... 94
5.1.4. Punti di debolezza ............................................................................................ 95
5.2. Metodo di progetto a spirale ( Spiral Model ) ........................................................ 97
5.2.1. Definizione ...................................................................................................... 97
5.2.2. Fasi ................................................................................................................ 98
5.2.3. Punti di forza .................................................................................................. 98
5.2.4. Punti di debolezza ........................................................................................... 98
5.3. MSF / MOF ...................................................................................................... 99
5.3.1. MSF................................................................................................................ 99
5.3.2. MOF ............................................................................................................. 102
5.3.2.1. Elementi di MOF ......................................................................................... 105
5.3.2.1.1. Il Team Model di MOF ............................................................................... 105
5.3.2.1.1.1. Principi fondamentali ............................................................................. 106
5.3.2.1.1.2. Gruppi di ruoli del team model ................................................................ 107
5.3.2.1.2. Il process model MOF ............................................................................... 109
5.3.2.1.2.1. Panoramica .......................................................................................... 109
5.3.2.1.2.2. Principi fondamentali ............................................................................. 109
5.3.2.1.2.3. Quadranti per il process model ................................................................ 110
5.3.2.1.3. La disciplina di risk management MOF ......................................................... 112
5.3.2.1.3.1. Panoramica .......................................................................................... 112
5.3.2.1.3.2. Principi fondamentali ............................................................................. 113
5.3.2.1.3.3. Processo di gestione dei rischi ................................................................. 113
APPENDICE .................................................................................................................. 115
1. MANUALE PER LA PROCEDURA DI DEPLOYMENT ................................................... 115
1.1. Cenni Preliminari ............................................................................................ 115
1.2. Nomi di Dominio ............................................................................................ 115
4

1.3. Certificati ...................................................................................................... 115
1.4. Infrastruttura ................................................................................................. 115
1.5. Utilizzo di MAPI vs SMTP .................................................................................. 115
1.6. SQL Server e ORACLE ..................................................................................... 116
1.7. ANTIVIRUS .................................................................................................... 116
1.8. Versioni del software, Patch e Service pack. ....................................................... 116
1.9. Descrizione di massima dell’infrastruttura .......................................................... 117
1.10. Procedura di installazione infrastruttura ............................................................. 118
1.10.1. Installazione sistemi operativi e software di base ................................................ 118
1.10.2. Certificati di root e per Posta-Certificata ............................................................ 121
1.10.3. Doppi Virtual Server SMTP sui Front End ............................................................ 123
1.10.4. Modifica dei file di configurazione ..................................................................... 127
1.10.5. Installazione Applicativa .................................................................................. 129
1.10.5.1. Exchange BackEnd ....................................................................................... 129
1.10.5.2. Exchange FrontEnd....................................................................................... 131
1.10.6. Database SQL ................................................................................................ 134
1.10.7. Patch per PEC ................................................................................................ 134
5.4. BIBLIOGRAFIA ...................................................................................................... 136
5

1. INTRODUZIONE
La presente tesi si occuperà inizialmente di introdurre al tema della Posta Elettronica Certificata
per poi procedere in una dettagliata descrizione del lavoro svolto durante lo stage presso
Microsoft, descrivendone in maniera accurata le milestones e i successivi affinamenti che hanno
permesso di realizzare un’implementazione funzionante di un laboratorio virtuale per la gestione
del flusso di Posta Elettronica Certificata. Trascurando il naturale entusiasmo che può comportare
il fatto di avere a disposizione uno strumento versatile come la raccomandata in forma elettronica,
è opportuno sottolineare come il progressivo raffinamento delle tecnologie informatiche, la
massificazione delle stesse e l’investimento in termini economici da parte dello stato di adeguare
la pubblica amministrazione al contesto abbia reso possibile l’ideazione della PEC.
Contestualmente all’approvazione del decreto legislativo relativo alla PEC, che consente di inviare
email aventi certificazione legale dell’avvenuta consegna, alcune società hanno iniziato ad offrire il
servizio a pagamento rivolgendosi dapprima alle aziende e in secondo luogo ai privati cittadini. Per
poter offrire tale servizio una società deve essere inserita nell’elenco pubblico dei gestori: i
requisiti per entrarne a far parte prevedono che la società disponga di un capitale sociale di
almeno 1 milione di euro, ovvero Pubbliche Amministrazioni (con alcune limitazioni). Inoltre, il
candidato Gestore viene valutato dal CNIPA rispetto a requisiti di onorabilità, adeguatezza del
personale, processi di sicurezza, esperienza nell’erogazione di servizi analoghi, ridondanza e
servizi di emergenza. stati più volte rivisti e modificati, contestualmente allo sviluppo del percorso
che ha portato alla definizione del decreto legge. Di fatto la barriera all’ingresso del livello minimo
di capitale sociale se da un lato limita il numero di enti che possono svolgere il ruolo di certificatori
( ad oggi sono undici ), dall’ altro tutela gli utilizzatori rendendo impossibile che qualcuno si illustri
fraudolentemente della carica di certificatore.
Entrando nel merito delle società che hanno contribuito alla realizzazione del progetto PEC occorre
citare EDS, multinazionale operante nell’ambito dello sviluppo software, che dopo aver vinto nel
Febbraio 1999 il bando di gara dell’ AIPA (Autorità per l'informatica nella pubblica
amministrazione, dal 30 giugno 2003 CNIPA, Centro nazionale per l'informatica nella pubblica
amministrazione) per la fornitura dei servizi di interoperabilità della PA, ha costituito un’apposita
società avente come oggetto sociale esclusivo la fornitura dei servizi oggetto della gara, EDSPA.
EDS/EDSPA è uno degli 11 certificatori PEC regolarmente iscritti all’elenco e Microsoft, in
collaborazione con il partner Tiq, si è occupata di implementare la soluzione software per la
7

gestione della PEC utilizzata da EDS. Nel dettaglio Microsoft si è occupata della parte
infrastrutturale della soluzione, affidando in outsourcing a Tiq lo sviluppo delle componenti
software necessarie per la gestione del flusso PEC. La soluzione è stata parallelamente messa in
produzione e utilizzata presso EDS, che si è occupata del testing e in parte dello sviluppo,
mantenendo i contatti con il Cnipa per verificare la conformità ai requisiti. I macro obiettivi
raggiunti nell’ambito del progetto sono stati :
Allestire un laboratorio di macchine per la gestione del flusso della PEC
o Allestire il laboratorio di macchine virtuali basandosi su tecnologia Microsoft
o Installare e configurare le componenti software specifiche responsabili del flusso PEC
o Effettuare il test di casi d’uso specifici
o Mantenere aggiornato il laboratorio considerando il versioning delle componenti custom
e degli aggiornamenti di sistema operativo e applicativi.
Scrivere la documentazione relativa al deployment della soluzione
1.1. Obiettivi dello stage
L’obiettivo primario dello stage svolto è stato quello di realizzare un’infrastruttura di Posta
Elettronica Certificata funzionante, adottabile in ambito produttivo. Molteplici e eterogenee sono le
skills sviluppate collateralmente nel portare a termine questo compito : da un lato si sono affinate
abilità pratiche, correlate con la conoscenza delle modalità e degli strumenti necessari per
effettuare deployment di sistemi operativi e software applicativi, dall’altro si sono acquisite
competenze tecniche e commerciali sugli applicativi coinvolti. Inoltre è stato possibile constatare
come si lavora in un’azienda di grandi dimensioni, familiarizzando con i workflow interni e le
modalità di lavoro. Oltre a produrre un laboratorio PEC funzionante, inseribile in ambito
produttivo, si è provveduto a scrivere una documentazione di installazione per agevolare il
trasferimento della conoscenza acquisita effettuando questo deployment. La documentazione
prodotta è consultabile in appendice.
1.2. Struttura della tesi
Nel presente documento si è deciso di affrontare l’argomento della Posta Elettronica Certificata in
maniera progressiva: dopo un’introduzione al contesto generale della PEC e dopo averne
giustificate le origini, anche dal punto di vista del diritto, si procede con la descrizione delle regole
8

tecniche sulla base delle quali è stato sviluppato il software custom adoperato per la realizzazione
del laboratorio. Si tracceranno infine alcune linee guida per ulteriori sviluppi e miglioramenti
futuri.
9

2. Dalla raccomandata tradizionale alla Posta Elettronica
Certificata
Per comprendere come si sia potuti arrivare alla concretizzazione della PEC e di quali siano i suoi
benefici rispetto all’utilizzo della raccomandata tradizionale, occorre entrare nel merito delle
caratteristiche di quest’ ultima.
2.1. La raccomandata cartacea
Come il sito di Poste Italiane spiega, la posta raccomandata viene utilizzata quando occorre
dimostrare che la spedizione di una missiva è stata effettuata, disponendo della certificazione
legale dell'avvenuta spedizione. Dal momento che ha valore legale è particolarmente adatta per
tutte quelle comunicazioni critiche per le quali è necessaria la certezza dell’avvenuta consegna,
come per esempio gare, concorsi pubblici, usi amministrativi e giudiziari. La raccomandata
cartacea può essere spedita esclusivamente recandosi presso un ufficio postale e compilando un
apposito modulo, una copia del quale resta come ricevuta al mittente. Una raccomandata cartacea
ha delle dimensioni fisiche da rispettare, il superamento delle quali determina l’impossibilità di
effettuare la spedizione :
Dimensioni minime: 14 centimetri di base per 9 di altezza
Dimensioni standard: da 14 a 23,5 centimetri di base e da 9 a 12 centimetri di altezza. Il
peso non può superare i 20 grammi e lo spessore non può essere più di mezzo centimetro
Dimensioni massime: 35,3 centimetri di base per 25 di altezza, 5 centimetri di spessore, 2
chili di peso
La lettera raccomandata una volta giunta a destinazione viene consegnata solo al destinatario o a
un suo incaricato. Se non c'è nessuno a riceverla, bisogna ritirarla all'ufficio postale indicato
nell'avviso. Entro 5 giorni di deposito presso l’ufficio postale il ritiro è gratuito, dal sesto al
10

trentesimo giorno si paga una mora quotidiana ( 0,52 euro ). Dopo trenta giorni la raccomandata
viene rispedita al mittente. Sono disponibili alcune servizi aggiuntivi a pagamento :
1. Avviso di Ricevimento
Necessario per ricevere la conferma dell'avvenuta consegna a destinazione della spedizione,
consta di una cartolina firmata dal destinatario o da chi ha effettuato il ritiro. L' avviso di
ricevimento prioritario costa 0,60 euro ed è disponibile anche l'avviso di ricevimento ordinario al
costo di 0,45 euro.
2. Contrassegno
Nel caso di contrassegno la raccomandata viene consegnata solo se il destinatario paga la cifra
stabilita. Se la cifra è inferiore a 250,00 euro il destinatario può pagare in contanti al portalettere.
Per cifre superiori, fino a un importo massimo di 3.000,00 euro, il ricevente deve andare all'ufficio
postale indicato nell'avviso che gli viene consegnato.
2.2. La raccomandata “online”
Una variante della raccomandata cartacea tradizionale è la cosiddetta “raccomandata online”, un
servizio di Poste Italiane che consente di inviare raccomandate direttamente dal computer: Poste
Italiane provvede alla stampa, all' imbustatura e alla consegna al destinatario tramite Posta
Raccomandata. La ricevuta della spedizione, che ha lo stesso valore legale della ricevuta fornita
con la raccomandata tradizionale, viene inviata da Poste Italiane nella casella di posta elettronica
"Postemail" del mittente. I documenti inviati sono automaticamente conservati per tre mesi in un
archivio online che il mittente può consultare in qualsiasi momento. Come per la Raccomandata
tradizionale è possibile richiedere l'Avviso di Ricevimento, che verrà recapitato per Posta Ordinaria
o Prioritaria. Il testo della raccomandata può essere fornito scrivendo direttamente online mentre
si è collegati al sito (lunghezza massima: 2 pagine in formato A4) oppure allegando un file già
preparato e memorizzato sul computer (lunghezza massima: 18 pagine in formato A4). Il file può
essere in formato doc, txt, tif, xls o jpg e avere una dimensione massima di 3 MB.
Successivamente la stampa della raccomandata viene effettuata in bianco e nero ed è possibile
effettuare il pagamento online. Lo stesso documento può essere inviato a più destinatari con una
sola operazione. Il numero massimo degli invii varia in base alla modalità di inserimento degli
11

indirizzi: mediante inserimento manuale si possono inserire fino a 10 destinatari, mediante
inserimento dalla rubrica fino a 200 destinatari .
Una volta spedita la raccomandata, sia che sia stata spedita a mano o via web, è possibile
effettuarne il tracking mediante il codice di invio riportato sulla ricevuta di spedizione, consegnata
a mano presso l’ufficio o inviato nella casella di posta elettronica "Postemail".
12

2.3. Costi della raccomandata tradizionale
Nella seguente tabella è possibile visualizzare i costi per l’invio di posta raccomandata
tradizionale.
Normale Normale + AR
(ordinaria/prioritaria)
Online Online + AR
(ordinaria/prioritaria)
Fino a 20 g. 2,80 euro 3,25 / 3,40 euro x x
Fino a 20 g.
(3 pagine
formato A4)
x x 3,50 euro 3,90 / 4,10 euro
Da 21 fino a
50g.
Da 51 fino a
100g.
Da 21 fino a
100g (da 4 a
18 pagine
formato A4 )
Da 100 fino a
250g.
Da 250 fino a
350g.
Da 350 fino a
1000g.
Da 1000 fino a
2000g
Da 2000 fino a
20000g
3,20 euro 3,65 / 3,80 euro x x
3,25 euro 3,70 / 3,85 euro x x
x x 4,50 euro 4,90 / 5,10 euro
4,05 euro 4,50 / 4,65 euro x x
4,15 euro 4,60 / 4,75 euro x x
6,35 euro 6,80 / 6,95 euro x x
8,35 euro 8,80 / 8,95 euro x x
12,50 euro 12,95 / 13,10 euro x x
Tabella 1 Costi per l’invio di raccomandate tradizionali [4]
13

2.4. La Posta Elettronica Certificata
Nel corso dell’ultimo decennio la posta elettronica è diventata sempre più uno strumento
indispensabile per la comunicazione tra privati, aziende e pubbliche amministrazioni, seppur
limitata dall’assenza di caratteristiche di sicurezza e di tracciabilità dei messaggi che la rendano
opponibile a terzi nel caso di contenziosi. Per questo fino ad oggi, per l’invio di documenti formali
importanti, ci si è avvalsi esclusivamente delle raccomandate con ricevuta di ritorno. Con la
creazione della Posta Elettronica Certificata (PEC) si è voluto introdurre uno strumento efficace,
economico e sicuro per garantire alle comunicazioni via internet lo stesso livello di sicurezza e
supporto legislativo che oggi hanno le raccomandate, colmando quel gap caratteristico dell’ e-Mail
tradizionale.
Per ottenere questi requisiti, è stato necessario regolamentare il meccanismo di Posta Elettronica
Certificata con apposite normative e offrire uno schema tecnico di supporto: in particolare il Testo
Unico sulla documentazione amministrativa (DPR 445/2000) e, più recentemente, il DPR 68/2005.
Con le regole tecniche emanate dal CNIPA ( Centro Nazionale per l’ Informatica nella Pubblica
Amministrazione ) e la pubblicazione dell’elenco pubblico dei gestori sono stati resi disponibili tutti
i presupposti perché la PEC divenga operativa.
La PEC completa il “ciclo di vita” del documento informatico, dalla formazione e sottoscrizione,
passando per la verifica della firma, la spedizione e ricevuta, il protocollo, per arrivare alla
conservazione : non manca nulla per sostituire la carta a tutti gli effetti con tutti i benefici che
questo adeguamento comporta.
Tecnicamente la PEC consta di un sistema di trasporto di documenti informatici fondato sul
servizio di posta elettronica tradizionale, a cui sono state aggiunte delle caratteristiche tali da
fornire agli utenti la certezza dell’invio e della consegna (o meno) dei messaggi e-mail al
destinatario. Può essere utilizzata per la trasmissione di tutti i tipi di informazioni e documenti in
formato elettronico e consente di certificare l’invio, l’integrità e l’avvenuta consegna del
messaggio scambiato tra il gestore di PEC del mittente e quello del destinatario. Dal punto di vista
legale la PEC ha lo stesso valore della tradizionale raccomandata con avviso di ricevimento
(garantendo, quindi, l’opponibilità a terzi dell’avvenuta consegna). In definitiva il servizio ha tutte
le caratteristiche della raccomandata con in aggiunte notevoli vantaggi sia in termini di tempo che
di costi. In particolare, nella PEC si riscontra:
Semplicità ed economicità di trasmissione, inoltro e riproduzione
Semplicità ed economicità di archiviazione e ricerca
Certificazione dell’invio e della e consegna del messaggio;
Opponibilità a terzi rispetto alle operazioni di invio e ricezione di un messaggio.
14

Facilità di invio multiplo, cioè a più destinatari contemporaneamente, con costi
estremamente più bassi rispetto a quelli dei mezzi tradizionali
Velocità della comunicazione ed inoltre non è necessaria la presenza del destinatario per
completare la consegna
Possibilità di consultazione ed uso anche da postazioni diverse da quella del proprio ufficio
o abitazione (basta un qualsiasi PC connesso ad Internet e un normale browser web), ed in
qualunque momento grazie alla persistenza del messaggio nella casella di posta
elettronica.
Livelli minimi di qualità del servizio e di sicurezza stabiliti dalla legge.
Diversamente dalla raccomandata tradizionale, nella ricevuta di avvenuta consegna sono
presenti anche i contenuti del messaggio originale (opponibilità del contenuto inviato ).
Semplice integrabilità con soluzioni applicative preesistenti.
La pubblica amministrazione utilizza un servizio di posta elettronica certificata già dal 2004 e la
pubblica amministrazione locale si è dotata del servizio in maniera progressiva durante gli ultimi 2
anni.
2.5. Caratteristiche della Posta Elettronica Certificata
Procedendo nell’analisi delle caratteristiche della PEC è necessario chiarire che la certificazione
offerta è relativa ai soli eventi di invio e di consegna del messaggio nella casella del destinatario.
Non si certifica la lettura del messaggio da parte del destinatario, allo stesso modo in cui nella
consegna di una raccomandata tradizionale si assicura solo l’avvenuta consegna della missiva e si
assume che il destinatario la legga. La PEC è in grado di garantire l’identità della casella mittente,
in quanto è assicurata l’inalterabilità dell’indirizzo associato alla casella dalla quale si effettua
l’invio del messaggio, cosi’ come è in grado di garantire l’associazione fra il titolare del servizio e
la relativa casella di posta elettronica certificata, infatti il soggetto che intende richiedere un
servizio di PEC, attivando una mailbox dedicata, deve presentare al Gestore di PEC, oltre che alla
richiesta di attivazione del servizio, anche un documento che attesti la sua identità diventando
quindi titolare del servizio. Per queste ragioni inviare mail di SPAM da un indirizzo di PEC
risulterebbe essere una pratica controproducente.
15

L’invio e la ricezione di messaggi di PEC hanno valore legale solo nel caso in cui il destinatario sia
dotato di una casella di Posta Elettronica Certificata: è solo mediante l’invio attraverso questo
circuito privilegiato che vengono generate le ricevute necessarie alla certificazione. E’ possibile
inviare messaggi anche ai possessori di una casella di posta elettronica non certificata, ma senza
alcun valore legale : questi ultimi riceveranno la mail imbustata come se se fosse una mail
certificata ma la generazione delle ricevute necessarie alla certificazione non avrà luogo. Dal
momento che la normativa impone ai differenti gestori di PEC di garantire la piena interoperabilità
dei servizi offerti è possibile inviare messaggi di Posta Elettronica Certificata tra utenti che
utilizzano Gestori di PEC differenti.
Nel caso in cui un messaggio sia stato effettivamente consegnato, il destinatario non può negarne
l’avvenuta ricezione, in quanto la ricevuta di avvenuta consegna del messaggio, firmata ed inviata
al mittente dal Gestore di PEC scelto dal destinatario, riporta la data e l’ora in cui il messaggio è
stato consegnato nella casella di PEC del destinatario, certificandone l’avvenuta consegna. Se si
smarrisce una ricevuta e occorre ottenerne una copia valida a fini legali bisogna rivolgersi al
proprio Gestore di PEC il quale, per legge, è obbligato a "registrare" e archiviare tutte le
operazioni relative alle trasmissioni effettuate per trenta mesi. Tali informazioni sono conservate
nel file di log, un registro informatico all’interno del quale vengono memorizzate tutte le
transazioni relative alle trasmissioni effettuate. Tale registro è indispensabile per la ricostruzione
delle ricevute, nel caso di eventuale smarrimento delle stesse. Per quel che concerne la sicurezza
e la privacy dei dati personali dei titolari di caselle PEC, la norma impone ai gestori di applicare
tutte le procedure atte a garantire la sicurezza e la privacy dei dati personali. Analogo livello di
sicurezza è garantito anche per le informazioni archiviate nel log delle trasmissioni.
2.6. I gestori di PEC
Per richiedere e attivare il servizio di PEC occorre rivolgersi ad uno dei Gestori iscritti nell’indice
tenuto dal CNIPA. Possono offrire tale servizio solamente le aziende e le Pubbliche
Amministrazioni che, presentata la domanda di accreditamento al Cnipa, superino l’istruttoria
dimostrando di essere in possesso dei requisiti richiesti dalla normativa di riferimento. Tali
soggetti, divenuti Gestori di PEC, sono iscritti in un apposito elenco pubblico tenuto dal Cnipa. Per
attivare la casella di PEC è necessario che l’utente scelga (in funzione delle proprie
esigenze/preferenze) il Gestore di PEC con cui vuole attivare la propria casella e quindi seguire le
istruzioni contenute nel manuale operativo del Gestore scelto. Dopo aver sottoscritto un contratto
16

con un Gestore di PEC si ottengono servizi di gestione di caselle di posta, ricevute opponibili,
accesso ai log in caso di smarrimento di una ricevuta o contestazioni, livelli minimi di servizio
garantiti dalla normativa. Per quanto riguarda le imprese, nei rapporti tra loro intercorrenti,
possono dichiarare la esplicita volontà di accettare l’invio di Posta Elettronica Certificata mediante
indicazione nell’atto di iscrizione al registro delle imprese (http://www.infoimprese.it/),
specificando il proprio indirizzo.
Per diventare Gestori di PEC occorre essere una società con capitale di almeno 1 milione di euro
interamente versato, oppure una pubblica amministrazione (con alcune limitazioni), e
naturalmente occorre presentare domanda di iscrizione nell’apposito elenco pubblico al CNIPA[6].
Il candidato Gestore viene valutato dal CNIPA rispetto a:
o Requisiti di onorabilità
o Adeguatezza del personale
o Procedure di sicurezza
o Esperienza nell’erogazione di servizi analoghi
o Ridondanza e servizi di emergenza
I Gestori di PEC hanno l’obbligo di rispettare i requisiti, le prescrizioni tecniche e i livelli minimi di
servizio. Inoltre devono dotarsi della certificazione di qualità ISO 9000 per il processo PEC, di una
polizza assicurativa e devono consentire eventuali attività di vigilanza da parte di incaricati del
CNIPA. Tale esercizio, detto vigilanza a regime, è effettuato dal Cnipa con controlli periodici - su
segnalazione - attraverso l’emissione di delibere e atti di indirizzo, con incontri periodici e
attraverso l’acquisizione di informazioni. Il CNIPA prima di accettare una domanda di iscrizione
all’elenco dei Gestori di PEC effettua la verifica dei requisiti oggettivi e soggettivi, sulla base di
quanto richiesto dalla norma; in caso positivo il nuovo Gestore viene iscritto nell’elenco pubblico e
messo in condizione di erogare il servizio. Le modalità di accreditamento nell'elenco pubblico dei
gestori sono dettagliate nella Circolare del Cnipa 49/2005.
Consultando l’elenco pubblico dei Gestori di PEC è possibile sapere chi sono i gestori di PEC:
l’elenco riporta la lista esaustiva dei gestori abilitati ad offrire il servizio. Posto che il servizio
offerto dai gestori deve rispettare numerosi requisiti di base che sono stabiliti dalla normativa e
controllati dal CNIPA all’atto dell’iscrizione nell’elenco pubblico dei Gestori, ciascun operatore
abilitato può personalizzare e valorizzare la propria offerta ed è libero di fissare le proprie
strategie commerciali e di prezzo. Attraverso Internet è possibile visitare i siti dei diversi Gestori di
PEC e confrontare le caratteristiche del servizio ed i prezzi, scegliendo poi in funzione delle proprie
esigenze. Tutti i Gestori di PEC sono tenuti a pubblicare sui loro siti il manuale operativo del
17

servizio che descrive tutte le principali caratteristiche tecniche dell’offerta. I livelli minimi di qualità
e continuità del servizio garantiti dai Gestori del servizio di PEC sono dettati dalla normativa di
riferimento e approfonditi nel seguente capitolo.
Esiste un servizio denominato "Indice delle Pubbliche Amministrazioni" (IPA) consultabile on line
che agglomera tutti gli indirizzi PEC delle PA all’indirizzo http://www.indicepa.gov.it/, mentre per i
privati la pubblicazione è possibile solo in caso di consenso esplicito.
2.7. Elementi di diritto e PEC
L’ingresso delle nuove tecnologie nel panorama giuridico ha presentato la necessità di riformare
alcuni concetti che sono alla base del Diritto Amministrativo e non solo, provocando un
ripensamento delle convinzioni dottrinali alle quali per anni si è ispirata l’azione amministrativa.
Il processo di osmosi che ha visto come attori tecnologia e diritto ha dato vita a nuovi istituti
giuridici che hanno recentemente ricevuto una formale investitura da parte delle fonti normative
italiane e comunitarie, risultando essere tra i maggiori impulsi di rinnovamento della pubblica
amministrazione, bisognosa di una riforma volta al miglioramento della sua operatività.
Attraverso l’analisi giuridica dei principali fattori innovativi legati al rinnovo informatico della
pubblica amministrazione e la dimostrazione della perfetta equiparazione giuridica tra le nuove
figure figlie dell’applicazione delle tecnologie al diritto e i paralleli istituti classici, si puo’
presumere che l’informatizzazione dell’azione amministrativa porterà ad un sensibile
miglioramento del servizio pubblico, consentendo l’avvicinamento dell’amministrazione alle
esigenze dei cittadini, per renderla più pronta nell’assolvimento dei propri compiti istituzionali.
2.7.1. Innovazione, pubblica amministrazione e diritto
Le principali novità nel panorama giuridico sono rappresentate dal documento informatico, ovvero
la rappresentazione informatica di atti, fatti o dati giuridicamente rilevanti, un atto prodotto in
forma elettronica per mezzo di sistemi informatici che in tale forma dispiega i propri effetti, e la
firma digitale, il risultato di una procedura informatica che consente di rendere certa la
18

provenienza e l’integrità di un documento informatico, emulando perfettamente la funzione della
firma autografa e fornendo maggiore certezza e flessibilità.
Questi due nuovi istituti giuridici, disciplinati compiutamente nel testo unico sulla documentazione
amministrativa (D.P.R. 445/2000), sono alla base della riforma informatica della Pubblica
Amministrazione e consentiranno non solo di snellire, proceduralizzare e standardizzare l’attività
amministrativa, ma anche di fornire maggiori garanzie per ciò che concerne la certezza dei
documenti amministrativi che, nella forma elettronica, se rispondenti agli accorgimenti tecnici
indicati nella normativa in materia, risultano più affidabili rispetto ai classici atti prodotti in forma
cartacea.
La gestione dei flussi documentali e la relativa archiviazione rappresenta uno dei compiti più
onerosi cui deve far fronte la pubblica amministrazione. Con l’introduzione delle nuove figure
giuridiche finalizzate alla “digitalizzazione” dell’azione amministrativa è possibile fare a meno degli
atti cartacei e dei relativi bolli, marche e punzoni, consentendo la lavorazione delle pratiche, la
loro archiviazione e protocollazione su supporti elettronici aventi il pregio di essere di dimensioni
ridotte e di poter contare su una elevatissima flessibilità gestionale. Cosi’ come la trasmissione di
atti, documenti e informazioni tra uffici e tra amministrazioni avviene su canali telematici,
abbattendo tempi e costi che hanno storicamente appesantito il procedimento amministrativo, e
consentendo alle pubbliche amministrazioni maggiore funzionalità e razionalità.
Il cammino intrapreso mediante la comparsa e la progressiva adozione delle nuove tecnologie
conduce a un sistema di “teleamministrazione”, ovvero di un’amministrazione della cosa pubblica
condotta con l’ausilio dell’informatica, volta allo scopo di eliminare la carta come strumento
fondamentale dell’attività amministrativa a vantaggio di atti, documenti e firme elettronici aventi il
pregio di una maggiore flessibilità, che consenta all’amministrazione un’erogazione dei servizi per
mezzo di collegamenti informatici che possano garantire una razionale e veloce interconnesione
tra le varie amministrazioni pubbliche e l’offerta ai cittadini di una diretta partecipazione al
procedimento amministrativo. Ha concorso all’estensione di queste nuove fuzionalità l’introduzione
della carta d’identità elettronica (una tessera magnetica dotata di micro-chip), che oltre ad
espletare le caratteristiche funzioni di documento di riconoscimento, è destinata a divenire una
vera e propria “carta multifunzionale” del cittadino, per mezzo della quale lo stesso potrà accedere
telematicamente ai servizi offerti dalle amministrazioni pubbliche. Una migliore efficienza
dell’amministrazione ed un razionale impiego delle risorse, grazie al proficuo utilizzo delle nuove
tecnologie nelle amministrazioni dello Stato, porterà ad una sensibile diminuzione dei costi e dei
tempi attualmente necessari per lo svolgimento di operazioni burocratico amministrative,
compatibilmente con i tempi di adozione e ambientamento con questi nuovi strumenti. La PEC
completa il ciclo di gestione documentale elettronica rendendo possibile l’invio e la ricezione
provato a termini di legge di documenti elettronici.
19

2.7.2. Posta Elettronica Certificata : origini e normative
Vediamo ora cosa succede nel caso in cui sia il mittente che il destinatario siano entrambi
attrezzati con caselle di posta certificata. L’art. 14 del Testo Unico sulla documentazione
amministrativa (D.P.R. n. 445/2000) indica i principi idonei a dare piena validità legale a tale
fattispecie di trasmissione: “La trasmissione del documento informatico per via telematica, con
modalità che assicurino l’avvenuta consegna, equivale alla notificazione per mezzo della posta nei
casi consentiti dalla legge.” La norma equipara, nei casi consentiti dalla legge, il valore giuridico
della trasmissione di un documento informatico (un messaggio e-mail, nel nostro caso), a quello
della notificazione postale. La norma dispone altresì una condizione indispensabile affinché ciò
accada, ovvero che la trasmissione debba essere effettuata con modalità che assicurino l’avvenuta
consegna: ecco il motivo per cui è stata “inventata” la posta elettronica certificata (PEC), ovvero
un sistema di posta elettronica che certifica sia il momento di avvenuta spedizione che quello di
avvenuta consegna di un documento informatico. Il D.P.R. 11 febbraio 2005 n. 68 [1]
(Disposizioni per l'utilizzo della posta elettronica certificata, a norma dell'articolo 27 della legge 16
gennaio 2003, n. 3) ha recentemente regolamentato l’utilizzo della posta elettronica certificata, di
seguito denominata PEC. Nel momento il cui il mittente invia un proprio messaggio di posta
elettronica riceve dal proprio gestore di posta una ricevuta che costituisce prova dell’avvenuta
spedizione. Quando il messaggio perviene al destinatario il gestore di posta di quest’ultimo, invia
al mittente la ricevuta di avvenuta consegna, che attesta che il messaggio è effettivamente
pervenuto, indicando anche il momento esatto in cui tale consegna è avvenuta.
La ricevuta di avvenuta consegna, secondo quanto stabilito dal comma 5, viene rilasciata nel
momento in cui il messaggio viene consegnato nella casella di posta elettronica del destinatario a
prescindere dalla avvenuta lettura del messaggio da parte del destinatario. Vi è quindi
contemporaneità tra il rilascio della ricevuta di consegna al mittente e la consegna stessa del
messaggio nella casella di posta elettronica del destinatario. Insieme alla ricevuta di consegna,
come previsto dal comma 4, il gestore del destinatario può inviare al mittente anche la copia
completa del testo del messaggio, al fine di dimostrare che è effettivamente quello il messaggio
consegnato. Le modalità relative alla possibilità tecnologica che oltre alla ricevuta sia restituita al
mittente la copia completa del testo del messaggio saranno definite nelle regole tecniche di
prossima emanazione. Il comma 7 prevede poi che, nel caso in cui il mittente abbia smarrito le
ricevute, la traccia informatica delle operazioni svolte (log) conservata su un apposito registro
informatico a cura dei gestori, secondo quanto previsto dall’articolo 11, comma 2, ha il medesimo
valore giuridico delle ricevute ed è opponibile ai terzi ai sensi dell’articolo 14 del D.P.R. n.
445/2000. E’ importante infine notare che il meccanismo della PEC non attesta l’avvenuta lettura
20

del messaggio da parte del destinatario ma solo il recapito nella sua casella di posta, esattamente
come la consegna della raccomandata postale da parte del postino nelle mani del destinatario non
dà alcuna informazione sull’apertura della busta e sulla lettura del suo contenuto. L’art.6 del
decreto sulla PEC disciplina il rilascio delle ricevute di accettazione e di avvenuta consegna di un
messaggio di posta elettronica certificata, che rappresentano la peculiarità di questo sistema di
trasmissione che gli conferisce, appunto, pieno valore legale.
Scopo della posta elettronica certificata tuttavia, contrariamente a quanto si possa pensare ad un
primo approccio, non è quello di garantire integrità e autenticità del contenuto del messaggio,
bensì quello di dare certezza al processo di inoltro del messaggio stesso, a partire dalla presa in
carico da parte del sistema sino all’atto della consegna nella mailbox del destinatario. E’ lo stesso
concetto della posta raccomandata tradizionale cartacea: il sistema non entra nel merito di cosa
sia stato spedito, ma è in grado di garantire che ciò che è stato spedito non è stato alterato
durante il processo di consegna e che è stato consegnato al destinatario in tempi e con modalità
certe.
21

3. Regole tecniche del servizio di trasmissione di documenti
informatici mediante posta elettronica certificata [5]
Il Centro Nazionale per l’ Informatica nella Pubblica Amministrazione ( CNIPA ) è un organo
collegiale che opera “presso” la Presidenza del Consiglio per l’attuazione delle politiche del Ministro
per l’innovazione (MIT), con autonomia tecnica, funzionale, amministrativa, contabile e finanziaria
e con indipendenza di giudizio. Le funzioni del CNIPA nei confronti della Pubblica Amministrazione
sono quelli di :
o
o
o
o
o
Indirizzare lo sviluppo dei sistemi informativi
Coordinare e gestire grandi progetti intersettoriali
Definire criteri e regolamenti di sicurezza, interoperabilità, standard aperti, qualità
Emettere pareri di congruità tecnico economico strategica sui progetti
Coordinare la predisposizione di piani di formazione del personale
Mentre nei confronti di cittadini e imprese:
o
o
o
Contribuire alla definizione della politica del Governo, lavorando in stretto contatto con il
MIT
Attuare progetti di innovazione e di e-government
Fornire consulenza per la stesura di progetti di legge nel settore informatico
Il CNIPA si è occupato della stesura e della pubblicazione delle regole tecniche che standardizzano
il funzionamento della Posta Elettronica Certificata. Tali regole descrivono in maniera univoca e
tecnicamente esauriente il funzionamento della PEC, dando la possibilità di sviluppare
un’infrastruttura ad hoc che implementando l’architettura descritta realizzi un servizio
tecnicamente compliant di Posta Elettronica Certificata.
3.1. Definizioni
Le seguenti definizioni esplicano il ruolo di ogni attore coinvolto nella gestione del flusso di PEC.
Punto di accesso
È il punto che fornisce i servizi di accesso per l’invio e la lettura di messaggi di posta elettronica
certificata, nonché i servizi di identificazione ed accesso dell’utente, di verifica della presenza di
22

virus informatici all’interno del messaggio, di emissione della ricevuta di accettazione, di
imbustamento del messaggio originale nella busta di trasporto.
Punto di ricezione
È il punto che riceve il messaggio all’interno di un dominio di posta elettronica certificata, effettua
i controlli sulla provenienza/correttezza del messaggio ed emette la ricevuta di presa in carico,
imbusta i messaggi errati in una busta di anomalia e verifica la presenza di virus informatici
all’interno dei messaggi di posta ordinaria e delle busta di trasporto.
Punto di consegna
È il punto che compie la consegna del messaggio nella casella di posta elettronica certificata del
titolare destinatario. Verifica la provenienza/correttezza del messaggio, emette, a seconda dei
casi, la ricevuta di avvenuta consegna o l’avviso di mancata consegna.
Ricevuta di accettazione
È la ricevuta, contenente i dati di certificazione, rilasciata al mittente dal punto di accesso a fronte
dell’invio di un messaggio di posta elettronica certificata. La ricevuta di accettazione è firmata con
la chiave del gestore di posta elettronica certificata del mittente.
Avviso di non accettazione
E’ l’avviso che viene emesso quando il gestore mittente è impossibilitato ad accettare il messaggio
in ingresso. La motivazione per cui non è possibile accettare il messaggio è inserita all’interno del
testo della ricevuta che esplicita inoltre che il messaggio non potrà essere consegnato al
destinatario. L’avviso di non accettazione è firmato con la chiave del gestore di posta elettronica
certificata del mittente.
Ricevuta di presa in carico
È emessa dal punto di ricezione verso il gestore di posta elettronica certificata mittente per
attestare l’avvenuta presa in carico del messaggio da parte del dominio di posta elettronica
certificata di destinazione. Nella ricevuta di presa in carico sono inseriti i dati di certificazione per
consentirne l’associazione con il messaggio a cui si riferisce. La ricevuta di presa in carico è
firmata con la chiave del gestore di posta elettronica certificata del destinatario.
Ricevuta di avvenuta consegna
Il punto di consegna fornisce al mittente la ricevuta di avvenuta consegna nel momento in cui il
messaggio è inserito nella casella di posta elettronica certificata del destinatario. È rilasciata una
ricevuta di avvenuta consegna per ogni destinatario al quale il messaggio è consegnato. La
ricevuta di avvenuta consegna è firmata con la chiave del gestore di posta elettronica certificata
del destinatario.
Ricevuta completa di avvenuta consegna
E’ caratterizzata dal contenere in allegato i dati di certificazione ed il messaggio originale.
23

Ricevuta breve di avvenuta consegna
E’ caratterizzata dal contenere in allegato i dati di certificazione ed un estratto del messaggio
originale.
Ricevuta sintetica di avvenuta consegna
E’ caratterizzata dal contenere in allegato i dati di certificazione.
Avviso di mancata consegna
Nel caso in cui il gestore di posta elettronica certificata sia impossibilitato a consegnare il
messaggio nella casella di posta elettronica certificata del destinatario, il sistema emette un avviso
di mancata consegna per indicare l’anomalia al mittente del messaggio originale.
Messaggio originale
È il messaggio originale inviato da un utente di posta elettronica certificata prima del suo arrivo al
punto di accesso. Il messaggio originale è consegnato al titolare destinatario per mezzo di una
busta di trasporto che lo contiene.
Busta di trasporto
È il messaggio creato dal punto di accesso, all’interno del quale sono inseriti il messaggio originale
inviato dall’utente di posta elettronica certificata ed i relativi dati di certificazione. La busta di
trasporto è firmata con la chiave del gestore di posta elettronica certificata mittente. La busta di
trasporto è consegnata immodificata nella casella di posta elettronica certificata di destinazione
per permettere la verifica dei dati di certificazione da parte del ricevente.
Busta di anomalia
Quando un messaggio errato/non di posta elettronica certificata deve essere consegnato ad un
titolare, esso viene inserito in una busta di anomalia per evidenziare al destinatario detta
anomalia. La busta di anomalia è firmata con la chiave del gestore di posta elettronica certificata
del destinatario.
Dati di certificazione
E’ un insieme di dati che descrivono il messaggio originale e sono certificati dal gestore di posta
elettronica certificata del mittente. I dati di certificazione sono inseriti nelle varie ricevute e sono
trasferiti al titolare destinatario insieme al messaggio originale per mezzo di una busta di
trasporto. Tra i dati di certificazione sono compresi: data ed ora di invio, mittente, destinatario,
oggetto, identificativo messaggio, ecc.
Gestore di posta elettronica certificata
È il soggetto che gestisce uno o più domini di posta elettronica certificata con i relativi punti di
accesso, ricezione e consegna. È titolare della chiave usata per la firma delle ricevute e delle
buste. Si interfaccia con altri gestori di posta elettronica certificata per l’interoperabilità con altri
titolari.
24

Dominio di posta elettronica certificata
Corrisponde ad un dominio DNS dedicato alle caselle di posta elettronica dei titolari. All’interno di
un dominio di posta elettronica certificata tutte le caselle di posta elettronica certificata devono
appartenere a titolari. L’elaborazione dei messaggi di posta elettronica certificata (ricevute, buste
di trasporto, ecc.) deve avvenire anche nel caso in cui il mittente ed il destinatario appartengano
allo stesso dominio di posta elettronica certificata.
Indice dei gestori di posta elettronica certificata
Consiste in un server LDAP posizionato in un’area raggiungibile dai vari gestori di posta elettronica
certificata che costituisce la struttura tecnica relativa all’elenco pubblico dei gestori di posta
elettronica certificata. Contiene l’elenco dei domini e dei gestori di posta elettronica certificata con
i relativi certificati corrispondenti alle chiavi usate per la firma delle ricevute e delle buste di
trasporto.
Casella di posta elettronica certificata
È una casella di posta elettronica alla quale è associata una funzione che rilascia delle ricevute di
avvenuta consegna al ricevimento di messaggi di posta elettronica certificata. Una casella di posta
elettronica certificata può essere definita esclusivamente all’interno di un dominio di posta
elettronica certificata.
Titolare
È il soggetto a cui è assegnata una casella di posta elettronica certificata.
Marca temporale
E’ un'evidenza informatica con cui si attribuisce, ad uno o più documenti informatici, un
riferimento temporale opponibile ai terzi secondo quanto previsto dal decreto del Presidente della
Repubblica 28 dicembre 2000, n. 445 e dal decreto del Presidente del Consiglio dei Ministri 13
gennaio 2004, pubblicato nella Gazzetta Ufficiale del 27 aprile 2004, n. 98.
3.2. Elaborazione dei messaggi
Il sistema di PEC genera i messaggi (ricevute, avvisi e buste) in formato MIME. I messaggi sono
composti da una parte di testo descrittivo, per l’utente, e da una serie di allegati (messaggio
originale, dati di certificazione, ecc.) variabili a seconda della tipologia del messaggio. Il
messaggio (composto dall’insieme delle parti descritte nelle specifiche sezioni del presente
allegato) è quindi inserito in una struttura S/MIME v3 in formato CMS, firmata con la chiave
privata del gestore di posta certificata. Il certificato associato alla chiave usata per la firma deve
essere incluso in tale struttura. Il formato S/MIME usato per la firma dei messaggi generati dal
sistema è il “multipart/signed” (formato .p7s) così come descritto nella RFC 2633 al paragrafo
25

3.4.3. I messaggi sono trasferiti tra gestori usando una codifica a 7 bit sia per gli header sia per il
corpo del messaggio e gli eventuali allegati. Per garantire la possibilità di verifica delle firme
presenti sui messaggi di posta certificata, sul più ampio numero di client di posta elettronica
possibile, i certificati X.509v3 utilizzati dai sistemi di posta elettronica certificata dovranno
rispettare il profilo proposto nell’allegato tecnico del CNIPA. Per garantire la verificabilità della
firma da parte del client di posta ricevente, il mittente del messaggio deve coincidere con quello
specificato all’interno del certificato usato per la firma S/MIME. Questo meccanismo comporta che
le buste di trasporto riportino nel campo “From” un indirizzo di posta mittente differente da quello
del messaggio originale. Al fine i consentire una migliore fruibilità del messaggio da parte
dell’utente finale, l’indirizzo di posta mittente del messaggio originale è inserito come “display
name” mittente nel messaggio. Ad esempio, per un messaggio originale con il seguente campo
“From”:
From: "Mario Bianchi"
la relativa busta di trasporto generata avrà un campo “From” del tipo:
From: "Per conto di: mario.bianchi@dominio.it"
Per consentire che eventuali risposte alla busta di trasporto siano correttamente indirizzate verso
il mittente originale, è necessario che l’indirizzo di quest’ultimo sia riportato nel campo “Reply-To”
della busta di trasporto. Qualora tale campo non fosse esplicitamente specificato nel messaggio
originale, il sistema che genera la busta di trasporto provvede a crearlo estraendolo dal campo
“From” del messaggio originale. Per l’invio delle ricevute, il sistema usa come destinatario
esclusivamente il mittente del messaggio originale così come specificato nel dato di “reverse path”
del protocollo SMTP. Le ricevute devono essere inviate alla casella di posta certificata del mittente
senza tenere conto del campo “Reply-To” eventualmente presente nell’intestazione del messaggio.
Tutti i messaggi generati dal sistema di posta certificata sono identificabili per la presenza di un
header specifico. Ai fini della determinazione dei dati di certificazione fanno fede, per il sistema, gli
elementi utilizzati per l’effettivo instradamento del messaggio verso i destinatari. Nelle fasi di
colloquio mediante protocollo SMTP (ad esempio presso i punti di accesso e di ricezione) i dati di
“reverse path” e “forward path” (comandi “MAIL FROM” e “RCPT TO”) sono quindi considerati
come dati di certificazione rispettivamente del mittente e dei destinatari. I dati di indirizzamento
presenti nel corpo del messaggio (campi “To” e “Cc”) sono usati esclusivamente per discriminare
tra destinatari primari del messaggio e riceventi in copia, qualora necessario; i dati di
indirizzamento presenti nel campo “Ccn” non sono considerati validi dal sistema.
26

3.3. Logging
Durante le fasi di trattamento del messaggio presso i punti di accesso, ricezione e consegna, il
sistema deve mantenere traccia delle operazioni svolte. Tutte le attività sono memorizzate su un
registro riportante i dati significativi dell’operazione:
o
o
o
o
o
o
o
o
il codice identificativo univoco assegnato al messaggio originale (Message-ID)
la data e l’ora dell’evento
il mittente del messaggio originale
i destinatari del messaggio originale
l’oggetto del messaggio originale
il tipo di evento (accettazione, ricezione, consegna, emissione ricevute, errore, ecc.)
il codice identificativo (Message-ID) dei messaggi correlati generati (ricevute, errori, ecc.)
il gestore mittente
Gli effettivi dati registrati sui singoli log dipendono dalla tipologia dell’operazione tracciata
(ricezione di un messaggio, generazione ricevute, ecc.). Deve essere garantita la possibilità di
reperire, a richiesta, le informazioni contenute nei log.
3.4. Punto di accesso
Il punto di accesso consente ad un utente di accedere ai servizi di posta certificata resi disponibili
dal proprio gestore. La possibilità da parte di un utente di accedere ai servizi di PEC deve
prevedere necessariamente l’autenticazione dello stesso da parte al sistema. Alla ricezione di un
messaggio originale, il punto di accesso:
o
o
o
effettua dei controlli formali sul messaggio in ingresso
genera una ricevuta di accettazione
imbusta il messaggio originale in una busta di trasporto.
La ricevuta di accettazione indica al mittente che il suo messaggio è stato accettato dal sistema e
certifica la data e l’ora dell’evento. All’interno della ricevuta è presente un testo leggibile
dall’utente, un allegato XML con i dati di certificazione in formato elaborabile ed eventuali altri
27

allegati per funzionalità aggiuntive offerte dal gestore. Il punto di accesso, utilizzando i dati
dell’indice dei gestori di posta certificata, effettua un controllo per ogni destinatario del messaggio
originale per verificare se appartengono all’infrastruttura di posta certificata o sono utenti esterni
(es. posta Internet). Tale controllo è realizzato verificando l’esistenza (mediante una ricerca “case
insensitive”) dei domini dei destinatari tra gli attributi “managedDomains” presenti all’interno
dell’indice dei gestori. La ricevuta di accettazione (ed i relativi dati di certificazione) riporta quindi
la tipologia dei vari destinatari per informare il mittente del differente flusso seguito dai due
gruppi di messaggi (utenti di posta certificata, utenti esterni). Deve essere garantita l’univocità
dell’identificativo dei messaggi originali accettati nel complesso dell’infrastruttura di posta
certificata per consentire una corretta tracciatura dei messaggi e delle relative ricevute. Il formato
di tale identificativo è del tipo:
[stringa alfanumerica]@[dominio_di_posta_gestore]
oppure:
[stringa alfanumerica]@[FQDN_server_di_posta]
Il messaggio originale e la corrispondente busta di trasporto dovranno quindi contenere il
seguente campo di header:
Message-ID:
Qualora il client di posta elettronica che colloquia con il punto di accesso avesse già inserito un
Message ID all’interno del messaggio originale da inviare, questo dovrà essere sostituito con
l’identificativo sopra descritto. Al fine di consentire al mittente l’associazione tra il messaggio
inviato e le corrispondenti ricevute, l’eventuale Message ID originariamente presente nel
messaggio dovrà essere inserito nel messaggio originale e nelle relative ricevute, avvisi e busta di
trasporto. Se presente, il Message ID originale dovrà essere reso disponibile nell’intestazione del
messaggio mediante l’inserimento del seguente header:
X-Riferimento-Message-ID: [Message-ID originale]
che sarà poi incluso all’interno delle ricevute e della busta di trasporto e riportato nei dati di
certificazione.
28

3.4.1. Controlli formali sui messaggi in ingresso
Al momento dell’accettazione del messaggio il punto di accesso deve garantirne la correttezza
formale verificando che:
o
o
o
o
o
nel corpo del messaggio esista un campo “From” riportante un indirizzo email conforme
alle specifiche RFC 2822
nel corpo del messaggio esista un campo “To” riportante uno o più indirizzi email conformi
alle specifiche RFC 2822
l’indirizzo del mittente del messaggio specificato nei dati di instradamento (reverse path)
coincida con quanto specificato nel campo “From” del messaggio;
gli indirizzi dei destinatari del messaggio specificati nei dati di instradamento (forward
path) coincidano con quelli presenti nei campi “To” o “Cc” del messaggio;
non siano presenti indirizzi dei destinatari del messaggio specificati nel campo “Ccn” del
messaggio.
Qualora il messaggio non superi i controlli, il punto di accesso non dovrà accettare il messaggio
all’interno del sistema di posta certificata emettendo il relativo avviso di non accettazione.
3.4.2. Avviso di non accettazione per eccezioni formali
Qualora il punto di accesso non possa provvedere all’inoltro del messaggio, a causa del mancato
superamento dei controlli formali, viene recapitato al mittente uno specifico avviso di non
accettazione. Per questo avviso di non accettazione gli header contengono i seguenti campi:
X-Ricevuta: non-accettazione
Date: [data di emissione ricevuta]
Subject: AVVISO DI NON ACCETTAZIONE: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [mittente]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio di questa ricevuta è composto da un testo che costituisce la vera e propria
ricevuta in formato leggibile, secondo un modello che riporti i seguenti dati:
29

Errore nell’accettazione del messaggio
Il giorno [data] alle ore [ora] ([zona]) nel messaggio
"[subject]" proveniente da "[mittente]"
ed indirizzato a: [destinatario1] [destinatario2]
è stato rilevato un problema che ne impedisce l’accettazione a causa di
[descrizione errore].
Il messaggio non è stato accettato.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare alla ricevuta per
permetterne una elaborazione automatica. All’interno della ricevuta potranno inoltre essere
presenti ulteriori allegati per specifiche funzionalità fornite dal gestore di posta certificata; in
nessun caso però potrà essere inserito il messaggio originale.
3.4.3. Ricevuta di accettazione
La ricevuta di accettazione è costituita da un messaggio di posta elettronica inviato al mittente e
riportante data ed ora di accettazione, dati del mittente e del destinatario ed oggetto. Negli header della
ricevuta di accettazione sono inseriti i seguenti campi:
X-Ricevuta: accettazione
Date: [effettiva data di accettazione]
Subject: ACCETTAZIONE: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [mittente messaggio originale]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio della ricevuta è composto da un testo che costituisce la vera e propria
ricevuta in formato leggibile, secondo un modello che riporta i seguenti dati:
Ricevuta di accettazione
Il giorno [data] alle ore [ora] ([zona]) il messaggio
"[subject]" proveniente da "[mittente]"
ed indirizzato a:
[destinatario1] (["posta certificata" | "posta ordinaria"])
[destinatario2] (["posta certificata" | "posta ordinaria"])
.
.
.
[destinatarion] (["posta certificata" | "posta ordinaria"])
è stato accettato dal sistema ed inoltrato.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare alla ricevuta per
permetterne una elaborazione automatica. All’interno della ricevuta potranno inoltre essere
presenti ulteriori allegati per specifiche funzionalità fornite dal gestore di posta certificata.
30

3.4.4. Busta di trasporto
La busta di trasporto consiste in un messaggio generato dal punto di accesso e che contiene il
messaggio originale ed i dati di certificazione. La busta di trasporto eredita dal messaggio
originale i seguenti header che dovranno quindi essere riportati immodificati:
o Received
o To
o Cc
o Return-Path
o Message-ID
o X-Riferimento-Message-ID
o X-TipoRicevuta
Dovranno invece essere modificati, od inseriti se necessario, gli header sotto elencati:
X-Trasporto: posta-certificata
Date: [effettiva data di accettazione]
Subject: POSTA CERTIFICATA: [subject originale]
From: "Per conto di: [mittente originale]"
Reply-To: [mittente originale (inserito solo se assente)]
Il corpo della busta di trasporto è composto da un testo che costituisce la parte immediatamente
leggibile dal destinatario del messaggio di posta certificata secondo un modello che riporti i
seguenti dati di certificazione:
Messaggio di posta certificata
Il giorno [data] alle ore [ora] ([zona]) il messaggio
"[subject]" è stato inviato da "[mittente]"
indirizzato a:
[destinatario1]
[destinatario2]
.
.
.
[destinatarion]
Il messaggio originale è incluso in allegato.
Identificativo messaggio: [identificativo]
All’interno della busta di trasporto è inserito in allegato l’intero messaggio originale immodificato
in formato conforme alla RFC 2822 (tranne per quanto detto a proposito del Message ID)
completo di header, corpo ed eventuali allegati. Nella stessa busta di trasporto è inoltre incluso un
allegato XML che specifica in formato elaborabile i dati di certificazione già riportati nel testo ed
informazioni aggiuntive sul tipo di messaggio e tipo di ricevuta richiesta. Alla busta di trasporto
possono inoltre essere allegati ulteriori elementi opzionali per specifiche funzionalità fornite dal
gestore di posta certificata. Anche se il campo “From” della busta di trasporto è modificato per
31

consentire la verifica della firma da parte del destinatario, i dati di instradamento della busta di
trasporto (forward path e reverse path del messaggio) rimangono immutati rispetto agli stessi dati
del messaggio originale.
3.4.5. Avviso di mancata consegna per superamento dei tempi massimi previsti
Qualora il gestore del mittente non abbia ricevuto dal gestore del destinatario, nelle dodici ore
successive all’inoltro del messaggio, la ricevuta di presa in carico o di avvenuta consegna del
messaggio inviato, comunica al mittente che il gestore del destinatario potrebbe non essere in
grado di effettuare la consegna del messaggio. Tale comunicazione è effettuata mediante un
avviso di mancata consegna per superamento dei tempi massimi nel quale gli header contengono i
seguenti campi:
X-Ricevuta: preavviso-errore-consegna
Date: [data di emissione ricevuta]
Subject: AVVISO DI MANCATA CONSEGNA PER SUP. TEMPO MASSIMO: [subject
originale]
From: posta-certificata@[dominio_di_posta]
To: [ricevute gestore mittente]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio del primo avviso di mancata consegna è composto da un testo che
costituisce la vera e propria ricevuta in formato leggibile secondo un modello che riporti i seguenti
dati:
Avviso di mancata consegna
Il giorno [data] alle ore [ora] ([zona]) il messaggio
"[subject]" proveniente da "[mittente]"
e destinato all’utente "[destinatario]"
non e stato consegnato nelle prime dodici ore dal suo invio. Non
escludendo che questo possa avvenire in seguito, si ritiene utile
considerare che l’invio del messaggio potrebbe non andare a buon fine.
Il sistema provvederà comunque ad inviare un ulteriore avviso di
mancata consegna se nelle prossime dodici ore non vi sarà la conferma
della ricezione da parte del destinatario.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare all’avviso per
permetterne una elaborazione automatica. All’interno all’avviso potranno inoltre essere presenti
ulteriori allegati per specifiche funzionalità fornite dal gestore di posta certificata; in nessun caso
però potrà essere inserito il messaggio originale. Qualora, entro ulteriori dodici ore, il gestore del
mittente non abbia ricevuto la ricevuta di avvenuta consegna del messaggio inviato, inoltra al
mittente un ulteriore avviso relativo alla mancata consegna del messaggio entro le 24 e non prima
delle 22 ore successive all’invio. Il corpo del messaggio di questo avviso di mancata consegna è
32

composto da un testo che costituisce la vera e propria ricevuta in formato leggibile secondo un
modello che riporti i seguenti dati:
Avviso di mancata consegna
Il giorno [data] alle ore [ora] ([zona]) il messaggio
"[subject]" proveniente da "[mittente]"
e destinato all’utente "[destinatario]"
non e stato consegnato nelle ventiquattro ore successive al suo invio.
Si ritiene che la spedizione debba considerarsi non andata a buon fine.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare all’avviso per
permetterne una elaborazione automatica. All’interno all’avviso potranno inoltre essere presenti
ulteriori allegati per specifiche funzionalità fornite dal gestore di posta certificata; in nessun caso
però potrà essere inserito il messaggio originale.
3.5. Punto di ricezione
Il punto di ricezione permette lo scambio di messaggi di posta certificata tra diversi gestori di
posta certificata. È inoltre il punto attraverso il quale messaggi di posta elettronica ordinaria
possono essere inseriti nel circuito della posta certificata. Lo scambio di messaggi tra diversi
gestori avviene tramite una transazione basata sul protocollo SMTP come definito dalla RFC 2821.
Eventuali errori verificatisi nel colloquio SMTP possono essere gestiti mediante i meccanismi
standard di notifica degli errori propri del protocollo SMTP come previsto dalle RFC 2821 e RFC
1891. Tale sistema è adottato anche per la gestione di errori transitori in fase di trasmissione
SMTP per i quali risulti un superamento del limite temporale di giacenza. Al fine di garantire al
mittente una segnalazione dell’errore in tempi contenuti, i sistemi che gestiscono il traffico di
posta certificata devono adottare come limite di tempo per la giacenza del messaggio un valore
pari a 8 ore. Il punto di ricezione, a fronte dell’arrivo di un messaggio, effettua la seguente serie
di controlli ed operazioni:
o
o
o
o
verifica la correttezza/natura del messaggio in ingresso;
se il messaggio in ingresso è una busta di trasporto corretta ed integra:
o emette una ricevuta di presa in carico verso il gestore mittente
o inoltra la busta di trasporto verso il punto di consegna
se il messaggio in ingresso è una ricevuta corretta ed integra o un avviso di posta
certificata corretto ed integro:
o inoltra la ricevuta/avviso verso il punto di consegna;
se il messaggio in ingresso non risponde ai requisiti per una busta di trasporto o per una
ricevuta/avviso corretto ed integro, ma risulta proveniente da un gestore di posta
33

o
certificata, quindi supera le verifiche di esistenza, provenienza e validità della firma, il
messaggio deve essere propagato verso il destinatario, quindi:
o imbusta il messaggio in arrivo in una busta di anomalia
o inoltra la busta di anomalia verso il punto di consegna.
se il messaggio in ingresso non proviene da un sistema di posta certificata, quindi non
supera le verifiche di esistenza, provenienza e validità della firma, viene considerato di
posta ordinaria, quindi, se propagato verso il destinatario:
o imbusta il messaggio in arrivo in una busta di anomalia
o inoltra la busta di anomalia verso il punto di consegna.
La ricevuta di presa in carico è emessa dal gestore ricevente il messaggio, nei confronti del
gesture mittente. Il suo fine è quello di consentire il tracciamento del messaggio nel passaggio tra
un gestore ed un altro.
Al ricevimento di un messaggio presso il punto di ricezione, il sistema compie i seguenti
controlli,per verificare che la busta di trasporto/ricevuta/avviso sia corretta/integra:
o
o
o
Controllo dell’esistenza della firma
il sistema verifica la presenza della struttura S/MIME di firma all’interno del messaggio in
ingresso;
Controllo che la firma sia stata emessa da un gestore di posta certificata
il punto di ricezione estrae il certificato usato per la firma del messaggio in ingresso e ne
verifica la presenza all’interno dell’indice dei gestori di posta certificata. Per facilitare il
controllo, è possibile calcolare l’hash SHA1 del certificato estratto ed effettuare la ricerca
“case insensitive” della sua rappresentazione esadecimale all’interno degli attributi
“providerCertificateHash” presenti nell’indice. Questa operazione consente di individuare
agevolmente il gestore mittente per un successivo e necessario controllo della coincidenza
del certificato estratto con quello presente nel record del gestore;
Controllo della validità della firma
è verificata la correttezza della firma S/MIME del messaggio effettuando il ricalcolo degli
algoritmi di firma,la verifica della CRL e la validità temporale del certificato. Nel caso di
utilizzo di meccanismi di replica locale (cache) dei contenuti delle CRL, deve essere
adottato un intervallo di aggiornamento tale da garantire l’attualità del dato, al fine di
minimizzare il possibile ritardo tra pubblicazione della revoca da parte della CA ed il
recepimento di questa variazione da parte del gestore;
34

o
Correttezza formale
il gestore effettua le verifiche sufficienti e necessarie a garantire gli aspetti di correttezza
formale necessari per l’interoperabilità.
Nel caso di messaggi di posta ordinaria in ingresso al sistema di posta certificata, il gestore deve
effettuare un controllo sulla presenza di virus informatici al fine di impedire l’introduzione di
messaggi di posta ordinaria potenzialmente pericolosi, nel circuito della posta certificata. Nel caso
di presenza di virus informatici in un messaggio di posta ordinaria, questo potrà quindi essere
scartato dal punto di ricezione prima dell’ingresso nel circuito della posta certificata, senza quindi
un trattamento particolare dell’errore ma con una gestione conforme alle pratiche comunemente
adottate per i messaggi sulla rete pubblica. Quando in fase di ricezione viene rilevata la presenza
di un virus all’interno di una busta di trasporto, il gestore del destinatario emette un avviso di
rilevazione virus informatico destinato al punto di consegna del gestore mittente. Il gestore
mittente, alla ricezione di un avviso di rilevazione virus informatico dovrà :
1. controllare periodicamente quali tipologie di virus non sono state rilevate dal proprio
sistema antivirus al fine di comprenderne le motivazioni e verificare l’opportunità di
eventuali interventi,
2. inviare gli eventuali avvisi di mancata consegna per virus, destinati al mittente del
messaggio.
3.5.1. Ricevuta di presa in carico
Allo scambio di messaggi di posta certificata corretti tra differenti gestori di posta certificata, il
gestore ricevente emette una ricevuta di presa in carico nei confronti del gestore mittente. Le
ricevute di presa in carico emesse sono relative ai destinatari ai quali è indirizzato il messaggio in
ingresso, così come specificato nei dati di instradamento (forward path e reverse path) della
transazione SMTP. All’interno dei dati di certificazione della singola ricevuta di presa in carico sono
elencati i destinatari a cui la stessa fa riferimento. In generale, a fronte di una busta di trasporto,
ogni gestore destinatario dovrà emettere una o più ricevute di presa in carico per i destinatari di
propria competenza. L’insieme di tali ricevute coprirà, in assenza di errori di trasporto, il
complessivo dei destinatari del messaggio. Gli header di una ricevuta di presa in carico
contengono i seguenti campi:
X-Ricevuta: presa-in-carico
Date: [data di presa in carico]
Subject: PRESA IN CARICO: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [ricevute gestore mittente]
35

X-Riferimento-Message-ID: [Message-ID messaggio originale]
L’indirizzo per l’invio delle ricevute al gestore mittente è ricavato dall’indice dei gestori di posta
certificata durante l’interrogazione necessaria per il controllo del soggetto che ha emesso la firma
nella verifica del messaggio in ingresso. Il corpo del messaggio di una ricevuta di presa in carico è
composto secondo un modello riportante i seguenti dati:
Ricevuta di presa in carico
Il giorno [data] alle ore [ora] ([zona]) il messaggio
"[subject]" proveniente da "[mittente]"
ed indirizzato a:
[destinatario1]
[destinatario2]
.
.
.
[destinatarion]
è stato accettato dal sistema.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare alla ricevuta per
permetterne una elaborazione automatica. All’interno della ricevuta potranno inoltre essere
presenti ulteriori allegati per specifiche funzionalità fornite dal gestore di posta certificata.
3.5.2. Busta di anomalia
Nel caso in cui uno dei test evidenzi un errore nel messaggio in arrivo, oppure venga riconosciuto
come un messaggio di posta ordinaria e il gestore preveda la propagazione verso il destinatario, il
sistema lo inserisce in una busta di anomalia. Prima della consegna, il messaggio pervenuto al
punto di ricezione completo di header, testo ed allegati è inserito in formato conforme alla RFC
2822 come allegato all’interno di un nuovo messaggio che eredita dal messaggio in arrivo i
seguenti header che dovranno quindi essere riportati immodificati:
o
o
o
o
o
Received
To
Cc
Return-Path
Message-ID
36

Dovranno invece essere modificati, od inseriti se necessario, gli header sotto elencati:
X-Trasporto: errore
Date: [data di arrivo del messaggio]
Subject: ANOMALIA MESSAGGIO: [subject originale]
From: "Per conto di: [mittente originale]"
Reply-To: [mittente originale (inserito solo se assente)]
Il corpo della busta di anomalia è composto da un testo che costituisce la parte immediatamente
leggibile dal destinatario del messaggio secondo un modello che riporti i seguenti dati:
Anomalia nel messaggio
Il giorno [data] alle ore [ora] ([zona]) è stato ricevuto
il messaggio "[subject]" proveniente da "[mittente]"
ed indirizzato a:
[destinatario1]
[destinatario2]
.
.
.
[destinatarion]
Tali dati non sono stati certificati per il seguente errore:
[descrizione sintetica errore riscontrato]
Il messaggio originale è incluso in allegato.
Nella busta di anomalia non sono inseriti allegati oltre al messaggio pervenuto al punto di
ricezione (es. dati di certificazione) data l’incertezza sull’effettiva provenienza/correttezza del
messaggio.
Anche se il campo “From” della busta di anomalia è modificato per consentire la verifica della
firma da parte del destinatario, i dati di instradamento della busta di anomalia (forward path e
reverse path del messaggio) rimangono immutati rispetto agli stessi dati del messaggio originale. In
questo modo è garantito sia l’inoltro del messaggio verso i destinatari originari sia il ritorno di
eventuali notifiche di errore sul protocollo SMTP (come da RFC 2821 e RFC 1891) al mittente del
messaggio.
3.5.3. Avvisi relativi alla rilevazione di virus informatici
3.5.3.1. Avviso di non accetazione per virus informatico
Qualora il gestore del mittente riceva messaggi con virus informatici è tenuto a non accettarli,
informando tempestivamente il mittente dell’impossibilità di dar corso alla trasmissione. Il punto
di accesso deve compiere dei controlli sul contenuto del messaggio in ingresso e non accettarlo
37

qualora all’interno di questo o di uno dei suoi eventuali allegati, fosse identificata la presenza di
virus informatici. In questo caso deve essere emesso l’avviso di non accettazione per virus
informatico per dare chiara comunicazione al mittente dei motivi che hanno portato al rifiuto del
messaggio. Per questo avviso di non accettazione gli header contengono i seguenti campi:
X-Ricevuta: non-accettazione
X-VerificaSicurezza: errore
Date: [data di emissione ricevuta]
Subject: AVVISO DI NON ACCETTAZIONE PER VIRUS: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [mittente]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio di questa ricevuta è composto da un testo che costituisce la vera e propria
ricevuta in formato leggibile secondo un modello che riporti i seguenti dati:
Errore nell’accettazione del messaggio per presenza di virus
Il giorno [data] alle ore [ora] ([zona]) nel messaggio
"[subject]" proveniente da "[mittente]"
ed indirizzato a: [destinatario1] [destinatario2]
è stato rilevato un problema di sicurezza [identificativo del tipo di
contenuto rilevato].
Il messaggio non è stato accettato.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare alla ricevuta per
permetterne una elaborazione automatica. All’interno della ricevuta potranno inoltre essere
presenti ulteriori allegati per specifiche funzionalità fornite dal gestore di posta certificata; in
nessun caso però potrà essere inserito il messaggio originale.
3.5.3.2. Avviso di rilevazione virus informatico
Qualora il gestore del destinatario riceva messaggi di posta elettronica certificata con virus
informatici è tenuto a non inoltrarli, informando tempestivamente il gestore del mittente affinché
comunichi al mittente medesimo l’impossibilità di dar corso alla trasmissione. Nel caso nella fase
di ricezione si evidenzi la presenza di virus informatici nel messaggio di posta elettronica
certificata la cui provenienza sia stata accertata dalle verifiche effettuate sulla firma del gestore
mittente, il sistema genera un avviso di rilevazione virus da restituire al gestore mittente
indicando come indirizzo quello specificato per le ricevute nell’Indice dei gestori di posta
certificata, con l’indicazione dell’errore riscontrato. Per questo avviso di rilevazione virus gli
header contengono i seguenti campi:
38

X-Ricevuta: rilevazione-virus
X-Mittente: [mittente messaggio originale]
Date: [data di emissione ricevuta]
Subject: PROBLEMA DI SICUREZZA: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [ricevute gestore mittente]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio di questo avviso è composto da un testo che costituisce la vera e propria
ricevuta in formato leggibile, secondo un modello che riporti i seguenti dati:
Avviso di rilevazione virus informatico
Il giorno [data] alle ore [ora] ([zona]) nel messaggio
"[subject]" proveniente da "[mittente]"
e destinato all’utente "[destinatario]"
è stato rilevato un problema di sicurezza [identificativo del tipo di
contenuto rilevato].
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare all’avviso, per
permetterne un’elaborazione automatica. All’interno all’avviso potranno inoltre essere presenti
ulteriori allegati per specifiche funzionalità fornite dal gestore di posta certificata; in nessun caso
però potrà essere inserito il messaggio originale. Nel corpo del messaggio deve essere specificato
il motivo per il quale è stato impossibile dar corso alla trasmissione.
3.5.3.3. Avviso di mancata consegna per virus informatico
All’arrivo di un avviso di rilevazione di virus informatico proveniente dal gestore destinatario, il
gestore del mittente emette un avviso di mancata consegna da restituire al mittente. Per questo
avviso di mancata consegna gli header contengono i seguenti campi:
X-Ricevuta: errore-consegna
X-VerificaSicurezza: errore
Date: [data di emissione ricevuta]
Subject: AVVISO DI MANCATA CONSEGNA PER VIRUS: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [mittente originale]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio di questo avviso di mancata consegna è composto da un testo che
costituisce la vera e propria ricevuta in formato leggibile, secondo un modello che riporti i
seguenti dati:
39

Avviso di mancata consegna per virus
Il giorno [data] alle ore [ora] ([zona]) nel messaggio
"[subject]" destinato all’utente "[destinatario]"
è stato rilevato un problema di sicurezza [identificativo del tipo di
contenuto rilevato].
Il messaggio non è stato consegnato.
Identificativo messaggio: [identificativo]
Tutte le informazioni necessarie per la costruzione di questo avviso derivano da quanto contenuto
nel correlato avviso di rilevazione virus. Gli stessi dati di certificazione sono inseriti all’interno di
un file XML da allegare all’avviso per permetterne una elaborazione automatica. All’interno
dell’avviso potranno inoltre essere presenti ulteriori allegati per specifiche funzionalità fornite dal
gestore di posta certificata. Nel corpo del messaggio deve essere specificato il motivo per il quale
è stato impossibile dar corso alla trasmissione.
3.5.4. Punto di consegna
3.5.4.1. Verifiche sui messaggi in ingresso
All’arrivo del messaggio presso il punto di consegna, il sistema ne verifica la tipologia e stabilisce
se deve inviare una ricevuta al mittente. La ricevuta di avvenuta consegna è emessa dopo che il
messaggio è stato consegnato nella casella di posta del destinatario ed esclusivamente a fronte
della ricezione di una busta di trasporto valida, identificabile dalla presenza dell’header:
X-Trasporto: posta-certificata
In tutti gli altri casi (es. buste di anomalia, ricevute), la ricevuta di avvenuta consegna non è
emessa. In ogni caso, il messaggio ricevuto dal punto di consegna deve essere consegnato
immodificato alla casella di posta del destinatario. La ricevuta di avvenuta consegna indica al
mittente che il suo messaggio è stato effettivamente consegnato al destinatario specificato e
certifica la data e l’ora dell’evento tramite un testo leggibile dall’utente ed un allegato XML con i
dati di certificazione, oltre ad eventuali allegati per funzionalità aggiuntive offerte dal gestore. Se
il messaggio pervenuto al punto di consegna non fosse recapitabile alla casella di destinazione, il
punto di consegna emette un avviso di mancata consegna. L’avviso di mancata consegna è
generato, a fronte di un errore, relativo alla consegna di una busta di trasporto corretta.
3.5.4.2. Ricevute di avvenuta consegna
3.5.4.2.1. Ricevuta completa di avvenuta consegna
Le ricevute di avvenuta consegna sono costituite da un messaggio di posta elettronica inviato al
mittente che riporta la data e l’ora di avvenuta consegna, i dati del mittente e del destinatario e
40

l’oggetto. Negli header delle ricevute di avvenuta consegna sono inseriti i seguenti campi:
X-Ricevuta: avvenuta-consegna
Date: [data di consegna]
Subject: CONSEGNA: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [mittente messaggio originale]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio di ricevuta è composto da un testo che costituisce la vera e propria
ricevuta in formato leggibile, secondo un modello che riporti i seguenti dati di certificazione:
Ricevuta di avvenuta consegna
Il giorno [data] alle ore [ora] ([zona]) il messaggio
"[subject]" proveniente da "[mittente]"
ed indirizzato a "[destinatario]"
è stato consegnato nella casella di destinazione.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare alla ricevuta.
All’interno della ricevuta potranno inoltre essere presenti ulteriori allegati per specifiche
funzionalità fornite dal gestore di posta certificata. La ricevuta di avvenuta consegna è emessa per
ognuno dei destinatari a cui è consegnato il messaggio. Nel rilascio delle ricevute di avvenuta
consegna, il sistema distingue tra i messaggi consegnati ai destinatari primari ed i riceventi in
copia. Tale verifica è effettuata mediante l’analisi dei campi “To” (destinatari primari) e “Cc”
(riceventi in copia) del messaggio rispetto al destinatario oggetto della consegna. Esclusivamente
per le consegne relative ai destinatari primari, all’interno della ricevuta di avvenuta consegna,
oltre agli allegati descritti, è inserito il messaggio originale completo (header, testo ed eventuali
allegati). Il sistema deve adottare una logica cautelativa nella valutazione della tipologia
destinatario (primario o ricevente in copia) e nella conseguente decisione di non inserire il
messaggio originale nella ricevuta di avvenuta consegna. Qualora il sistema che effettua la
consegna non potesse determinare con certezza la natura del destinatario (primario od in copia)
per problemi di ambiguità dei campi “To” e “Cc”, la consegna dovrà essere considerata come
indirizzata ad un destinatario primario ed includere il messaggio originale completo.
3.5.4.2.2. Ricevuta di avvenuta consegna breve
Al fine di consentire uno snellimento dei flussi, è possibile, per il mittente, richiedere la ricevuta di
avvenuta consegna in formato breve. La ricevuta di avvenuta consegna breve inserisce al suo
interno il messaggio originale, sostituendone gli allegati con i relativi hash crittografici per ridurre
le dimensioni della ricevuta. Per permettere la verifica dei contenuti trasmessi è indispensabile che
41

il mittente conservi gli originali immodificati degli allegati inseriti nel messaggio originale, a cui gli
hash fanno riferimento. Se all’interno della busta di trasporto è presente l’intestazione:
X-TipoRicevuta: breve
il punto di consegna emette, per i destinatari primari, una ricevuta di avvenuta consegna breve.
L’assenza di tale intestazione o un valore diverso da ‘breve’ o ‘sintetica’ comportano l’elaborazione
della ricevuta di avvenuta consegna secondo le modalità della ricevuta di avvenuta consegna
completa. Il valore dell’intestazione nella busta di trasporto deriva dal messaggio originale
permettendo così al mittente di stabilire il formato delle ricevute di avvenuta consegna relative ai
destinatari primari del messaggio originale. Per i destinatari riceventi in copia, le ricevute di
avvenuta consegna seguono le modalità della ricevuta di avvenuta consegna completa. Negli
header delle ricevute brevi di avvenuta consegna sono inseriti i seguenti campi:
X-Ricevuta: avvenuta-consegna
Date: [data di consegna]
Subject: CONSEGNA: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [mittente messaggio originale]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio di ricevuta è composto da un testo che costituisce la vera e propria
ricevuta in formato leggibile, secondo un modello che riporti i seguenti dati di certificazione:
Ricevuta breve di avvenuta consegna
Il giorno [data] alle ore [ora] ([zona]) il messaggio
"[subject]" proveniente da "[mittente]"
ed indirizzato a "[destinatario]"
è stato consegnato nella casella di destinazione.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare alla ricevuta.
All’interno della ricevuta potranno inoltre essere presenti ulteriori allegati per specifiche
funzionalità fornite dal gestore di posta certificata. La ricevuta di avvenuta consegna è emessa per
ognuno dei destinatari a cui è consegnato il messaggio. Alla ricevuta breve di avvenuta consegna
è allegato il messaggio originale nel quale rimane inalterata la struttura MIME, ma i cui allegati
sono sostituiti da altrettanti file di testo contenenti gli hash del file al quale si vanno a sostituire.
Gli allegati sono identificati dalla presenza del parametro “name” nell’intestazione “content-type”
oppure “filename” nell’intestazione “content-disposition” della parte MIME. Nel caso di messaggi
originali in formato S/MIME è necessario non alterare l’integrità della struttura del messaggio
modificando le parti MIME proprie della costruzione S/MIME. La verifica della natura S/MIME del
42

messaggio originale avviene controllando il MIME type dell’entità di livello più alto (coincidente con
il messaggio stesso). Un messaggio S/MIME può avere i seguenti MIME type (come da RFC 2633):
o
o
multipart/signed
Il MIME type rappresenta un messaggio originale firmato dal mittente secondo la struttura
descritta dalla RFC 1847. Il messaggio è formato da due parti MIME: la prima che
costituisce il messaggio composto dal mittente prima della sua firma e la seconda che
contiene i dati di firma. La seconda parte (generalmente di tipo “application/pkcs7-
signature” oppure “application/x-pkcs7-signature”) contiene i dati aggiunti durante la fase
di firma del messaggio e deve essere lasciata inalterata per non compromettere la
struttura complessiva del messaggio;
application/pkcs7-mime oppure application/x-pkcs7-mime
Questi MIME type sono generalmente associati a messaggi crittografati, anche se in alcune
particolari implementazioni possono rappresentare messaggi firmati od altri oggetti
crittografici. Il messaggio è composto da un unico oggetto CMS contenuto all’interno della
parte MIME. Data l’impossibilità di distinguere gli allegati eventualmente presenti all’interno
dell’oggetto CMS, la parte MIME viene lasciata intatta senza essere sostituita dal relativo
hash, di fatto determinando l’emissione di una ricevuta di avvenuta consegna breve con gli
stessi contenuti di una normale ricevuta di avvenuta consegna.
L’individuazione delle parti da non sottoporre alla sostituzione con i corrispondenti hash deve
basarsi sul MIME type del messaggio (entità MIME di livello più alto) e sull’eventuale sottostruttura
MIME interna. I MIME type delle parti di livello inferiore così come i nomi dei file delle parti stesse
non devono essere usati come elementi discriminanti per evitare ambiguità con allegati utente
aventi stessi tipi od estensioni. Nel caso il messaggio originale contenga allegati il cui Content-
Type risulti "message/rfc822", ossia contenga un messaggio di posta come allegato, l'intero
messaggio allegato viene sostituito con il relativo hash. In generale, nel caso di messaggi originali
in formato S/MIME, la copia del messaggio contenuta all’interno della ricevuta di avvenuta
consegna breve avrà le seguenti caratteristiche:
o se il messaggio originale è firmato, la struttura S/MIME ed i relativi dati di firma resteranno
inalterati. Il messaggio genererà un errore in un’eventuale fase di verifica dell’integrità
della firma, in seguito alla sostituzione degli allegati con i relativi hash;
o se nel messaggio originale è presente il MIME Type :application/pkcs7-mime oppure
application/x-pkcs7-mime : gli allegati contenuti nel messaggio non saranno sostituiti dagli
43

hash data l’impossibilità di identificarli all’interno del blocco crittografico. Il contenuto della
ricevuta di avvenuta consegna breve coinciderà quindi con quello di una normale ricevuta
di avvenuta consegna.
L’algoritmo utilizzato per il calcolo dell’hash è il Secure Hash Algorithm 1 (SHA1), così come
descritto dalla RFC 3174 calcolato sull’intero contenuto dell’allegato. Per consentire di distinguere i
file contenenti gli hash dai file a cui fanno riferimento, il suffisso “.hash” è aggiunto al termine del
nome originale del file. L’hash è scritto all’interno del file con rappresentazione esadecimale come
un’unica sequenza di 40 caratteri. Il MIME type di questi allegati è impostato a “text/plain” per
evidenziare la loro natura testuale.
3.5.4.2.3. Ricevuta sintetica di avvenuta consegna
Se all’interno della busta di trasporto è presente l’intestazione:
X-TipoRicevuta: sintetica
il punto di consegna emette, sia per i destinatari primari sia per i riceventi in copia, una ricevuta
di avvenuta consegna sintetica. Negli header delle ricevute sintetiche di avvenuta consegna sono
inseriti i seguenti campi:
X-Ricevuta: avvenuta-consegna
Date: [data di consegna]
Subject: CONSEGNA: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [mittente messaggio originale]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio di ricevuta è composto da un testo che costituisce la vera e propria
ricevuta in formato leggibile, secondo un modello che riporti i seguenti dati di certificazione:
Ricevuta sintetica di avvenuta consegna
Il giorno [data] alle ore [ora] ([zona]) il messaggio
"[subject]" proveniente da "[mittente]"
ed indirizzato a "[destinatario]"
è stato consegnato nella casella di destinazione.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare alla ricevuta.
All’interno della ricevuta potranno inoltre essere presenti ulteriori allegati per specifiche
funzionalità fornite dal gestore di posta certificata. La ricevuta di avvenuta consegna è emessa per
ognuno dei destinatari a cui è consegnato il messaggio. Il valore dell’intestazione nella busta di
trasporto deriva dal messaggio originale permettendo così al mittente di stabilire il formato delle
44

icevute di avvenuta consegna relative ai destinatari primari del messaggio originale. La ricevuta
sintetica di avvenuta consegna segue le medesime regole di emissione della ricevuta di avventa
consegna; in allegato non contiene il messaggio originale ma contiene esclusivamente il file XML
contenente i dati di certificazione descritti nella ricevuta di avvenuta consegna.
3.5.4.3. Avviso di mancata consegna
Nel caso si verifichi un errore nella fase di consegna del messaggio, il sistema genera un avviso di
mancata consegna da restituire al mittente con l’indicazione dell’errore riscontrato. Per un avviso
di mancata consegna gli header contengono i seguenti campi:
X-Ricevuta: errore-consegna
Date: [data di emissione ricevuta]
Subject: AVVISO DI MANCATA CONSEGNA: [subject originale]
From: posta-certificata@[dominio_di_posta]
To: [mittente messaggio originale]
X-Riferimento-Message-ID: [Message-ID messaggio originale]
Il corpo del messaggio di un avviso di mancata consegna è composto da un testo che costituisce
la vera e propria ricevuta in formato leggibile secondo un modello che riporti i seguenti dati:
Avviso di mancata consegna
Il giorno [data] alle ore [ora] ([zona]) nel messaggio
"[subject]" proveniente da "[mittente]"
e destinato all’utente "[destinatario]"
è stato rilevato un errore [errore sintetico].
Il messaggio è stato rifiutato dal sistema.
Identificativo messaggio: [identificativo]
Gli stessi dati di certificazione sono inseriti all’interno di un file XML da allegare all’avviso per
permetterne un’elaborazione automatica. All’interno dell’avviso potranno inoltre essere presenti
ulteriori allegati per specifiche funzionalità fornite dal gestore di posta certificata.
3.6. Formati
3.6.1. Riferimenti temporali
Per tutte le operazioni effettuate durante i processi di elaborazione dei messaggi, ricevute, log,
ecc. svolte dai punti di accesso/ricezione/consegna è necessario disporre di un accurato
riferimento temporale. Tutti gli eventi (generazione di ricevute, buste di trasporto, log, ecc.) che
45

costituiscono la transazione di elaborazione del messaggio presso i punti di accesso, ricezione e
consegna devono impiegare un unico valore temporale rilevato all’interno della transazione stessa.
In questo modo l’indicazione dell’istante di elaborazione del messaggio è univoca all’interno dei
log, delle ricevute, dei messaggi, ecc. generati dal server.
3.6.2. Formato data/ora utente
Le indicazioni temporali fornite dal servizio in formato leggibile dall’utente (testo delle ricevute,
buste di trasporto, ecc.) sono fornite con riferimento all’ora legale vigente al momento indicato
per l’operazione. Per la data il formato impiegato è “gg/mm/aaaa” mentre per l’indicazione oraria
si utilizza “hh:mm:ss”, dove hh è in formato 24 ore. Al dato temporale è fatta seguire tra
parentesi la “zona” ossia la differenza (in ore e minuti) tra l’ora legale locale ed UTC. La
rappresentazione di tale valore è in formato “[+|-]hhmm”, dove il primo carattere indica una
differenza positiva o negativa.
3.7. Specifiche degli allegati
Di seguito sono riportati i dati caratteristici delle varie componenti di messaggi e ricevute generati
dal sistema di posta certificata. Nel caso in cui una delle parti del messaggio contenesse caratteri
con valori al di fuori dell’intervallo 0÷127 (7-bit ASCII) la parte dovrà essere adeguatamente
codificata in maniera tale da garantire che il messaggio finale sia compatibile con il trasporto a 7
bit previsto (es. quoted-printable, base64).
3.7.1. Corpo del messaggio
Set di caratteri: ISO-8859-1 (Latin-1)
MIME type: text/plain oppure multipart/alternative
Il MIME type multipart/alternative può essere utilizzato per aggiungere una versione in formato
HTML del corpo dei messaggi generati dal sistema. In questo caso dovranno essere presenti due
sotto-parti MIME: una di tipo text/plain ed un’altra text/html. La parte in formato HTML deve
rispettare i seguenti vincoli:
o deve contenere le stesse informazioni riportate nella parte di testo;
o non deve contenere riferimenti ad elementi (es. immagini, suoni, font, style sheet) né
interni al messaggio (parti MIME aggiuntive) né esterni (es. ospitati su server del gestore);
o non deve avere contenuto attivo (es. Javascript, VBscript, Plug-in, ActiveX).
46

3.7.2. Messaggio originale
MIME type: message/rfc822
Nome allegato: postacert.eml
3.7.3. Dati di certificazione
Set di caratteri: UTF-8
MIME type: application/xml
Nome allegato: daticert.xml
3.8. Schema dei dati di certificazione
Di seguito viene proposto il DTD relativo al file XML che conterrà i dati di certificazione da allegare
nelle ricevute.
47

48

3.9. Schema indice dei gestori di PEC
L’indice dei gestori di posta certificata è realizzato mediante un server LDAP (Lightweight
Directory Access Protocol, un protocollo standard per l'interrogazione e la modifica dei servizi di
directory) centralizzato che contiene i dati dei gestori e dei relativi domini di posta certificata. La
“base root” dell’indice è “o=postacert” ed i “DistinguishedName” dei singoli record sono del tipo
“providerName=,o=postacert”. La ricerca all’interno dell’indice avviene principalmente in
modalità “case insensitive” usando gli attributi “providerCertificateHash” (in fase di verifica della
firma delle buste) o “managedDomains” (in fase di accettazione del messaggio). All’interno del
record di un singolo gestore è possibile la presenza di più attributi “providerCertificate” e dei
relativi “providerCertificateHash” per consentire la gestione dei rinnovi dei certificati in scadenza.
Il gestore deve provvedere, con un sufficiente anticipo rispetto alla scadenza del certificato, ad
aggiornare il proprio record aggiungendo un nuovo certificato la cui validità può sovrapporsi con il
certificato precedente. I precedenti certificati scaduti non devono essere rimossi dall’indice per
consentire la verifica della firma dei messaggi in tempi successivi. L’attributo “LDIFLocationURL”
deve puntare ad un oggetto HTTPS, messo a disposizione dal gestore, che contiene un file in
formato LDIF secondo RFC 2849. Per garantirne l’autenticità, tale file dovrà essere firmato dal
gestore per le operazioni proprie del servizio di posta certificata. Il file LDIF, la firma ed il
certificato X.509v3, devono essere inseriti in una struttura PKCS#7 in formato binario ASN.1 DER
come file con estensione “.p7m”. Con cadenza giornaliera, il sistema LDAP centralizzato scarica
tale file e, dopo le opportune verifiche sulla firma apposta, lo applica sul record relativo al gestore.
Il file LDIF che comprende i dati di tutti i gestori di posta certificata è disponibile, firmato con il
metodo descritto per i singoli gestori, come oggetto HTTPS alla URL puntata dall’attributo
“LDIFLocationURL” del record “dn: o=postacert”. Mediante tale LDIF I singoli gestori dovranno
49

eplicare localmente, con cadenza giornaliera, il contenuto dell’indice al fine di migliorare i tempi
di risposta del sistema evitando di effettuare richieste al sistema centrale per ogni fase di
elaborazione del messaggio.
È possibile, per il gestore, definire più record distinti per indicare diversi ambienti operativi
secondari amministrati. Ogni record fa riferimento al singolo ambiente operativo secondario per il
quale è possibile dichiarare specifici attributi, eventualmente distinti da quelli relativi agli altri
ambienti e all’ambiente principale. Tutti i record devono riportare nell’attributo “providerName” il
nome del gestore, mentre l’attributo “providerUnit” è usato per identificare gli ambienti operativi
secondari. I “DistinguishedName” dei record relativi agli ambienti operativi secondari sono del tipo
“providerUnit=,providerName=,o=postacert”. Ogni gestore deve avere un
record associato al proprio ambiente operativo principale distinguibile per l’assenza dell’attributo
“providerUnit” all’interno del record e del DistinguishedName. I record per gli ambienti secondari
non devono riportare l’attributo “LDIFLocationURL” che è ricavato, per tutti i record connessi al
gestore, dagli attributi dell’ambiente principale. Nel caso di presenza di ambienti secondari, il file
LDIF indicato nel record dell’ambiente principale deve riportare il contenuto di tutti i record di
pertinenza del gestore. Di seguito sono riportati gli attributi definiti per lo schema dell’indice dei
gestori di posta certificata:
Figura 3-1 Attributi dello schema indice dei gestori di PEC
50

Quello che segue è lo schema LDAP per l’indice dei gestori di posta certificata secondo la sintassi
descritta nella RFC 2252:
attributetype ( 16572.2.2.1
NAME 'providerCertificateHash'
DESC 'Hash SHA1 del certificato X.509 in formato esadecimale'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{40} )
attributetype ( 16572.2.2.2
NAME 'providerCertificate'
DESC 'Certificato X.509 in formato binario ASN.1 DER'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
attributetype ( 16572.2.2.3
NAME 'providerName'
DESC 'Nome del gestore di posta certificata'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}
SINGLE-VALUE )
attributetype ( 16572.2.2.4
NAME 'mailReceipt'
DESC 'E-mail a cui inviare le ricevute di presa in carico'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
SINGLE-VALUE )
attributetype ( 16572.2.2.5
NAME 'managedDomains'
DESC 'Domini gestiti dal gestore di posta certificata'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 16572.2.2.6
NAME 'LDIFLocationURL'
DESC 'URL (HTTP) del file LDIF che definisce la entry'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
attributetype ( 16572.2.2.7
NAME 'providerUnit'
DESC 'Nome dell’ambiente operativo secondario'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}
SINGLE-VALUE )
objectclass ( 16572.2.1.1
51

NAME 'LDIFLocationURLObject'
DESC 'Classe per inserimento di un attributo LDIFLocationURL'
MAY ( LDIFLocationURL )
SUP top AUXILIARY )
objectclass ( 16572.2.1.2
NAME 'provider'
DESC 'Gestore di posta certificata'
SUP top
MUST ( providerCertificateHash $
providerCertificate $
providerName $
mailReceipt $
managedDomains)
MAY ( description $
LDIFLocationURL $
providerUnit) )
Il seguente file LDIF rappresenta un esempio di indice dei gestori della posta certificata
contenente una “base root” e due gestori fittizi. I certificati inseriti sono due certificati “selfsigned”
riportati a titolo di esempio:
dn: o=postacert
objectclass: top
objectclass: organization
objectClass: LDIFLocationURLObject
o: postacert
LDIFLocationURL: https://igpec.rupa.it/igpec.ldif.p7m
description: Base root per l’indice dei gestori di posta certificata
dn: providerName=Anonima Posta Certificata S.p.A.,o=postacert
objectclass: top
objectclass: provider
providerName: Anonima Posta Certificata S.p.A.
providerCertificateHash: 7E7AEF1059AE0F454F2643A95F69EC3556009239
providerCertificate;binary:: MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQ
QFADBmMQswCQYDVQQGEwJJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZp
Y2F0YSBTLnAuQS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG
9jZXJ0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkGA1UE
BhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdGEgUy5wLkEuMS
wwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBhbnBvY2VydC5pdDCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qKKdxV9LzDMPqwnEy0P8H/KwbI0Szs
8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC2uL09HDyx8agjgZWdhypnehguiSK3busha15
RSpMGhiqxmz2b0HhOG73GfalZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxz
y34XcCAwEAAaOBwzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAG
A1UdIwSBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYTAk
lUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC5BLjEsMCoG
CSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2NlcnQuaXSCAQAwDAYDVR
0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58BZ+q1qSKpuffzTBpMtbeFkDIxMq
Ma+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqAXxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIw
bOunhrvsxh3vsG5CgN76JzZ95Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2Vl
xlQP7McSUw==
mailReceipt: ricevute@anpocert.it
LDIFLocationURL: https://www.anpocert.it/LDIF/anpocert.ldif.p7m
managedDomains: posta.anpocert.it
managedDomains: cert.azienda.it
52

managedDomains: costmec.it
description: Servizi di posta certificata per aziende
dn: providerName=Servizi Postali S.r.l.,o=postacert
objectclass: top
objectclass: provider
providerName: Servizi Postali S.r.l.
providerCertificateHash: e00fdd9d88be0e2cc766b893315caf93d5701a6a
providerCertificate;binary:: MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQ
QFADBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5s
LjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2
F0YUBzZXJwb3N0YWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjA5MTczMjE2WjBu
MQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA
0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YUBz
ZXJwb3N0YWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKoc7n6zA+sO8N
ATMcfJ+U2aoDEsrj/cObG3QAN6Sr+lygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIE
aYZhYRGjhbcuJ9H/ZdtWdXxcwEWN4mwFzlsASogsh5JeqS8db3A1JWkvhO9EUfaCYk
8YMAkXYdCtLD9s9tCYZeTE2ut9AgMBAAGjgcswgcgwHQYDVR0OBBYEFHPw7VJIoIM3
VYhuHaeAwpPF5leMMIGYBgNVHSMEgZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leMoX
KkcDBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5s
LjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2
F0YUBzZXJwb3N0YWwuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB
gQApqeXvmOyEjwhMrXezPAXELMZwv4qqr5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFw
NQMNxYFVJqdWoLh8qExsTLXnsKycPSnHbCfuphrKvXjQvR2da75U4zGSkroiyvJ2s9
TtiCcT3lQtIjmvrFbaSBiyzj+za7foFUCQmxCLtDaA==
mailReceipt: presaincarico@serpostal.it
LDIFLocationURL: https://servizi.serpostal.it/ldif.txt.p7m
managedDomains: servizi-postali.it
managedDomains: postaricevuta.it
description: Servizi di posta certificata per il pubblico
3.10. Aspetti relativi alla sicurezza
Di seguito sono riportate le indicazioni che fanno riferimento agli aspetti della sicurezza del
sistema di posta elettronica certificata.
3.10.1. Firma
La chiave privata e le operazioni di firma devono essere gestite utilizzando un dispositivo
hardware dedicato, in grado di garantirne la sicurezza in conformità a criteri riconosciuti in ambito
europeo o internazionale.
3.10.2. Autenticazione
La possibilità da parte di un utente di accedere ai servizi di PEC, tramite il punto di accesso, deve
prevedere necessariamente l’autenticazione al sistema da parte dell’utente stesso. A titolo
esemplificativo, e non esaustivo, le modalità di autenticazione possono prevedere, ad esempio,
l’utilizzo di user-id e password o, se disponibili e ritenute modalità necessarie per il livello di
53

servizio erogato, la carta d’identità elettronica o la carta nazionale dei servizi. La scelta della
modalità con la quale realizzare l’autenticazione è lasciata al gestore. L’autenticazione è
necessaria per garantire che il messaggio sia inviato da un utente del servizio di posta certificata i
cui dati di identificazione siano congruenti con il mittente specificato, al fine di evitare la
falsificazione di quest’ultimo.
3.10.3. Colloquio sicuro
Al fine di garantire l’inalterabilità del messaggio originale spedito dal mittente si realizza
l’imbustamento e la firma dei messaggi in uscita dal punto di accesso e la successiva verifica in
ingresso al punto di ricezione. Il messaggio originale (completo di header, testo ed eventuali
allegati) è inserito come allegato all’interno di una busta di trasporto. La busta di trasporto
fermata dal gestore mittente permette di verificare che il messaggio originale non sia stato
modificato durante il suo percorso dal dominio mittente al dominio destinatario. La sicurezza del
colloquio tra mittente e destinatario prevede un meccanismo di protezione per tutte le connessioni
previste dall’architettura di posta certificata (tra utente e punto di accesso, tra gestore e gestore,
tra punto di consegna ed utente) attuato tramite l’impiego di canali sicuri. L’integrità e la
confidenzialità delle connessioni tra il gestore di posta certificata e l’utente devono essere
garantite mediante l’uso di protocolli sicuri. A titolo esemplificativo, e non esaustivo, dei protocolli
accettabili per l’accesso figurano quelli basati su TLS (es. IMAPS, POP3S, HTTPS), quelli che
prevedono l’attivazione di un colloquio sicuro durante la comunicazione (es. SMTP STARTTLS,
POP3 STLS), quelli che realizzano un canale di trasporto sicuro sul quale veicolare protocolli non
sicuri (es. IPSec). Il colloquio tra i gestori deve avvenire con l’impiego del protocollo SMTP su
trasporto TLS, come descritto nella RFC 3207. Il punto di ricezione deve prevedere ed annunciare
il supporto per l’estensione STARTTLS ed accettare connessioni sia in chiaro (per la posta
ordinaria) che su canale protetto.
Al fine di garantire la completa tracciabilità nel flusso di messaggi di posta certificata, questi non
devono transitare su sistemi esterni al circuito di posta certificata. Nello scambio di messaggi tra
gestori diversi, tutte le transazioni devono avvenire tra macchine appartenenti al circuito della
posta certificata od a conduzione diretta del gestore. Gli eventuali sistemi secondari di ricezione
dei messaggi per il dominio di posta certificata devono essere sotto il controllo diretto del gestore.
Ogni dominio di posta certificata dovrà essere associato al relativo punto di ricezione mediante un
record di tipo “MX” definito all’interno del sistema di risoluzione dei nomi secondo le
raccomandazioni della RFC 1912.
3.10.4. Virus
54

Un altro aspetto rilevante di sicurezza, che riguarda l’intero sistema di posta elettronica certificata,
è relativo all’architettura tecnico/funzionale che deve impedire che la presenza di virus possa
compromettere la sicurezza di tutti i possibili messaggi gestiti; deve quindi essere prevista
l’istallazione ed il costante aggiornamento di sistemi antivirus che impediscano quanto più
possibile ogni infezione, senza però intervenire sul contenuto della posta certificata in accordo
cona quato già definito.
3.10.5. Indice dei gestori di PEC
Il contenuto dell’indice dei gestori di posta elettronica certificata è interrogabile via HTTP su
protocollo SSL esclusivamente dai gestori accreditati che disporranno di appositi certificati utente;
tale modalità di accesso garantisce l’autenticità, l’integrità e la riservatezza dei dati.
55

3.11. Schema logico di funzionamento
Nel seguito viene proposta la rappresentazione grafica adottata dal CNIPA che schematizza gli
elementi caratteristici di un dominio di posta certificata e le sue interazioni con un altro dominio di
posta, sia certificata che non certificata.
3.11.1. Interazione fra due domini di posta certificata
3.11.1.1. Busta di trasporto corretta e valida con consegna avente esito positivo
Figura 3-2 Busta di trasporto corretta e valida con consegna avente esito positivo
• 1a – l’utente invia una e-mail al Punto di accesso (PdA)
• 1b – il PdA restituisce al mittente una Ricevuta di Accettazione (RdA)
• 2a – il PdA crea una Busta di Trasporto (BdT) e la inoltra al Punto di Ricezione (PdR) del
Gestore destinatario
• 2b – il PdR verifica la BdT e crea una Ricevuta di Presa in Carico (RdPiC) che viene
inoltrata al PdR del Gestore mittente
56

• 2c – il PdR verifica la validità della RdPiC e la inoltra al PdC
• 2d – il PdC salva la RdPiC nello store delle ricevute del Gestore
• 3 – il PdR inoltra la BdT al Punto di Consegna (PdC)
• 4a – il PdC verifica il contenuto della BdT ma non riesce a salvarla nello store (es.
mailbox del destinatario piena)
• 4b – il PdC crea un Avviso di Mancata Consegna (AMC) e la inoltra al PdR del Gestore
mittente
• 4c – il PdR verifica la validità dello AMC e lo inoltra al PdC
• 4d – il PdC salva lo AMC nella mailbox del mittente
3.11.1.2. Busta di trasporto corretta contenente virus informatico non rilevato dal gestore
mittente e consegna avente errore di consegna
Figura 3-3 Busta di trasporto corretta contenente virus informatico non rilevato dal gestore mittente e
consegna avente errore di consegna
• 1a – l’utente invia una e-mail al Punto di accesso (PdA)
• 1b – il PdA restituisce al mittente una Ricevuta di Accettazione (RdA)
• 2a – il PdA crea una Busta di Trasporto (BdT) e la inoltra al Punto di Ricezione (PdR) del
Gestore destinatario
57

• 2b – il PdR verifica la BdT e crea una Ricevuta di Presa in Carico (RdPiC) che viene
inoltrata al PdR del Gestore mittente
• 2c – il PdR verifica la validità della RdPiC e la inoltra al PdC
• 2d – il PdC salva la RdPiC nello store delle ricevute del Gestore
• 3 – il PdR verifica il contenuto della BdT, ne rileva un contenuto potenzialmente
pericoloso e non la recapita al destinatario ma la conserva
• 4b – il PdR crea una Avviso di Mancata Consegna per Virus e la inoltra al PdR del Gestore
mittente
• 4c – il PdR verifica la validità della RdAC e la inoltra al PdC
• 4d – il PdC salva l’Avviso di Mancata Consegna per Virus nello store delle ricevute del
Gestore
• 5 – il PdC crea una Ricevuta di Mancata Consegna (RdE) e la inoltra nella mailbox del
mittente
3.11.1.3. Messaggio originale con virus informatico rilevato dal gestore mittente e avviso di
non accettazione
Figura 3-4 Messaggio originale con virus informatico rilevato dal gestore mittente e avviso di non
accettazione
58

• 1a – l’utente invia una e-mail al Punto di accesso (PdA)
• 1b – il PdA rileva un contenuto potenzialmente pericoloso e restituisce al mittente una
Avviso di non accettazione (ANA)
• 2 – il PdA non recapita al destinatario il messaggio ma lo conserva
3.11.2. Interazione fra un dominio di posta convenzionale (mittente) ed un dominio di posta
certificata (ricevente)
Figura 3-5 Interazione fra un dominio di posta convenzionale (mittente) ed un dominio di posta
certificata (ricevente)
L’immissione di un messaggio di posta ordinaria nel circuito di trattamento della posta certificata è
a discrezione del gestore destinatario; i criteri adottati per gestire la posta ordinaria devono
essere noti e condivisi dall’utente finale del servizio. La mail non PEC viene inserita in una busta di
trasporto e consegnata al destinatario.
59

3.11.3. Interazione fra un dominio di posta certificata (mittente) ed un dominio di posta
convenzionale (ricevente)
Figura 3-6 Interazione fra un dominio di posta certificata (mittente) ed un dominio di posta
convenzionale(ricevente)
La mail viene impacchettata nella BDT ed emessa dal circuito PEC. Il dominio ricevente la tratta
come una comune mail, consegnandola imbustata al destinatario.
60

4. Sviluppo e test di un'infrastruttura di supporto per la PEC
4.1. Introduzione al lavoro svolto
Il progetto PEC non ha richiesto la fase di identificazione e definizione dei requisiti della soluzione,
in quanto le sue specifiche tecnico funzionali sono state rese note in forma ufficiale e definitiva da
parte del Cnipa a nov 2005. Il gruppo di progetto ha comunque iniziato l’attività di sviluppo della
soluzione basandosi su specifiche dettate dal Legislatore e definite in un periodo transitorio che si
è concluso a Dicembre 2005. I rischi di progetto sono stati mitigati dalla consapevolezza che il
Legislatore avrebbe comunque utilizzato l’esperienza maturata nel periodo transitorio come base
per la definizione delle specifiche tecniche definitive. Questo ha consentito di arrivare preparati al
momento della pubblicazione della legge in Gazzetta Ufficiale. Nello specifico il mio compito
nell’ambito del progetto è consistito di :
o
o
o
Realizzare un laboratorio di macchine per implementare l’infrastruttura PEC allo scopo di
o Verificarne il funzionamento con diverse configurazioni di software e soluzioni
infrastrutturali
o Analizzare e ottimizzare la procedura di installazione delle componenti sofware di
PEC
o Effettuare il testing della soluzione secondo determinati casi d’uso e utilizzando
differenti versioni del software coinvolto
Analizzare, estendere ed aggiornare la documentazione descrittiva del progetto.
Scrivere la documentazione relativa alla procedura di installazione e ai requisiti software
per l’adozione della soluzione.
4.2. Descrizione preliminare del lavoro
La fase iniziale dello stage è stata dedicata all’ acquisizione delle competenze che mi avrebbero
successivamente permesso di entrare nel merito dell’infrastruttura adottata per il laboratorio PEC.
Sotto la guida del tutor aziendale, attraverso la lettura di documentazione e manualistica interna,
mi sono formato sui seguenti temi :
o Infrastruttura di rete e domini Windows Server 2003
o Virtualizzazione e macchine virtuali
o Infrastruttura Microsoft Exchange
61

Successivamente ho iniziato a familiarizzare con le procedure di deployment e configurazione dei
prodotti utilizzati per il laboratorio PEC:
o Virtual Server 2005 R2
o Windows Server 2003
o Microsoft Sql Server 2000
o Microsoft Exchange Server 2003
Il laboratorio è stato realizzato utilizzando il software di virtualizzazione Microsoft Virtual Server
2005 R2. Dopo aver compreso a livello concettuale quello che sarebbe dovuto essere il risultato
del mio lavoro e aver sviluppato una buona familiarità con le procedure di deployment e
configurazione, il lavoro è proceduto per milestones, tenendo presente che a prescindere dalle
differenti versioni di software Microsoft e componenti custom PEC le versioni del laboratorio da
implementare sarebbero dovute essere 2: una ad altà disponibilità, con il backend ( ovvero il
server che basilarmente si occupa dello storage delle mailbox ) ridondato su 2 nodi di un cluster
active/passive di Microsoft Exchange 2003 (4 macchine) e uno a bassa disponibilità (3 macchine),
con un singolo server Exchange di backend. In ambienti di produzione secondo le norme tecniche
della PEC il servizio deve essere attivo 24 ore su 24, 7 giorni su 7, per una disponibilità non
inferiore al 99,8% su base quadrimestrale, con durata massima del singolo fermo inferiore a 2h
52m 48s. Si evince quindi come l’infrastruttura a bassa disponibilità sia stata realizzata solo per
avere una maggiore flessibilità in termini di testing e benchmarking della soluzione: non potrà mai
essere usata in ambienti di produzione. Fondamentalmente gli step che hanno definito il mio
lavoro sono i seguenti:
Effettuare il deployment del laboratorio a 3 / 4 macchine dell’infrastruttura
o Installare e configurare correttamente ognuna delle 3 / 4 macchine in modo da
rendere il laboratorio idoneo all’aggiunta delle componenti custom della PEC :
Macchina 1 : Windows 2003 Server Enterprise NoSP / Sp1 + Sql
Server 2000 Standard Sp4
Macchina 2 : Windows 2003 Server Enterprise NoSP / Sp1 +
Exchange 2003 Enterprise Sp1/Sp2 ( FRONTEND )
Macchina 3 : Windows 2003 Server Enterprise NoSP / Sp1 +
Exchange 2003 Enterprise Sp1/Sp2 ( BACKEND CLUSTER; NODO 1 )
Macchina 4 : Windows 2003 Server Enterprise NoSP / Sp1 +
Exchange 2003 Enterprise Sp1/Sp2 ( BACKEND CLUSTER; NODO 2 )
o Configurare e verificare l’interoperabilità della rete e della rete privata del cluster
62

o Creare, configurare e verificare lo stato dei domini, dei profili degli utilizzatori, delle
policy di dominio
o Configurare correttamente il cluster di Windows 2003 e il cluster di Exchange 2003
o Configurare correttamente l’infrastruttura Exchange, creare le mailbox per i profili di
test e le recipient policy necessarie per la generazione automatica degli indirizzi
smtp predefiniti.
o Configurare correttamente Sql Server 2000
Installare su ogni macchina le componenti custom dedicate alla gestione della PEC
o Effettuare il ripristino e la messa online sulla Macchina 1 del database dedicato alla
conservazione e all’organizzazione delle ricevute di PEC.
o Installare e configurare le componenti custom sul server Exchange di Frontend
o Installare e configurare le componenti custom su entrambi i nodi del server
Exchange di Backend
o Effettuare i test con i casi d’uso previsti.
4.3. Aspetti più significativi della messa in essere dell’infrastruttura
In questo paragrafo mi occupero’ di trattare e descrivere quelli che sono stati gli aspetti più critici
nella realizzazione del laboratorio, a partire dalla scelta della virtualizzazione rispetto
all’allestimento di un laboratorio fisico fino ad arrivare alle procedure necessarie per la verifica del
corretto deployment della macchine, di modo da poter disporre di un ambiente testato sul quale
inserire le componenti software custom.
4.3.1. La virtualizzazione dell’infrastruttura
La virtualizzazione riunisce in sè diverse tecnologie che, in sostanza, servono da supporto per
suddividere le risorse di un unico computer in più parti indipendenti. Tale risultato può essere
ottenuto applicando uno o più metodi quali: partizionamento dell’hardware e del software, time
sharing e simulazione parziale o integrale di una macchina. La ricerca in questo settore è iniziata
negli anni Sessanta e si è concentrata sulle architetture basate su macchine virtuali progettate
come copie identiche dell’hardware della macchina principale. La virtualizzazione può oggi
assumere la forma di un singolo prodotto indipendente, altamente ottimizzato e impiegato con
carichi di lavoro su piccola o su vasta scala. Oppure può essere applicata a ogni livello
dell’infrastruttura It: server, reti e storage. Il tutto porta a una efficienza maggiore attraverso un
utilizzo migliore delle risorse, sia di memorizzazione sia di server, fisicamente disponibili. Un
63

miglior utilizzo si trasforma a sua volta in una riduzione dei costi amministrativi e dei consumi
elettrici. Reso possibile da una nuova generazione di processori, il software di virtualizzazione
offre un’immagine hardware standardizzata sulla quale possono girare sistemi operativi e
applicazioni della medesima versione e con lo stesso tipo di installazione usato con il tradizionale
hardware stand-alone, ma con una notevole riduzione della complessità infrastrutturale. È
altrettanto importante notare come la virtualizzazione introduca flessibilità nell’infrastruttura It,
permettendole di crescere e di contrarsi a seconda della necessità. Così i sistemi divengono
maggiormente reattivi ai cambiamenti delle priorità o ai problemi hardware.
Quando un’azienda dotata di diversi sistemi sperimenta un improvviso picco di traffico proveniente
dai clienti, rispondere con ulteriori risorse può essere problematico. Questa situazione
normalmente non può essere risolta con la semplice aggiunta di un nuovo application server
dedicato. Nelle moderne architetture applicative multilivello è infatti necessario allineare alla
nuova situazione tutti i livelli correlati come Web server front-end, application server e database
server. Con la tecnologia di virtualizzazione è possibile sia installare un nuovo server per
supportare un particolare servizio soggetto a forte domanda da parte dei clienti, sia riassegnare
tale servizio a un server più potente. La commutazione a un server più capace viene effettuata
dinamicamente in tempi estremamente ridotti. Tutti i server possono essere gestiti come se
fossero uno solo, facendo risparmiare risorse con l’ottimizzazione dell’infrastruttura nel suo
complesso. All’interno di un’unica offerta possono essere raggruppati componenti server, storage
e software preconfigurati e certificati, racchiusi in un quadro tecnologico di automazione,
virtualizzazione e deployment, con i relativi servizi. Grazie alle tecnologie di virtualizzazione, si
apre anche una strada verso ambienti Service-Oriented, nei quali computer e database possono
essere dinamicamente allineati alle applicazioni. Soprattutto nel caso dei server virtuali, più
istanze di sistema operativo girano in parallelo sotto forma di server virtuali appoggiati a un
sistema fisico reale. Le dimensioni delle partizioni possono essere modificate online a richiesta;
inoltre, le risorse possono essere nuovamente assegnate tra i diversi server virtuali, senza dover
interrompere il funzionamento del sistema.
4.3.1.1. Microsoft Virtual Server 2005
Il laboratorio è stato allestito sfruttando il software di virtualizzazione di Microsoft, Virtual Server
2005 R2 che consente l’esecuzione della maggior parte dei sistemi operativi a 32 bit, inoltre è
risultato adeguato per l’implementazione del laboratorio di PEC in quanto ha permesso di
virtualizzare l’elevata disponibilità di un cluster, componente dell’infrastruttura PEC. Per le comuni
operazioni di gestione inoltre si avvale di tecnologie standard, come Hypertext Transfer Protocol
(HTTP), RDP (Terminal Services), Extensible Markup Language (XML) e Performance Monitor
64

(PerfMon). Le configurazioni delle macchine virtuali sono memorizzate in file XML, mentre il
monitoraggio e la configurazione dei server vengono effettuati tramite un'interfaccia HTTP/HTML.
VS2005R2 utilizza il multithreading eseguito come servizio di sistema. Ogni macchina virtuale è
eseguita nel proprio thread di elaborazione e l'I/O (input/output) ha luogo nei thread secondari. Esso
sfrutta due funzioni di base del sistema operativo host:
1. Il kernel del sistema operativo host, che provvede alla pianificazione delle risorse CPU
2. I driver di periferica del sistema operativo host, che consentono l'accesso alle periferiche di
sistema.
Virtual Machine Monitor (VMM) mette a disposizione l'infrastruttura software per la creazione delle
macchine virtuali, la gestione delle istanze e l'interazione con i sistemi operativi guest.
Figura 4-1 Architettura di Ms Virtual Server 2005 [1]
65

4.3.1.2. Architettura delle macchine virtuali
Analizzando la figura sottostante dalla parte inferiore della struttura logica troviamo il sistema
operativo host, Windows Server 2003, che gestisce il sistema host. Virtual Server 2005 R2
fornisce il livello di virtualizzazione VMM (Virtual Machine Monitor) per la gestione delle
macchine virtuali, creando l'infrastruttura software necessaria per l'emulazione hardware. Ogni
macchina virtuale è composta da un insieme di periferiche virtualizzate. Infine, il sistema
operativo guest e le relative applicazioni vengono eseguiti nella macchina virtuale e non
rilevano, ad esempio, che la scheda di rete con cui interagiscono tramite Virtual Server 2005
R2 è solo un'emulazione software di un dispositivo Ethernet fisico. Quando viene eseguito un
sistema operativo guest, l'apposito kernel di Virtual Machine Monitor assume il controllo della
CPU e dell'hardware durante il funzionamento della macchina virtuale, dando luogo a un
ambiente isolato.
Sistema operativo
e applicazioni della
macchina virtuale
Hardware
virtuale
Sistema operativo
e applicazioni della
macchina virtuale
Hardware
virtuale
Virtual Server 2005 R2
Windows Server 2003
(32 o 64 bit)
Server x86 o x64
Figura 4-2 Architettura delle machine virtuali [1]
66

4.3.1.3. Architettura delle reti virtuali
Durante l'installazione, il driver del servizio di rete virtuale viene installato nel sistema operativo
host a basso livello, appena al di sopra del driver di rete hardware. Il driver del servizio di rete
virtuale si occupa dell'indirizzamento dei pacchetti di rete, inviandoli al sistema operativo host o a
un sistema operativo guest. Il sistema operativo host è in grado di leggere, monitorare o acquisire
il traffico di rete delle macchine virtuali guest in esecuzione su di esso. Inoltre, le macchine virtuali
configurate solo per la rete esterna non sono in grado di leggere, monitorare o acquisire il traffico
di rete di altre macchine virtuali. Di seguito è illustrata l'architettura delle reti virtuali di Virtual
Server 2005 R2.
Figura 4-3 Architettura delle reti virtuali [1]
Poiché il driver di rete virtuale è installato al di sotto del driver Network Load Balancing nello stack
di rete, il servizio Network Load Balancing non è disponibile con Virtual Server 2005 R2.
67

4.3.1.4. Funzionalità per la gestione e utilizzo di Virtual Server
Le funzionalità descritte nel seguito sono state utilizzate nella creazione e nella gestione del
laboratorio di Posta Elettronica Certificata. Nella pagina Master Status sono riportate le varie
opzioni di gestione, insieme alle macchine virtuali configurate. L'immagine di anteprima Remote
View delle macchine virtuali in esecuzione permette di controllare a colpo d'occhio lo stato del
server. Sul lato opposto è disponibile una rappresentazione grafica dell'utilizzo della CPU.
La pagina include anche una descrizione dello stato delle macchine virtuali, che indica se sono
in esecuzione, arrestate, in corso di arresto o salvate. Infine, nella parte inferiore della pagina un
log riporta gli eventi più recenti, che vengono registrati anche nel registro eventi del sistema host.
Figura 4-4 Interfaccia utente del sito Web per l'amministrazione di Virtual Server:
pagina Master Status.
68

Le funzionalità di gestione possono essere facilmente configurate in base alle specifiche esigenze
di un'organizzazione grazie alla pagina Administration Website Properties. Le preferenze
selezionate modificano le proprietà di visualizzazione della pagina, personalizzandola a seconda
delle esigenze amministrative dell'organizzazione.
Figura 4-5 Interfaccia utente del sito Web per l'amministrazione di Virtual Server:
pagina Administration Website Properties.
69

Le macchine virtuali vengono create tramite un modulo molto semplice, con cui l'amministratore
imposta il sistema operativo virtuale per la macchina. In un sistema convenzionale, molte di
queste impostazioni sono determinate dall'hardware. Le proprietà delle macchine virtuali derivano
da una combinazione di specifiche hardware (come velocità del processore e schede di rete
fisiche) e impostazioni virtuali (come dimensione dei dischi rigidi e allocazione della memoria) ed è
inoltre possibile selezionare il tipo di bus (IDE o SCSI) al momento della creazione delle macchine
virtuali.
Figura 4-6 Interfaccia utente del sito Web per l'amministrazione di Virtual Server:
pagina Create Virtual Machine.
70

Una volta create, le singole macchine virtuali possono essere monitorate e modificate tramite
un'apposita pagina di configurazione, in cui sono visualizzate tutte le informazioni relative alle
prestazioni e alla configurazione. In fase di esecuzione, molte opzioni di modifica della
configurazione sono disattivate per evitare di interferire con il funzionamento della macchina.
Figura 4-7 Interfaccia utente del sito Web per l'amministrazione di Virtual Server:
pagina di configurazione di una macchina virtuale.
71

E’ supportata la definizione di una gerarchia dei dischi, consentendo l'esecuzione di differenti
macchine virtuali che prendono la configurazione di base da uno stesso disco rigido padre. Le
modifiche a una macchina vengono salvate in uno specifico disco, detto disco virtuale
differenziale, accoppiato al disco rigido virtuale padre per consentire il funzionamento della
macchina virtuale. È possibile eseguire contemporaneamente più dischi virtuali differenziali
associati allo stesso disco rigido virtuale padre. Come altre impostazioni, i dischi virtuali
differenziali possono essere configurati attraverso un semplice modulo.
Figura 4-8 Interfaccia utente del sito Web per l'amministrazione di Virtual Server:
pagina di configurazione Differencing Virtual Hard Disk.
72

L'interfaccia per l'impostazione delle rete virtuali consente di creare un numero illimitato di reti
virtuali. Le macchine virtuali possono supportare fino a quattro connessioni a reti virtuali.
Figura 4-9 Interfaccia utente del sito Web per l'amministrazione di Virtual Server:
pagina di configurazione di una rete virtuale.
73

L'accesso alle macchine virtuali avviene tramite il client VMRC, mediante il quale è possibile
accedere alle macchine virtuali da qualsiasi computer su cui è installato. Puo’ essere eseguito in
due modi: 1) come applicazione autonoma (Figura 4-10) oppure 2) in Internet Explorer, tramite
un controllo Active X® del sito Web per l'amministrazione di Virtual Server (Figura 4-11).
Figura 4-10 Client VMRC autonomo.
74

Figura 4-11 VMRC basato su browser.
75

4.3.2. Il laboratorio PEC
Entriamo ora nel vivo del progetto andando ad esaminare le macchine che compongono il
laboratorio e i ruoli che svolgono. Le funzionalità svolte da PDA, PDC, PDR (punto di accettazione,
consegna, ricezione) non sono indipendentemente mappate su corrispondenti macchine
dell’infrastruttura. Per esigenze architetturali e di sviluppo sono state redistribuite in maniera
arbitraria sui vari elementi software custom installati sulle macchine dell’infrastruttura. La scelta di
Internet
F01 EMCSIGN.DLL gestisce e verifica firma messaggi
F02 SMTPSink.DLL gestisce FE ( PDAcc,PDRic )
1 – Domain Controller
2 – Database Log
F03 SMTPSink.ChgMsgID Ribatte il message-id sui PDA
F04 Emcconfig.dll gestisce il file di configurazione di PEC.
AD/GC/SQL
FRONTEND
Exchange 2003
BACKEND
Exchange 2003
Cluster
B01 EMCSIGN.DLL gestisce e verifica firma messaggi
B02 Storage Filter Sync.dll
tipicamente).
gestisce il BE ( PDA, PDR, PDC
B03 ServicesPECBackEndStorageBds.dll
Gestisce emissione BDS
B04 PEC Agent servizio che svolge le funzioni di sincronizzazione
della lista dei gestori (CRL, integrazione IGPEC,...)
Figura 4-12 Visione d’insieme del laboratorio
76

Realizzare il laboratorio nelle 2 configurazioni a bassa e ad altà disponibilità, rispettivamente con 3
e 4 macchine, è stata dettata dal ruolo funzionale che svolgono le macchine all’interno
dell’infrastruttura senza appesantire troppo il carico di lavoro per ciascuna macchina. In linea
teorica il numero minimo di macchine da impiegare è 2, facendo svolgere alla prima macchina i
compiti di domain controller, logging con Sql Server 2000 e di Frontend di Exchange e alla
seconda macchina il ruolo di Backend di Exchange. Tuttavia questa configurazione non
consentirebbe una ripartizione ottimale delle risorse, soprattutto avendo a che fare con
un’infrastruttura virtuale : la macchina host che ha consentito di eseguire il laboratorio, non senza
criticità ed eccesso di carico, dispone di 1024 Megabyte di memoria RAM, di un microprocessore
Pentium IV 3,2 Ghz e di una memoria di massa su interfaccia IDE basata su unità a disco da 60
Gigabyte e 5400 rpm. La quantità di memoria della macchina host dedicabile alle macchine virtuali
attraverso Virtual Server non puo’ essere superiore agli 816 Megabyte, ma il valore massimo
suggerito per non appesantire l’host con file di paging è di 734 Megabyte (questi valori sono forniti
da Virtual Server 2005 R2). L’idea di effettuare benchmarking accurati considerando varie
configurazione di memoria non è stata approfondita in quanto una macchina host con questa
configurazione non sarebbe nemmeno presa in considerazione in ambito produttivo. Al posto di
benchmark accurati si è optato per un’analisi qualitativa delle prestazioni, effettuata valutando i
tempi di avvio delle macchine e i tempi di certificazione di una singola email, che ha consentito di
optare per la seguente configurazione :
o
o
o
o
Macchina 1 ( Dc,Sql ) 192 Megabyte di RAM
Macchina 2 ( Frontend Exchange ) 160 Megabyte di RAM
Macchina 3 ( Nodo 1 Backend Exchange ) 160 Megabyte di RAM
Macchina 4 ( Nodo 2 Backend Exchange ) 160 Megabyte di RAM
Per quanto riguarda la distribuzione del CPU time si è optato per lasciare la quantità ottenibile da
ciascuna macchina al 100%, senza riservarne per alcuna, dal momento che il carico di lavoro è
risultato essere equamente distribuito, anche nell’ottica di valutazione del tempo di downtime del
backend nel caso di failover di uno dei nodi del cluster e trasferimento del servizio sull’altro nodo.
4.3.2.1. Macchina 1 : Domain Controller / logging PEC
La prima macchina dell’infrastruttura svolge il ruolo di domain controller per il dominio
contoso.local e svolge il logging di tutte le operazioni svolte dalla PEC secondo quanto normato
nell’allegato tecnico. Il domain controller si occupa di regolare gli accessi al dominio da parte dei
vari utenti secondo quanto definito all’interno del database di Active Direcory. In questo caso, dal
77

momento che abbiamo un solo DC, esso svolge anche la funzione di Global Catalog, ovvero è il
responsabile delle ricerche di oggetti effettuate sul database Active Directory, cosi’ come
dell’autorizzazione a un account di loggarsi in rete. In Active Direcory sono contenute tutte le
informazioni degli oggetti di sistema, a partire dai diritti degli utenti fino ad arrivare alle
permission del file system. Successivamente all’installazione di un server Exchange avviene
un’estensione del database di Active Directory per poter aggiungere alle caratteristiche specifiche
di un utente tutte le nuove proprietà correlate con l’uso di un sistema di posta elettronica.Il
logging PEC viene eseguito attraverso Microsoft Sql Server 2000. Le componenti custom presenti
sulle altre macchine del laboratorio interagiscono con il database quando è online, attraverso delle
stored procedures e le informazioni sull’indirizzo e le credenziali per l’accesso contenute nei file di
configurazione. Il database di supporto al logging PEC è costituito da tre schemi, il primo (fig. 4-
13), implementato dagli sviluppatori di Milano con i quali si è lavorato, è usato per la gestione, la
memorizzazione e il tracciamento tutti gli eventi che si sono verificati nella gestione della Pec
(PDA, PDR, PDC):
tabLog contiene tutti gli eventi;
tabCfgEntity è il lookup sul tipo di messaggio (MDT, RDA, RDC, RDPIC, ...)
tabCfgReport stabilisce se è stato generato un log
tabCfgLog_Status stabilisce se è stato archiviato su log
Figura 4-13 Diagramma Main del database di PEC
78

Figura 4-14 Diagramma Task del database di PEC
Figura 4-15 Diagramma di tracciamento RDPIC del database di PEC
79

Gli altri schemi (fig. 4-14 e 4-15) sono state aggiunte da EDSPA e a causa della scarsa
documentazione presente sono fornite as-is, senza poter entrare nel merito della gestione interna:
tabTask è usata per le ricevute di mancata consegna e per il calcolo dei tempi.
tabLoopMDT è usata per le RDPIC ( ricevute di presa in carico )
Per accedere a queste tabelle esistono delle stored-procedure Sql.
4.3.2.2. Macchina 2 : Frontend di Exchange
La 2nda macchina dell’infrastruttura è una macchina Windows 2003 con installato Microsoft
Exchange 2003 configurato come frontend. Trattandosi di un frontend i principali servizi correlati
con Exchange sono in esecuzione sulla macchina di backend, in particolar modo la
memorizzazione fisica delle mail e dei dati di posta avviene sulla macchina di backend. Questa
macchina funziona come punto di accesso per svolgere le seguenti funzionalità:
Accesso alle caselle di PEC / posta normale attraverso browser internet, consentendo
l’accesso alla mailbox mediante Outlook Web Access mediante connessione sicura su https.
Esposizione del server smtp autenticato per consentire dal client l’invio di mail verso il
server per destinatari specifici mediante client standalone di posta
Esposizione del server smtp anonimo per consentire il ricircolo interno della mail tra
frontend e backend impacchettandola nella Busta di Trasporto secondo lo schema descritto
nell’allegato tecnico.
Su questa macchina sono installate parte delle componenti software custom per il funzionamento
della PEC :
CAPICOM.DLL
E’ una libreria standard Microsoft che espone le api criptografiche necessarie a EMCSIGN.DLL. La
versione più recente è la 1.0.0.3 ma esendo afflitta da un big per l’infrastruttura in question si è
adoperata la versione 1.0.0.1.
EMCSIGN.DLL
Attualmente scritto in VB6 e di prossima transizione a .Net ( con la release 2.0 del software
custom PEC ), è il componente che si occupa di gestire la firma dei messaggi, firmandoli e
verificandone le firme.
SMTPSINK.DLL
E' il filtro .Net che gestisce il frontend consentendogli di svolgere i ruoli di Punto di Accettazione e
Punto di Ricezione
Filtro di Cambio del Message ID ( su Server SMTP Anonimo )
80

E' il filtro C++ che ribatte il message-id sui Punti di Accettazione. Il message-id è un identificativo
univoco di una mail in relazione al server che la smista : l’univocità del message-id non è un
opzione in quanto se dovesse mancare non si potrebbero riconciliare i log delle mail di PEC. Se la
mail viene inviata mediante un client Smtp il message-id viene assegnato dal client, e non dal
server. Cosi’ per tutelarsi da client non compliant con la RFC sul protocollo SMTP piuttosto che da
virus o comportamenti anomali si ribattezza a priori il message-id per garantirne l'univocità .
SMTPVERIFY.DLL
E' un filtro C++ che aggiunge degli header per evitare il tampering dei msg provenienti da Linux
Filtro VerifySign SMTPVerify.VerifySign
Questo filtro si occupa di verificare che qualsiasi mail introdotta nel circuito PEC attraverso il
server SMTP anonimo sia stata preventivamente firmata con un certificato valido di PEC.
Emcconfig.dll
E' il componente.Net che gestisce il file di configurazione di PEC. Si occupa di ricaricarlo e
verificarne eventuali modifiche a intervalli predefiniti. In caso di modifiche a realtime alla maggior
parte dei paramentri presenti nel file di config occorre comunque un riavvio di sistema.
4.3.2.3. Macchina 3 – 4 : Nodi del cluster di Backend di Exchange
Un cluster a n nodi è una sub-infrastruttura hardware/software costituita da n macchine ognuna
con un sistema operativo cluster-aware che aumenta drasticamente la disponibilità dei servizi
erogati da queste macchine, infatti nel caso in cui un problema hardware o la messa offline di un
nodo su una macchina abbatta la disponibilità del servizio, questo viene spostato su una macchina
operativa. Questo è possibile su infrastruttura Windows 2003 Enterprise attraverso il servizio di
sistema MSCS (Microsoft Clustering Service) che consente la messa in opera di un cluster
active/passive, ovvero, nel caso di un cluster a 2 nodi, un nodo della macchina è attivo mentre
l’altro non lo è, resta in attesa di attivarsi in caso di failover. Nel caso di un cluster active/active
entrambi i nodi sono disponibili raddoppiando l’offerta del servizio, aumentando le prestazioni
globali, ma in caso di failover di uno dei due nodi una sola macchina si farebbe carico dei due
servizi ridondati. Con Exchange 2007 il servizio di clustering active/active non sarà più supportato.
Il server di BACKEND di Exchange è costituito da un cluster active/passive a 2 nodi Windows 2003
Server Enterprise. Ogni nodo del cluster per poter funzionare correttamente deve disporre di 2
81

adattatori di rete, uno pubblico, collegato alla rete dell’infrastruttura condivisa con le altre
macchine, e uno privato, che mette in comunicazione esclusivamente i 2 nodi. Inoltre per un
server Exchange clusterizzato la best practice consiglia l’adozione di 3 adattatori SCSI per ogni
macchina per poter condividere 3 unità a disco necessarie per condividere i dati utilizzati dai
servizi di clustering, dal processo di store di Exchange e dal processo di logging di Exchange.
Figura 4-16 Configurazione hardware di uno dei nodi del cluster
Questa metodologia oltre a garantire buone prestazioni abbassa ulteriormente il rischio di perdita
dati infatti dai logs si puo’ ricostruire lo store e viceversa. Per effettuare il deployment di Exchange
in modalità cluster occorre istanziare manualmente i processi necessari a Exchange manualmente,
82

dopo aver creato un cluster group dedicato. Dopo aver correttamente instanziato il server
Exchange di backend si puo’ procedere all’installazione delle componenti custom della PEC.
Figura 4-17 La console di controllo del cluster e l’elenco delle risorse disponibili
83

4.3.3. Lo sviluppo delle componenti software
L’organizzazione dello sviluppo delle componenti software è proceduto effettuando la
scomposizione delle componenti da un punto di vista architetturale ( distinta base ) e funzionale,
descrivendo i singoli work items in base ai seguenti parametri :
o Attività mandatorie / non mandatorie ( obbligatorie o no )
o Stima del tempo di sviluppo in giorni uomo
o Contingency ( stima del grado di rischio quantificata in giorni uomo )
Figura 4-18 Diagramma della stima dei tempi di progetto
Due distinti gruppi di progetto si sono occupati dello sviluppo software, come è possible notare in
fig. 4-16: da un lato MSFT, ruolo svolto da una società di sviluppo software di Milano come
outsourcer, dall’altro EDS, sita a Roma.
4.3.3.1. Procedura di deploy
Particolarmente critica è risultata essere l’automatizzazione della procedura di installazione delle
componenti software sulle macchine. Si è progressivamente raffinata la procedura batch per
l’installazione, che genera dei warning all’interno di un file di testo della cartella di install in caso di
eccezioni, tuttavia su sistemi con particolari configurazioni di sistema operativo o con livelli di
84

patch differenti è necessario procedere manualmente per avere la certezza di un deployment
effettuato perfettamente. In particolar modo le componenti più critiche da installare sono risultate
essere le seguenti:
o Filtro a livello di systemmailbox di Exchange – si tratta di una regola per la corretta
gestione delle ricevute di presa in carico. Per inserire questa regola occorre utilizzare un
utente definito ad hoc, ExAdmin ( cfr. appendice ) appartenente ai gruppi Domain Admins,
Domain Users, Exchange Domain Server e con particolari permission sulla mailbox di
sistema.
o Installazione e avviamento di alcune componenti COM+. COM+ è uno strumento della MMC
(Microsoft Management Console) che consente l’inserimento di componenti tenuti in
memoria ed eseguiti solo in caso di necessità, ma un livello più alto di quello dei servizi di
sistema.
o Installazione e messa in opera di servizio di PECAGENT, responsabile dell’aggiornamento
della CRL (Certificate Revocation List, la lista che include i certificatori attendibili di PEC).
L’attivazione del servizio prevede la creazione di un utente ad hoc con le permissions
necessarie per l’avvio automatico del servizio.
Il manuale per la procedura di deploy, parte integrante del lavoro svolto, è consultabile al capitolo
7.
4.3.3.2. Testing della soluzione
Effettuato il deployment con successo si è stilato una procedura standard per la verifica di tutte le
funzionalità offerte dalla PEC. La procedura completa prevede i seguenti casi d’uso :
o
o
o
o
o
o
o
o
o
o
o
Invio Normale
Invio a Utente Inesistente
Oggetto mancante
Testo con un solo CR
Testo mancante
Invio a più utenti
Invio a più utenti con utente inesistente in "to"
Invio a più utenti con utente inesistente in "to"
Invio a più utenti con utente inesistente in "cc"
Invio a un utente con ulteriore utente inserito in "ccn"
Invio a più utenti
85

o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
Invio a più utenti con utenti di posta ordinaria
Mail Crittografata
Testo con caratteri speciali
Oggetto con caratteri speciali
Invio ad un utente con casella piena
Messaggio di trasporto con firma del server corrotta
Messaggio con Virus, rilevabile dall'antivirus del gestore mittente
Messaggio con Virus, rilevabile dall'antivirus del gestore destinatario
Messaggio con un solo destinatario ed allegato superiore a 30Mb
Messaggio con 7 destinatari ed allegato da 5Mb
Messaggio con 6 destinatari ed allegato da 4.5Mb
Messaggio con un destinatario non certificato proveniente da un mittente in dominio chiuso
Messaggio con ricevuta di avvenuta consegna Breve
Messaggio Firmato con ricevuta di avvenuta consegna Breve
Messaggio Crittografato con ricevuta di avvenuta consegna Breve
Messaggio Firmato con ricevuta di avvenuta consegna Breve
Messaggio con ricevuta di avvenuta consegna Sintetica
Messaggio con mancata ricezione RDAC entro le 12 ore
Messaggio con mancata ricezione RDAC entro le 24 ore
Messaggio con destinatario definito in sottodominio
Messaggio con oggetto "Force DUMP on FE"
Messaggio con oggetto "Force DUMP on BE PDC"
4.4. Conclusioni e visioni future
La Posta Elettronica Certificata rappresenta uno strumento innovativo e di indubbia utilità: accolto
con entusiasmo dagli addetti ai lavori dell’ IT, saranno gli Italiani a decretarne il successo o meno.
Il paese ha una maturità sufficiente nei confronti delle nuove tecnologie per poter e soprattutto
volere adoperare la PEC al posto della raccomandata tradizionale ? Al momento della scrittura di
questa tesi le notizie non sono entusiasmanti, tanto è che solo una parte degli enti statali e di tutti
gli uffici pubblici che entro il 1 settembre 2006 ( art. 47 del Codice dell'Amministrazione Digitale )
avrebbero dovuto munirsi di indirizzo certificato e pubblicarlo sulle rispettive homepage, per
rendere accessibile a qualunque cittadino, hanno adempiuto a questo compito. Inoltre ricordiamo
che la PEC è un servizio a pagamento, come del resto lo è la controparte cartacea. Considerando
86

comunque che il nostro paese soffre di una lentezza storica nell’adeguarsi ai cambiamenti,
soprattutto entro i termini previsti, questi fatti non destano eccessive preoccupazioni.
Per quanto riguarda i possibili miglioramenti applicabili all’implementazione PEC proposta da
Microsoft abbiamo la riscrittura di tutto il codice di modo da poterlo adeguare al .Net Framework
2.0, operazione in corso al momento della scrittura di questa tesi. Si è inoltre pensato che la
realizzazione di una procedura automatizzata di testing e benchmarking, sebbene non sia di
immediata realizzazione, porterebbe benefici nel tempo. Per l’automazione del testing la scelta
ricadrebbe su WMI (Windows Management Instrumentation ), un linguaggio di scripting
incorporato nei OS Windows per l’automatizzazione di task amministrativi. Il benchmarking puo’
essere effettuato con MMB3 ( MAPI Messaging Benchmark 3 ), prodotto di Microsoft per il
benchmarking dei server di posta e delle infrastrutture basate su Exchange.
87

5. Metodo di progetto
Il metodo di progetto utilizzato abitualmente in Microsoft è Microsoft Solution Framework, una
raccolta di best practice, principi e modelli per la gestione di progetti software. MSF si è evoluto
nel tempo, fino ad arrivare alla versione attuale ( 3.0 ), rilasciata nel corso del 2003 e procede
nel suo sviluppo. Fondamentalmente MSF descrive una serie di sequenze di attività ad alto livello
per effettuare il building e il deployment di soluzioni IT derivate dalle seguenti proven practices
che hanno contribuito direttamente alla formazione e alla formalizzazione di MSF:
Microsoft Worldwide Products Groups
Microsoft Consulting Services
Microsoft Information Technology Groups
Microsoft Partners
Piuttosto che prescrivere una serie di procedure specifiche, MSF è sufficientemente flessibile da
accomodare un ampio range di progetti IT. Esso combina due modelli di progetto standard,
ampiamente adottati a livello industriale, il modello a cascata e il modello a spirale, aggiungendo
una serie di strumenti a supporto del ciclo di vita della soluzione, a partire dalla fase di
avviamento fino ad arrivare alla fase di deployment. MSF è un processo guidato da milestones,
ovvero momenti cronologici del progetto nell’ambito dei quali vengono prodotti deliverable
significativi. Parallelamente MOF 3.0 ( Microsoft Operation Framework ) si occupa di mettere in
uso e mantenere funzionanti le soluzioni IT, attraverso best practices e consolidati modelli per
team e processi che permettono di migliorare l'efficienza e la qualità della gestione IT
(Information Technology). È basato sulle linee guida IT Infrastructure Library versione 2.0 (ITIL),
pubblicate dall'Office of Government Commerce (OGC) del Regno Unito, e le estende attraverso
indicazioni e best practice definite a partire dall'esperienza dei team operativi, dei partner e dei
clienti Microsoft. Le componenti principali di MOF sono il team model, il process model e la
disciplina di risk management. Per meglio comprendere MSF si procederà con la descrizione dei
due metodi di progetto da cui deriva.
5.1. Metodo di progetto a cascata ( Waterfall Model )
Il modello a cascata o ciclo di vita a cascata (waterfall model o waterfall lifecycle in inglese) è un
modello di ciclo di vita del software (ovvero di processo software) secondo cui la realizzazione di
un prodotto software consta di una sequenza di fasi strutturata in analisi dei requisiti, progetto,
88

implementazione, testing (validazione), integrazione e manutenzione. Ciascuna di queste fasi
produce un ben preciso output che viene utilizzato come input per la fase successiva (da cui la
metafora della cascata). Il ciclo di vita a cascata fu il primo modello di ciclo di vita del software. La
sua teorizzazione rappresenta innanzitutto un importante mutamento di prospettiva nella pratica
dello sviluppo del software, che viene per la prima volta concepita come processo industriale (con
le relative necessità di documentazione e controllo) anziché come attività "artigianale" (il
cosiddetto approccio code and fix, che si potrebbe tradurre in italiano come programmazione per
tentativi ed errori). Il ciclo di vita a cascata ebbe un enorme successo negli anni '70 ed è quello
che ancora oggi viene più spesso associato alla programmazione procedurale e strutturata.
A partire almeno dagli anni '80 il modello è stato soggetto a profonde critiche e revisioni,
soprattutto dovute all'evoluzione del software stesso e dei linguaggi di programmazione. Benché
gran parte delle critiche a questo modello siano oggi universalmente accettate, il ciclo di vita a
cascata continua a rimanere un punto di riferimento importante, in sostanza un modello
"canonico" rispetto al quale vengono spesse descritte le "variazioni" moderne; ed è spesso il primo
modello di sviluppo software che si insegna agli studenti.
5.1.1. Definizione
I caposaldi del Waterfall Model sono:
1. Il processo di sviluppo è diviso in fasi sequenziali
2. Ogni fase produce un output che è usato come input per la fase successiva
3. Ogni fase del processo viene documentata.
Il modello a cascata tradizionale prevede le seguenti fasi:
3.1. Studio di fattibilità: ha lo scopo di determinare se intraprendere lo sviluppo del sistema;
3.2. Analisi e specifica dei requisiti: ha lo scopo di determinare cosa farà il sistema; essa
comprende, o è preceduta da, una analisi di fattibilità, in cui si stabilisce se vale la pena
(da un punto di vista tecnico ed economico) realizzare il sistema del quale si vanno
definendo i requisiti;
3.3. Progettazione: ha lo scopo di determinare come il sistema farà quanto stabilito nella
prima fase, e in particolare la sua suddivisione in moduli e le relazioni fra di essi;
3.4. Sviluppo e test di unità: creazione dei moduli con un linguaggio di programmazione
(codifica) e test dei singoli moduli.
3.5. Integrazione e test di sistema: assembramento dell’intero sistema ed esecuzione di
prove per verificare la correttezza del funzionamento complessivo del sistema.
89

3.6. Rilascio e manutenzione: segue la consegna o delivery del prodotto al cliente, e
comprende tutte le attività volte a migliorare, estendere e correggere il sistema nel
tempo.
Esistono molte varianti di questo schema, infatti nel contesto di una specifica organizzazione, il
modello a cascata può essere ridefinito con varianti specifiche. Inoltre, un'organizzazione può
formalizzare ulteriormente il processo definendo standard e imponendo vincoli per quanto
riguarda la natura, il formato, la struttura e/o i contenuti dei documenti prodotti nelle varie fasi (i
cosiddetti deliverable, consegnabili), tipicamente allo scopo di consentire un controllo più rigoroso
sullo stato di avanzamento del progetto e sulla qualità del lavoro svolto.
5.1.2. Fasi
Studio di fattibilità
E’ la prima fase. Scopo
Decidere se debba essere intrapreso un nuovo sviluppo.
Attori coinvolti
Cliente/Committente
Organizzazione aziendale
Output
Un documento che presenti diversi scenari e soluzioni insieme ad una discussione dei
compromessi in termini di costi previsti e benefici.
Svolgimento
Interazione tra gli attori
Ricerca delle soluzioni esistenti
Problemi principali
Analisi spesso svolta sotto pressione e in fretta
90

Analisi dei costi a volte imperfetta con continui rifacimenti
Decisioni premature che ostacolano lo sviluppo successivo
Analisi e specifica dei requisiti
Input
Il documento di studio di fattibilità
Scopo
Identificazione e descrizione dei requisiti, ossia delle caratteristiche del sistema
Attori coinvolti
Cliente/Committente
Sviluppatori
Organizzazione aziendale
Output
Un documento che descrive le caratteristiche del sistema e che colga le esigenze
dell’utente ma sia anche esaustivo per il progettista. Tale documento, per mettere
d’accordo le parti, deve essere facilmente comprensibile, preciso, completo, coerente e non
ambiguo, inoltre facilmente modificabile;
Manuale utente: in alcuni casi può essere utile una versione preliminare in cui si spiega
come l’utente interagirà con il sistema;
Piano di test: non è indispensabile, ma si può decidere in questa fase insieme all’utente.
Svolgimento
Interazione tra gli attori
Più il sistema è innovativo più è necessario interagire
La documentazione va descritta secondo degli standard e delle notazioni specifici
Problemi principali
Assenza di linguaggio comune tra gli attori
Requisiti spesso poco chiari
91

Impossibilità di considerare tutti i requisiti e di produrre un lavoro completo
Progettazione
Input
Il documento di specifica dei requisiti
Scopo
Definire l’architettura del sistema
Attori
Sviluppatori
Output
Definizione della struttura di massima (architettura di alto livello)
Definizione delle caratteristiche dei singoli componenti (moduli)
Svolgimento
Individuazione dei componenti necessari e delle loro caratteristiche
Problemi
Si devono prendere molte decisioni
Non tutte le strutture sono uguali
Non sempre le scelte sono ben definite
Sviluppo e test di unità
Input
I documenti di progetto
Scopo
Implementare i moduli
92

Attori
Sviluppatori
Output
Moduli implementati
Svolgimento
Scrittura del codice
Test di modulo
Controllo di aderenza agli standard
Problemi
Scrittura del codice
Integrazione e test di sistema
Input
I moduli codificati
Scopo
Controllare che i moduli presi uno a uno funzionino
Controllare che una volta messi assieme i moduli continuino a funzionare
Attori
Sviluppatori
Output
Il sistema funzionante
Tecniche di verifica e validazione (alpha test)
Problemi
93

Diversi tipi di problemi soprattutto connessi ad una cattiva analisi dei requisiti
Rilascio e Manutenzione
Tutto ciò che accade dal momento della consegna del sistema alla sua dismissione
Si verifica il software da parte degli utenti (beta test)
E’ una fase molto lunga
5.1.3. Punti di forza
Il Waterfall Model ha storicamente giocato un ruolo importante nello sviluppo del software per
superare i limiti del processo del “code and fix” e infine ha fissato due concetti:
• Il processo di sviluppo del software deve essere soggetto a disciplina e pianificazione;
• L’implementazione del prodotto deve essere rimandata fino a quando non sono
perfettamente chiari gli obiettivi.
Il maggior pregio di questo metodo di lavoro è certamente la semplificazione del controllo
dell’andamento del progetto tramite la suddivisione del ciclo di vita in fasi successive ben definite.
Le diverse metodologie che adottano questo ciclo di vita si distinguono essenzialmente per la
suddivisione e specificazione delle fasi in sottofasi più elementari, nella definizione di standard di
documentazione e nella individuazione di momenti di verifica al termine di ciascuna attività
(milestone). Per ottimizzare il ciclo di vita, la scomposizione delle fasi in sottofasi persegue due
obiettivi:
• assegnare a ciascuna fase la soluzione di problematiche specifiche
• rendere, per quanto possibile, le fasi indipendenti allo scopo di poterne parallelizzare le
attività
Benché l’adozione di questi principi appaia estremamente produttiva, la loro applicazione pratica
ha come effetto collaterale, soprattutto per i progetti di grandi dimensioni, un pericoloso
scollamento fra le diverse attività, sia per le difficoltà di coordinamento che per la difformità delle
metodologie e dei formalismi specialistici adottati. Ad esempio, normalmente l’individuazione delle
strutture dati e delle funzionalità del sistema sono affrontate con metodologie diverse e,
soprattutto per i progetti di grandi dimensioni, contemporaneamente e separatamente da gruppi
94

di lavoro differenti. Nel primo caso i risultati sono formalizzati con uno Schema Entità-Relazione
(ER o Entity-Relationship diagram nella dizione anglosassone) nel secondo con un metodo di
scomposizione funzionale. Solo quando queste due attività terminano viene avviata una ulteriore
attività di armonizzazione dei rispettivi risultati.
Un ulteriore problema di questa impostazione deriva dalla necessità di terminare completamente
tutta la fase di analisi dei requisiti e progetto dell’applicazione per cominciare la programmazione
e quindi verificarne sul campo le conclusioni.
Il modello, quindi, è una semplificazione della realtà che non trova piena applicazione in quanto
vanno rispettati tre principi:
• Linearità: spesso si hanno cicli di feedback (il caso dell’alpha e del beta testing) per la
correzione degli errori. Tale feedback, purtroppo, deve essere lineare e, quindi, non si possono
effettuare salti a ritroso ma vanno ripercorse tutte le fasi in maniera lineare;
• Rigidità: ogni fase viene congelata quando si passa alla fase successiva per cui non è
possibile un’interazione tra clienti e sviluppatori durante il ciclo di vita dopo la parte iniziale;
• Monoliticità: tutto il modello è orientato alla singola data di rilascio che spesso si pone a
mesi o anni dopo l’inizio della prima fase per cui se vengono commessi eventuali errori o
cambiano i requisiti, questi verranno implementati dopo parecchio tempo e comunque alla fase di
consegna seguirà subito un altro adattamento perché il software sarà già obsoleto.
Concretamente queste caratteristiche si traducono nella possibilità di usare il modello in presenza
di requisiti stabili e contratti con costi e tempi ben definiti, disponendo di buone competenze sul
dominio di business in un contesto tecnologico maturo.
5.1.4. Punti di debolezza
I maggiori problemi sono i seguenti:
• È difficile stimare le risorse e i costi in maniera accurata finché non sia stata svolta almeno
la prima fase di analisi;
• La specifica dei requisiti produce un documento scritto che vincola il prodotto da sviluppare
e ciò non sempre soddisfa le esigenze del cliente perché si tratta pur sempre di specifiche basate
su un documento inanimato che non sempre aiuta nel definire le esigenze, che, invece, appaiono
95

subito chiare dopo il primo rilascio del software, inoltre tale documento deve essere completo e
chiaro prima di procedere allo sviluppo, ma non sempre ciò è possibile;
• L’utente spesso non conosce tutti i requisiti dell’applicazione perché non può conoscerli,
motivo per cui non sempre il documento dei requisiti è completo e, quindi, si ha un passaggio alla
fase successiva con documentazione poco chiara;
• Il modello obbliga a usare standard pesantemente basati sulla produzione di una data
documentazione in determinati momenti per cui il lavoro rischia di essere burocratizzato.
Si comprende come gli alti costi del software siano proprio dovuti al modello a cascata a causa
proprio delle specifiche poco complete e ai molti interventi successivi per introdurre funzionalità
non previste in partenza. Capita, quindi, che le pecche del modello vadano a ricadere sulla
manutenzione che, quindi fa lievitare i prezzi o, al contrario, si opera con una manutenzione
sommaria che produce un software con un’implementazione che diverge dalle specifiche dei
requisiti. Il Modello a cascata non va usato quando si ha a che fare con software complesso in un
contesto innovativo, su progetti di lunga durata ( mal si adatta ai cambiamenti ) e in presenza di
requisiti non ben definiti all’inizio.
96

5.2. Metodo di progetto a spirale ( Spiral Model )
Il modello a spirale è un modello evolutivo del ciclo di vita del software. I modelli evolutivi
riconoscono l’inevitabilità delle evoluzione dei requisiti, delle tecnologie, del mercato e
l’impossibilità di arrivare a una soluzione in un unico passo. E’ previsto il rilascio di versioni
successive, con funzionalità parziali, per far fronte alla necessità di seguire le inevitabili evoluzioni
e alle pressioni del mercato e dei concorrenti. Questo si traduce nella rapida disponibilità di un
primo prodotto finito, ma il prodotto finale puo’ richiedere un maggior tempo ed effort rispetto
all’approccio a cascata.
Figura 5-1 Metodo di progetto a spirale [7]
5.2.1. Definizione
Il modello a spirale riconcilia le caratteristiche fondamentali del modello evolutivo :
97

o Lo sviluppo avviene in una serie di incrementi
o Si reitera sulle singole fasi per ottimizzare
o I primi incrementi vengono presentati anche su “carta” ( es. prima specifica iniziale )
Ogni incremento è una ripetizione ciclica delle “task region” ovvero fasi.
5.2.2. Fasi
Customer Communication ( comunicazioni con il cliente ):
o
Attività svolte a stabilire un efficace colloquio tra il cliente e il team di sviluppo
Planning ( pianificazione )
o Raccolta dei requisiti e definizione del piano di progetto ( risorse e scadenze )
Risk Analysis ( analisi dei rischi )
o
Stima e prevenzione dei rischi tecnici e di gestione
Engineering ( strutturazione )
o
Costruzione di rappresentazioni dell’applicazione da sviluppare
Construction & Release ( costruzione e rilascio )
o
Realizzazione, collaudo e installazione
Customer Evaluation ( valutazione da parte del cliente )
o
Rilevazione delle reazioni da parte del cliente
5.2.3. Punti di forza
Tra i principali punti di forza del modello a spirale individuiamo :
o Possono essere utilizzati i vantaggi della prototipazione ad ogni ciclo dell’evoluzione
o Si presta alla gestione di progetti complessivi e/o in contesti innovativi
o Focalizza l’attenzione sugli obiettivi
o I rischi sono presi in considerazione ad ogni stadio del progetto
5.2.4. Punti di debolezza
Tra i principali punti di debolezza del modello a spirale individuiamo :
o Il modello esige competenze ad alto livello per la stima dei rischi
98

o
Il controllo della strategia
5.3. MSF / MOF
5.3.1. MSF
Il Microsoft Solutions Framework (MSF) è un framework che aiuta nella gestione del processo di
sviluppo del software. MSF è un framework progettato per aiutare gruppi di sviluppatori (dai 3 ai
100 e oltre) a gestire le varie fasi della realizzazione del software.
Figura 5-2 MSF: Ciclo di vita del software [3]
La versione attualmente in sviluppo, e sarà differenziata in due versioni:
• MSF for Agile Software Development - più leggera e adatta a situazioni in cui si preferisce
rimanere "agili"
• MSF for CMMI Process Improvement - si basa sulla versione agile, ma la estende per
permettere alle aziende di raggiungere il livello 3 del CMMI (Capability Maturity Model®
Integration, un approccio per il miglioramento del processo di sviluppo proposto dal SEI -
Software Engineering Institute, indipendente dalla metodologia utilizzata). Entrambe le versioni
definiscono un Team Model (molto snello quello agile, molto completo quelli CMMI), e guidano il
processo di sviluppo attraverso delle iterazioni. La versione agile definisce una project guidance
molto semplice, senza milestone formali. La versione CMMI aggiunge alle iterazioni della versione
99

agile delle milestone in cui lo stato del progetto è ben definito. La versione attuale di MSF non
dispone di un prodotto Microsoft che lo supporti come metodo di progetto. MSF 4.0 invece, oltre
ad essere disponibile come documenti e guideline, sarà una delle metodologie per create Team
Project con Team Foundation Server e Visual Studio Team System, in cui saranno supportate
entrambe le versioni, formale e agile.
Figura 5-3 MSF: Successivi raffinamento del ciclo di vita del software [3]
Team Foundation Server e Visual Studio Team System non sono però legati solo ad MSF 4. E'
possibile customizzare una delle versioni di MSF (ad esempio partendo dalla agile e aggiungendo
parti, o partendo dalla CMMI e togliendo ciò che non serve) o adottare una metodologia
completamente diversa (sono disponibili implementazioni di RUP, Scrum ...).
MSF 3.0 (la versione corrente) ed è composta da:
• Process Model - da indicazioni su come strutturare le varie fasi dall'idea iniziale fino
al deployment
• Team Model - da indicazioni su come comporre un team efficiente
• Project Management Discipline - da indicazioni su come affrontare la gestione del
progetto
100

• Risk Management Discipline - da indicazioni su come gestire i rischi in tutte le fasi
del progetto
• Readiness Management Discipline - da indicazioni su come preparare il team ad
affrontare il progetto e a mantenersi aggiornato
MSF 3.0 inoltre fornisce alcune linee guida sull'utilizzo di "strumenti" che possono essere la Daily
Build (il fatto di avere sempre il prodotto in uno stato certo), i Living Documents (al contrario di
molti documenti dei processi tradizionali, che una volta scritti non vengono più aggiornati e
perdono giorno dopo giorno di valore), strumenti che possono essere utilizzati anche senza MSF,
ma che danno il loro meglio all'interno di MSF.
Il fatto che MSF non sia una metodologia o un processo ma che sia un framework significa che
MSF richiede di compiere delle scelte.
MSF va adattato alla propria realtà, non può essere preso e adottato ciecamente, altrimenti non
funziona.
101

5.3.2. MOF
Figura 5-4 Il ciclo di vita IT e i framework Microsoft [2]
Microsoft Operational Framework si occupa di mettere in uso e mantenere funzionanti le soluzioni
IT, come software, sistemi operativi, server. Lo sviluppo e il deployment di una soluzione IT in
genere coinvolgono due team. Il team di progetto si occupa per un periodo di tempo limitato di
pianificare, realizzare e implementare la soluzione. MSF offre una soluzione flessibile e scalabile
per pianificare, progettare, sviluppare e distribuire soluzioni IT di successo, attraverso principi,
modelli e discipline per gestire il personale, i processi, le tecnologie e i rischi legati alla maggior
parte dei progetti.
Il team operativo invece è permanente ed è responsabile del funzionamento e della gestione
continuativa della soluzione. MOF è pensato per assistere questo tipo di team, attraverso
indicazioni tecniche che consentono alle organizzazioni di ottenere livelli mission-critical di
affidabilità, disponibilità, supportabilità e gestibilità per le soluzioni IT basate sui prodotti e le
tecnologie Microsoft. Queste informazioni aiutano a risolvere i problemi relativi al personale, i
processi, le tecnologie e la gestione che caratterizzano i complessi ambienti IT eterogenei e
distribuiti. I due framework sono complementari, per ridurre al minimo il time to value, ovvero il
tempo tra il riconoscimento dell'esigenza e la fornitura del servizio. Anche l'uniformità di
terminologia e concetti tra i due framework contribuisce all'erogazione di servizi di alta qualità. I
102

due framework sono inoltre integrati. Per il deployment di una soluzione IT, ad esempio, è
necessario conoscere sia i requisiti e i controlli utente della soluzione che i requisiti di sistema per
il suo funzionamento. MSF e MOF includono linee guida per i team e i processi che garantiscono il
successo dei deployment negli ambienti di produzione. A tutti i livelli, MSF e MOF favoriscono la
creazione di processi che assicurano che la soluzione (o qualsiasi modifica all'ambiente IT) sia
progettata per l'operatività e la supportabilità, e che soddisfi i requisiti delle release. MOF offre un
insieme di linee guida e best practice riconosciute a livello mondiale che facilitano il
funzionamento e la gestione delle infrastrutture IT. Queste indicazioni sono valide per le
organizzazioni di qualsiasi dimensione, dalle piccole aziende alle compagnie multinazionali. Le
organizzazioni IT possono iniziare ad applicare MOF in qualsiasi area di loro interesse, quindi
ampliarne l'utilizzo ad altre aree. I principi MOF possono inoltre essere applicati in modo graduale,
aggiungendo ulteriori componenti per il perfezionamento delle capacità operative.
Il team model MOF definisce un set di ruoli che coprono tutte le attività necessarie per il
funzionamento di un'infrastruttura IT. MOF assicura la massima flessibilità per l'assegnazione di
questi ruoli nell'ambito di una gerarchia organizzativa esistente. Analogamente, il process model
MOF raggruppa i più comuni processi relativi alle varie fasi del ciclo di vita IT, correlandoli
ai ruoli corrispondenti. MSF e MOF sono un insieme di modelli e di discipline, frutto
dell’ibridazione dei seguenti concetti fondamentali:
o
o
o
Foundational Principles - Sono i principi fondamentali su cui si basa il framework
Key Concepts - Idee che supportano i principi e le discipline di MSF
Proven Practices - Tecniche, metodi e processi che hanno funzionato in progetti reali
103

Figura 5-5 MOF: Modelli e Discipline Coinvolte [2]
All'interno di qualsiasi organizzazione i servizi IT, così come le applicazioni
e l'infrastruttura che li supportano, hanno un ciclo di vita limitato. Questo ciclo
può essere suddiviso in tre gruppi di attività principali:
o Comprendere le esigenze di business e operative per il servizio e creare
una soluzione in grado di soddisfarle, tenendo conto degli specifici vincoli.
o Distribuire la soluzione agli utenti in modo efficace ed efficiente, con tempi
di inattività ridotti al minimo e in conformità con i livelli di servizio.
o
Assicurare un funzionamento eccellente della soluzione per fornire un servizio affidabile
all'organizzazione.
MSF e MOF offrono informazioni e risorse di implementazione per un utilizzo ottimale
delle tecnologie nell'intero ciclo di vita IT. Queste risorse sono organizzate
in due framework: Microsoft Solutions Framework (MSF) e Microsoft Operations Framework
(MOF). MSF permette di soddisfare le esigenze relative al primo gruppo
di attività (analizzare i requisiti e realizzare una soluzione di valore); MSF e MOF permettono di
coordinare processi e attività per il deployment della soluzione nel secondo gruppo; e MOF
permette di soddisfare le esigenze relative al terzo gruppo
di attività, fino alla dismissione della soluzione. MOF inoltre incorpora ed estende un'ampia varietà
104

di best practice messe a punto da altre organizzazioni che si occupano della definizione di
standard IT.
5.3.2.1. Elementi di MOF
I tre elementi chiave di MOF sono:
o
o
o
Il team model
Il process model
La disciplina di risk management
Questi elementi offrono informazioni relative allo staff, i processi e la gestione dei rischi
nell'ambito della gestione dei servizi IT. Ognuno fornisce tecnologie e best practice
per assicurare un elevato livello di disponibilità, affidabilità, supportabilità e gestibilità dei sistemi
sulla piattaforma Microsoft, oltre a indicazioni per l'interoperabilità con altre piattaforme
tecnologiche. Le sezioni che seguono illustrano in dettaglio i tre elementi
di base di MOF.
5.3.2.1.1. Il Team Model di MOF
Il team model MOF è stato sviluppato per assicurare agilità e capacità di adattamento alle
complessità dei team distribuiti, dal punto di vista geografico o organizzativo,
che si occupano della gestione di sistemi distribuiti. Pur assicurando un elevato livello
di flessibilità, il team model MOF definisce specifiche responsabilità per i ruoli
del team. Questo consente alle organizzazioni che utilizzano MOF di misurare e aumentare la
propria efficienza anche se le funzioni sono distribuite tra differenti posizioni geografiche o
sottogruppi.
Il team model MOF organizza la gestione IT in diversi gruppi di ruoli, ovvero singoli
o gruppi che eseguono una serie di attività correlate per il completamento di un particolare
componente di un servizio IT. Questi gruppi di ruoli sono definiti in base
alle best practice di settore per la strutturazione dei team operativi. MOF fornisce quindi ulteriori
informazioni di orientamento relative a tutti i gruppi di ruoli, che descrivono:
Principali attività e competenze per ciascun gruppo di ruoli.
Raccomandazioni per la scalabilità dei team in base alla dimensione e al tipo
di organizzazione.
Criteri per l'efficiente combinazione di più ruoli per i team di piccole dimensioni.
105

Interazione tra i team operativi MOF e i team di sviluppo MSF.
5.3.2.1.1.1. Principi fondamentali
Per sviluppare team operativi efficienti e di successo non sono sufficienti descrizioni
di ruoli e responsabilità. Occorrono anche principi condivisi che definiscano le priorità
di business e le linee guida per il funzionamento del team. I cinque principi più importanti validi
per tutti i gruppi di ruoli definiti dal team model MOF sono:
o
o
o
o
o
Fornire ai clienti servizi tempestivi, efficienti e accurati.
Comprendere le priorità di business e consentire all'IT di offrire business value.
Sviluppare team virtuali che operano in sinergia.
Sfruttare strumenti per l'automazione IT e la gestione delle conoscenze.
Attirare, sviluppare e mantenere personale competente per la gestione IT.
106

5.3.2.1.1.2. Gruppi di ruoli del team model
L'esperienza ha dimostrato che, per il successo, i team di gestione IT devono conseguire numerosi
obiettivi di qualità relativamente alle funzioni chiave per i servizi. I gruppi
di ruoli del team model MOF sono organizzati in base a sette categorie generali
di attività e processi, ognuna delle quali dispone di uno specifico set di obiettivi a livello di qualità.
Le descrizioni dei ruoli all'interno di un gruppo riguardano specificamente
le attività finalizzate al conseguimento degli obiettivi di qualità: non sono descrizioni
di funzioni e non presuppongono alcun tipo di organizzazione aziendale.
Nel diagramma che segue i sette gruppi di ruoli sono associati a decine di possibili
ruoli o team funzionali in una tipica organizzazione operativa. Il resto di questa sezione descrive le
funzioni di ognuno dei sette gruppi di ruoli.
Figura 5-6 MOF: Modelli e Discipline Coinvolte [2]
107

Gruppo di ruoli
Release
Descrizione
Tiene traccia di modifiche ed esperienze in una knowledge base aziendale.
Registra inventari e modifiche in un database per la gestione
delle configurazioni.
Opera a livello intermedio tra il team di sviluppo delle modifiche
e i gruppi operativi; mette in pratica le discipline ITIL per la gestione delle
configurazioni, il controllo e la distribuzione del software.
Infrastructure
Definisce gli standard per l'ambiente fisico.
Gestisce le risorse fisiche.
Si occupa della manutenzione dell'infrastruttura IT e supervisiona l'evoluzione
dell'architettura IT.
Coordina il trasferimento di sedi e strutture, le espansioni
e le acquisizioni, oltre alle modifiche dell'ambiente fisico
come cablaggio, laboratori e connettività degli utenti.
Support Fornisce supporto tecnico per i clienti interni ed esterni,
provvedendo alla risoluzione dei problemi e all'elaborazione
delle richieste di assistenza grazie a knowledge base e strumenti altamente
automatizzati.
Offre supporto di produzione per le applicazioni line-of-business.
Fornisce feedback ai team di sviluppo e progettazione.
Operations Assicura che le attività di routine vengano eseguite in modo
affidabile nell'ambito di aree tecnologiche e sistemi di produzione specifici
(messaggistica, amministrazione dei sistemi e così via).
Esegue processi pianificati e ripetibili come backup dei dati, archiviazione,
gestione dell'output, monitoraggio dei sistemi,
gestione degli event log e gestione di file server e server di stampa.
Partner Definisce e gestisce le partnership in modo conveniente
e vantaggioso per tutte le parti interessate.
Include sia il responsabile interno delle relazioni con le parti esterne
che queste stesse parti.
Security
Garantisce riservatezza, integrità e disponibilità dei dati.
Influenza i criteri di business, ad esempio definendo le procedure
108

da adottare quando un dipendente lascia l'organizzazione.
Service Assicura che tutti i servizi IT forniti ai clienti siano in linea
con le loro effettive esigenze.
Mantiene una relazione di collaborazione con i clienti, comprendendone le
esigenze a livello di servizi IT e gestendo l'introduzione di nuovi servizi, i
miglioramenti dei servizi esistenti
ed eventualmente la riduzione o il ritiro dei servizi.
Tabella 2 Dettagli sui gruppi di ruoli
5.3.2.1.2. Il process model MOF
5.3.2.1.2.1. Panoramica
Il process model MOF offre un riferimento e una descrizione funzionale dei processi eseguiti dai
team operativi per la gestione e la manutenzione dei servizi IT.
Il suo presupposto è che la principale responsabilità dei team operativi sia la gestione dei
cambiamenti nell'ambiente IT. Il modo più efficiente per gestire le modifiche nell'intero ciclo di
vita di un servizio è raggruppare le modifiche correlate in un pacchetto denominato release, in
modo da poter pianificare e gestire le modifiche come un singolo elemento. Il process model MOF
descrive un ciclo di vita che può essere applicato a qualsiasi release, insieme ai processi e alle
attività che compongono ogni fase di tale ciclo di vita.
5.3.2.1.2.2. Principi fondamentali
Il process model MOF è basato su quattro principi:
o
o
o
Architettura strutturata. Il process model MOF organizza tutte le attività operative
necessarie per i sistemi di elaborazione mission-critical negli ambienti IT complessi.
Rapidità del ciclo di vita e costante miglioramento. MOF supporta un ciclo di vita IT
iterativo, che permette di valutare e implementare rapidamente le modifiche
per rispondere all'evoluzione delle esigenze di business.
Gestione basata sulle verifiche. In base al process model, sono necessarie verifiche OMR
(Operations Management Review) nelle fasi chiave del ciclo di vita. Nel corso di queste
verifiche, il team e i principali interessati valutano le prestazioni per le attività relative alle
release e per le attività operative in cui la componente tempo
è fondamentale.
109

o
Gestione dei rischi. Poiché la mancata disponibilità di un servizio IT può avere conseguenze
catastrofiche in termini di costi, MOF offre gli strumenti per una gestione preventiva dei
rischi a tutti i livelli dei processi operativi.
5.3.2.1.2.3. Quadranti per il process model
Il process model MOF descrive un ciclo di vita applicabile alle release di qualsiasi dimensione e
relative a qualsiasi soluzione per i servizi. Il modello raggruppa le funzioni simili di gestione IT,
denominate SMF (Service Management Function), in quattro quadranti. A ogni quadrante
corrisponde una specifica mission del servizio. Benché
la struttura circolare del process model MOF implichi uno svolgimento in sequenza
delle attività di gestione, di fatto in un'organizzazione possono aver luogo contemporaneamente
diverse release, ognuna in una fase differente del ciclo di vita IT. Inoltre, le funzioni SMF descritte
nei quadranti Operating e Support avvengono continuamente e simultaneamente all'interno del
data center. Il diagramma che segue illustra il ciclo di vita di base, inclusi i quattro quadranti e le
quattro verifiche OMR (Operations Management Review).
Figura 5-7 MOF: Il Process Model di MOF [2]
Nella seguente tabella sono riportate le mission del servizio e le verifiche OMR
per ciascun quadrante.
110

Quadrante Mission del servizio Verifica OMR
Changing Introdurre nuovi servizi,
tecnologie, sistemi, applicazioni,
hardware e processi.
La Release Readiness Review concede
l'approvazione per il deployment della
soluzione, una volta completati lo sviluppo
e il testing.
Operating
Eseguire le attività di routine
in modo efficace ed efficiente.
La Operations Review viene svolta
periodicamente per valutare la capacità
dello staff IT di mantenere un determinato
servizio,
soddisfare
i requisiti per il livello di servizio
e documentare la propria esperienza
in una knowledge base.
Supporting Risolvere i problemi ed
elaborare le richieste di
assistenza rapidamente.
La SLA (Service Level Agreement) Review
viene svolta periodicamente per valutare la
capacità dello staff di soddisfare i requisiti
per il livello
di servizio definiti dal Service Level
Agreement.
Optimizing
Orientare le modifiche in modo
da ottimizzare costi, prestazioni,
capacità e disponibilità
nell'erogazione dei servizi IT.
La Change Initiation Review aumenta la
probabilità che i cambiamenti proposti
siano in linea con gli obiettivi di business e i
requisiti operativi.
Tabella 3 Dettagli sui gruppi di ruoli
Due delle verifiche OMR dipendono dalla pianificazione della release. La Change Initiation Review
(in precedenza denominata Release Approved Review) viene completata prima che abbia inizio il
lavoro di sviluppo per una release nuova o aggiornata, mentre la Release Readiness Review viene
eseguita prima del deployment della release nell'ambiente di produzione. La Operations Review e
la SLA Review vengono svolte a intervalli regolari dopo l'introduzione di una release, allo scopo di
valutare le prestazioni e le operazioni interne rispetto ai livelli di servizio per i clienti.
111

Come risultato, il quadrante Operating è quello in cui MOF fornisce la maggior
parte delle specifiche indicazioni per i prodotti e le tecnologie Microsoft. Inoltre, in conseguenza
della grande attenzione dedicata da Microsoft alla gestione IT, numerosi prodotti ora incorporano
caratteristiche e funzionalità direttamente finalizzate a renderli più supportabili, affidabili e
gestibili. Dove possibile, MOF estende le funzioni SMF di base identificate da ITIL con riferimenti
specifici per i prodotti Microsoft e caratteristiche che automatizzano o migliorano l'erogazione di
tali funzioni.
Relazione tra process e team model
I gruppi di ruoli del team model MOF sono allineati con i quattro quadranti del process model MOF,
come illustrato di seguito. Più ruoli possono essere coinvolti in un singolo quadrante e uno stesso
ruolo (come ad esempio Security) può riguardare più quadranti. Il gruppo di ruoli Partner è stato
omesso poiché può essere coinvolto in tutte le fasi del process model.
5.3.2.1.3. La disciplina di risk management MOF
5.3.2.1.3.1. Panoramica
MOF e MSF organizzano le informazioni relative alla gestione dei rischi in un corpus
di conoscenze definito disciplina. La differenza tra discipline e modelli sta nel fatto
che le conoscenze veicolate da una disciplina possono essere applicate a qualsiasi fase
di qualsiasi processo. Le discipline di MOF e MSF per il risk management sono sostanzialmente
identiche, sebbene le descrizioni e gli esempi forniti nella loro presentazione possano variare.
La disciplina di risk management per i processi operativi applica consolidate tecniche
di gestione ai problemi che i team operativi si trovano quotidianamente ad affrontare. Sono
disponibili numerosi modelli, framework e processi per la gestione dei rischi.
Tutti mostrano dei tratti comuni nelle modalità con cui identificano e gestiscono i rischi. Le
discipline di risk management MOF e MSF si rivelano superiori rispetto a questi approcci grazie
all'applicazione di principi chiave, una terminologia personalizzata,
un processo strutturato e ripetibile per l'analisi e la valutazione dei rischi e l'integrazione
in framework operativi di più ampia portata.
112

5.3.2.1.3.2. Principi fondamentali
La disciplina di risk management per i processi operativi è basata sui seguenti principi:
o
o
o
o
o
Valutare continuamente i rischi. Questo significa che il team provvede costantemente
all'identificazione dei nuovi rischi e alla rivalutazione di quelli esistenti.
Integrare la gestione dei rischi in ogni ruolo e funzione. Ad alto livello, questo significa che
ogni ruolo IT condivide parte della responsabilità per la gestione dei rischi e che ogni
processo IT viene progettato tenendo in considerazione la gestione dei rischi.
Trattare in modo positivo l'identificazione dei rischi. Per il successo nella gestione dei rischi,
è necessario che i membri del team possano identificare i rischi senza temere critiche o
"punizioni".
Usare pianificazioni che tengono conto dei rischi. Gestire un ambiente spesso significa
eseguire modifiche in sequenza: quando possibile, il team deve apportare innanzitutto le
modifiche più rischiose per evitare di sprecare tempo e risorse su modifiche che non
possono essere introdotte nell'ambiente di produzione.
Stabilire un approccio formalizzato e condiviso. Per il successo è necessario un processo
che il team comprende e utilizza.
È possibile riassumere questi principi con la parola prevenzione. Un team che mette in atto una
gestione preventiva dei rischi riconosce che il rischio è parte dei normali processi operativi e,
invece di temerlo, lo vede come un'opportunità per aumentare la sicurezza
in futuro. I membri del team dimostrano un atteggiamento preventivo adottando un processo
visibile, misurabile, ripetibile e continuo per la valutazione obiettiva di rischi
e opportunità, oltre che intraprendendo azioni che risolvono non solo i sintomi, ma anche le cause
dei rischi.
5.3.2.1.3.3. Processo di gestione dei rischi
Il seguente diagramma illustra le fasi che compongono il processo di gestione dei rischi (risk
management process): identificare, analizzare, pianificare, registrare, controllare e apprendere. È
importante comprendere che ogni rischio attraversa tutte queste fasi in almeno un'occasione e
spesso più volte. Ogni rischio, inoltre, ha una sua tempistica, per cui in un determinato momento
diversi rischi possono trovarsi in ognuna di queste fasi.
113

Figura 5-8 Il processo di gestione dei rischi [2]
Le sei fasi conducono i responsabili della gestione dei rischi e i membri del team attraverso un
processo che permette di identificare il rischio, stabilirne il potenziale impatto e pianificare una
soluzione in modo preventivo. Le altre fasi del processo permettono alle organizzazioni di tenere
traccia dei rischi in tutto il ciclo di vita IT, controllare quelli che si verificano e apprendere dalla
propria esperienza.
114

APPENDICE
1. Manuale per la procedura di deployment
1.1. Cenni Preliminari
La procedura descritta nei capitoli seguenti descrive i vari passaggi necessari per la installazione
della soluzione di e-government sviluppata da Microsoft Services definita “Posta Certificata”.
Prima di passare alla fase implementativa, è necessario chiarire alcuni punti relativi alla
realizzazione della soluzione, a come è stata progettata, e definire alcune best practices nella
conduzione, che sono conseguenti al modo con cui la soluzione è stata disegnata.
1.2. Nomi di Dominio
Nel documento che segue, si fa riferimento a nomi di dominio definiti “dominio.org”,
“certificata.dominio.org” e “normale.dominio.org”: si sono utilizzate queste nomenclature per
definire un generico nome di dominio.
Al momento dell’implementazione della soluzione in un laboratorio è consigliato l’utilizzo di
questa nomenclatura. Quando la soluzione verrà invece implementata in un ambiente di
produzione, questi nomi dovranno essere sostituiti con i nomi opportuni, decisi in fase di progetto
di implementazione.
1.3. Certificati
Nel KIT di distribuzione della PEC c’è una cartella contentente due certificati (un certificato ROOT e
un certificato di firma digitale rilasciato all’utente posta-certificata@certificata.dominio.org. Si
tratta di due certificati di prova che possono essere utilizzati per testare l’ambiente della soluzione
in un ambiente di laboratorio. In un ambiente di produzione, sarà necessario utilizzare due
certificati rilasciati appositamente da una Certification Authority riconosciuta e autorizzata a
rilasciare certificati di firma digitale.
1.4. Infrastruttura
L’infrastruttura descritta e il conseguente numero di macchine descritte è tagliato per una
implementazione in ASP della Posta Certificata in alta affidabilità. In un ambiente di laboratorio
l’infrastruttura può essere ridotta a 1 domain controller/Global Catalog/SqlServer2000, 1
Exchange di FE e 1 Exchange di BE ( eventualmente in modalità cluster, a 2 nodi ).
1.5. Utilizzo di MAPI vs SMTP
La soluzione prevede l’impiego esclusivamente di client che usano SMTP-POP3S/IMAPS-HTTPS, in
115

quanto le specifiche, dettate dall’allegato tecnico del decreto che istituisce la Posta Certificata
definiscono questi protocolli come gli unici in grado di poter essere utilizzati. Il problema non è
tecnico quanto normativo: il fatto che sia possibile utilizzare un client MAPI per spedire/ricevere
posta certificata non implica che sia normativamente corretto.
1.6. SQL Server e ORACLE
La soluzione disegnata da Microsoft prevede l’impiego di un DB relazionale posizionato su un
Microsoft SQL Server. E’ opportuno chiarire che la soluzione non prevede la sostituzione di questo
componente con DB server di altri fornitori, come Oracle o IBM DB2.
1.7. ANTIVIRUS
Se il mittente invia una mail virata ed il gestore mittente la rileva allora viene generata una
Ricevuta di NON Accettazione per Virus. Se il mittente invia una mail virata ed il gestore mittente
NON se ne accorge ma se ne accorge il gestore Destinatario allora il gestore reimbusta la mail in
una BDS, conservandola per 30 mesi, e manda un avviso di non accettazione al gestore mittente
(nella presa-in-carico) oltre alla ricevuta di presa in carico ( che viene inviata come notifica di mail
ricevuta ) quindi il gestore mittente manda una ricevuta di mancata consegna per virus. Se il
mittente invia una mail virata ed il gestore mittente NON se ne accorge e non se ne accorge
neanche il gestore Destinatario, allora la responsabilità è demandata all'utente finale.
1.8. Versioni del software, Patch e Service pack.
L’attuale versione di posta Certificata è stata disegnata per girare su:
Windows 2003 Enterprise Service Pack 1
Exchange 2003 Enterprise Service Pack 1
SQL Server 2000 Enterprise Service Pack 4
Sybari Antigen for Exchange v. 8.00.1517 SR3
CAPICOM versione 2.0.0.3
.NET Framework 1.1 (già presente sulla versione di Windows 2003)
La procedura di Posta Certificata NON E’ certificata per girare su sistemi con configurazioni diverse
da questa. Una versione di service pack o una hotfix in più oltre a quanto descritto potrebbe
invalidare il sistema. Il regression test che abilita l’inserimento di una hotfix o di una service pack
deve essere svolto dal supporto tecnico Microsoft.
116

1.9. Descrizione di massima dell’infrastruttura
Lo schema della infrastruttura del sistema di Posta Certificata è il seguente:
Internet
1 – Database Log
1 – SMTP Filter
2 – SMTP Verify
3 – SMTP Sink
4 – Capicom, EMCSign
5 - VS1Auth Filtro Message-ID
6 - VS2Anon Filtro VerifySign
7 – GAC DLLs ( emcconfig,
interop.adodb, interop.cdo, utility )
AD/GC/SQL
FE - Exch2003
BE - Exch2003
Cluster
1 – Storage Filter Sync ( COM+ )
2 – ServicesPECBackendStorageBDS ( COM+ )
3 – Capicom, EMCSign
4 – GAC DLLs ( emcconfig, interop.adodb,
introp.cdo, utility, interop.cdoexm )
5 – PEC.Agent
( Exchange SDK (6/2K2) )
Figura 1-1 Schema dell’infrastruttura
In sintesi, si tratta di un sistema basato su Windows 2003 ed Exchange 2003. Gli utenti sono
memorizzati in un active directory contenuto nei due Global Catalog.
Sui server di Front-End, che sono dual-homed e dal lato esposto verso Internet bilanciati
via Local Director, viene installato Windows 2003 Enterprise ed Exchange2003 Enterprise
117

Edition. Su questo vengono istanziati i due filtri di FrontEnd (il filtro per il cambio del
Message-ID e il filtro che svolge i ruoli di PDA e di PDR)
I due server di Back End sono in cluster MSCS, con due virtual server definiti: il primo,
Exchange2003+SP1 sui cui si istanzia il filtro che svolge i ruoli di PDA/PDR/PDC, e il
secondo, SQL2000, su cui vengono appoggiati i dati transienti di logging.
I client sono esclusivamente SMTP/POP3/IMAP4 su canale SSL con autenticazione obbligatoria
anche su SMTP e devono essere attestati sui server di Front-End.
Se i client vengono dal lato esposto dei firewall, dovranno avere impostato come server SMTP e
server POP3/IMAP4 l’indirizzo bilanciato.
1.10. Procedura di installazione infrastruttura
1.10.1. Installazione sistemi operativi e software di base
Installare il Domain Controller con Windows 2003 Server Enterprise Edition ( e passare la
Service Pack 1 se non integrata ).
Effettuare la DCPROMO, e installare il dominio ActiveDirectory (es. contoso.local )
Installare SQL Server 2000 e passare la SP4 di SQL2000.
Installare il / i server di Front End con Windows 2003 Enterprise Edition ( passare la
ServicePack1 di W2003 se non integrata ).
Iniziare l’installazione di Exchange sulle macchine di FE effettuando l’estensione dello schema
di AD tramite FORESTPREP e DOMAINPREP.
Successivamente installare Exchange 2003 Enterprise Edition sui server di FrontEnd e passare
la SP1 di Exchange.
Impostare i server di FrontEnd in modalità “Exchange FRONT-END” e verificare il corretto
funzionamento.
Installare il / i server di BackEnd con Windows2003 (passare la ServicePack 1 se non
integrata ) e configurare eventuali cluster.
Se si sta installando Exchange su cluster, creare la risorsa Distributed Transaction
Coordinator, necessaria per la corretta installazione di Exchange 2003 in modalità cluster (
fare comunque riferimento alla procedura dettagliata di installazione e configurazioni di un
cluster Exchange, trascurata in questa sede )
Installare Exchange 2003 Enterprise Edition su i 2 nodi del cluster di BackEnd (BE) e passare
la SP1 di Exchange su entrambi i nodi.
Installare Antigen for Exchange v. 8.00.1517 SR3 della Sybari su ogni server Exchange ( nel
caso del cluster su entrambi i nodi ).
118

Per istanziare l’Application Scan Job su Frontend e Backend, indispensabile per il corretto
funzionamento della PEC, è necessario sovrascrivere il file license.cfg presente nella cartella di
installazione del programma con quello fornito nel package PEC ed eseguire il comando
“AntigenStarter l” ( L minuscola ) da linea di comando.
Successivamente dal client di Antigen disabilitare tutti i Job tranne l’Application Scan Job, sia
su BE che su FE. Se non ancora abilitato, occorre abilitare l’Application Scan Job scegliendo
dal pannello di sinistra la voce OPERATE e successivamente l’opzione RUN JOB.
Abilitare il Virus Scanning, il File Filtering ed il Content Filtering. Svolte queste operazioni la
corretta schermata di configurazione che dobbiamo visualizzare è la seguente.
Figura 1-2 Schermata di configurazione di Antigen
119

Dopo aver effettuato l’abilitazione dello “Application Scan Job”, è fondamentale effettuare la
configurazione per l’aggiornamento automatico dei motori di ricerca di Antigen, quali: Norman,
Sophos, CA Inoculate, Ca Vet e Sybari Worm List.
Figura 1-3 Schermata di configurazione degli engine di scanning di Antigen
L’aggiornamento in automatico dei 5 motori di ricerca di Antigen è configurabile semplicemente
abilitando la voce “Use Proxy Server” e successivamente specificando quale è il server Proxy da
utilizzare tramite l’opzione “Proxy Setting”. Il campo Network Update Path è impostato
correttamente di default. Tramite l’utilizzo del calendario riportato in basso a sinistra è possibile
decidere con quale cadenza effettuare controlli per nuovi aggiornamenti.
120

Dall’ActiveDirectory Domains & Trusts, dalle proprietà di “ActiveDirectory Domains & Trusts”,
creare due suffissi alternativi UPN per posta normale e per posta certificata (es.
“contoso.com” e “pec.contoso.com”)
Dall’active Directory Users and Computer, creare due OU, una per posta NORMALE e una per
posta CERTIFICATA
Creare utenti in OU NORMALE (suffisso UPN: contoso.com ) e in OU CERTIFICATA (suffisso
UPN: pec.contoso.com)
Creare utente in CERTIFICATA chiamato “posta-certificata” con suffisso UPN pec.contoso.com;
Creare un utente in CERTIFICATA chiamato "presa-in-carico" con suffisso UPN
pec.contoso.com;
Dall’Exchange System Manager creare una Recipient Policy per NORMALE, con una query che
seleziona gli utenti che hanno una mailbox con Logon Name “ends with” “@contoso.local”.
Inserire un ulteriore indirizzo SMTP, da rendere primario, con indirizzo “@contoso.com”
Dall’Exchange System Manager creare una Recipient Policy per CERTIFICATA, con una query
che seleziona gli utenti che hanno una mailbox con Logon Name “ends with”
“@pec.contoso.com”. Inserire un ulteriore indirizzo SMTP, da rendere primario, con indirizzo
“@pec.contoso.com”
Effettuare il rebuild e l’update delle due recipient policy.
Verificare che gli utenti abbiano gli indirizzi di email aggiornati.
Nella OU Users creare un utente amministrativo “ExAdmin”, privo di mailbox, e renderlo
membro dei gruppi Domain Admins, Domain Users, Exchange Domain Servers. Tale utente
deve essere inserito nelle permission della SystemMailbox di riferimento del Back-End ( la
SystemMailbox ha la funzione di gestire l’applicazione di PEC e ogni operazione sul server da
origine ad un evento sincrono che di solito genera uno scambio di email ).
Sotto Active Directory Users And Computers, dopo aver abilitato View -> Advanced Features,
in Microsoft Exchange System Object visualizzare le proprietà della SystemMailbox{id}del
backend: nel tab “Exchange Advanced” selezionare Mailbox Rights e aggiugere l’utente
ExAdmin attivandone i grant “full mailbox access”, “Take Ownership”, “Change Permissions”,
“Read permissions”, “Delete Mailbox Storage”. Nel tab “Security” aggiugere l’utente ExAdmin
e attivarne il grant “full control”. Effettuare l’apply delle modifiche.
1.10.2. Certificati di root e per Posta-Certificata
In un ambiente in produzione, è importante che il certificato con cui i server di Posta Certificata
firmano i messaggi e le ricevute, sia un certificato con valenza legale, e quindi acquistato presso
121

uno dei provider autorizzati e previsti dalla legislazione Italiana.
In un laboratorio o in una fase sperimentale, invece, è possibile utilizzare dei certificati rilasciati
da una CA anche realizzata sulla propria infrastruttura. Qualora nel laboratorio si fosse usata la
nomenclatura di domini definita in questo documento, è possibile usare i due certificati presenti
nel kit di installazione, nella directory \certificati.
La procedura descritta in questo paragrafo, invece, descrive come installare una CA e farsi
rilasciare i certificati di tipo corretto per l’applicazione.
Installare un Certificate Server di tipo Enterprise su uno dei Global Catalog / Domain
Controller.
Aggiungere il template Exchange User ai templates della CA:
Dallo strumento Certification Authority di Administrative Tools, aprire lo snap-in
Certificate Authority.
Cliccare su
Cliccare su Certificate Templates
Con il tasto destro, accedere al menu “new”
Selezionare “New” -> “Certificate Template to Issue”
Selezionare Exchange User
Chiudere l’MMC
Creare e registrare il certificato per la firma delle mail:
Il Certificato va creato una volta e registrato su ogni macchina ( FE / BE )
dell’infrastruttura di Posta Certificata.
Da una delle macchine Exchange, aprire Internet Explorer e inserire l’indirizzo:
“http://[Netbios name della Certification Authority]/certsrv”
Selezionare “Request a certificate” e premere NEXT
Selezionare “Advanced request” e premere NEXT
Selezionare “Create and submit a request to this CA” e premere NEXT
Selezionare come Certificate Template: “Exchange User” e compilare il form,
specificando come indirizzo di mail:
“posta-certificata@”
Spuntare “Mark keys as exportable”, “Store certificate in the local computer certificate
store” e sotto Additional Options “PKCS10”. Cliccare SUBMIT.
Premere “Install this certificate”.
A questo punto è necessario aprire una MMC ed inserire gli SNAP-IN relativi alla
122

gestione dei Certificati. Aggiungere lo snap-in “Certificates” per “My User Account” e
“Computer Account (Local Machine)”.
Salvare l’MMC sul Desktop per future referenze.
Nella MMC, ricercare il certificato appena installato. Può trovarsi sia in
LocalComputer/Personal/Certificates che in Current User/Personal/Certificates.
Identificatolo, cliccare il pulsante dx del mouse e selezionare All Tasks -> Export.
Seguire il Wizard di esportazione specificando “Yes, Export The Private Key”, spuntare
solo “Include all certificates in the certification path if possibile”, impostare una
password per l’importazione del certificato e impostare un nome di file (per semplicità
salvarlo in una zona condivisa, es. “\\[Netbios name del domain controller]\sysvol”di
modo che anche dalle altre macchine si possa importare il certificato).
Installare il certificato su TUTTE e SOLO le altre macchine Exchange :
Accedere alla zona condivisa “\\[Netbios name del domain controller]\sysvol”
Fare doppio click sul file .pfx contenente il certificato.
Inserire la password precedentemente stabilita e lasciare vuote le caselle di
spunta
Selezionare “Automatically select the certificate store based on the type of
certificate”.
Una finestra pop-up avviserà del buon esito dell’operazione.
1.10.3. Doppi Virtual Server SMTP sui Front End
L’allegato tecnico del Decreto della Posta Certificata, descrivente le specifiche, prevede che la
comunicazione tra il client di posta elettronica ed il server SMTP, che ha funzioni di PDA, avvenga
tramite comunicazione TSL/SSL e facendo uso di SMTP autenticati. La procedura descritta nel
presente paragrafo descrive le operazioni da effettuare per la corretta impostazione di un secondo
virtual server SMTP anonimo, da utilizzarsi per le comunicazioni Server-to-Server, e di un SMTP
autenticato.
Aggiunta di un IP da abbinare al secondo SMTP Virtuale
Aggiungere un secondo NIC ( Network Adapter Interface ) a cui assegnare un secondo
indirizzo ip per la comunicazione di tipo anonymous ( ad esempio, se il primo NIC
aveva ip 192.168.150.7, assegnare al secondo NIC ip 192.168.150.8 ).
123

Creazione & configurazione di 2 SMTP diversi per le 2 diverse comunicazioni (autenticata e
anonima). [ NOTA : gli attuali script di installazione della PEC si riferiscono ai VS Smtp in base
alla loro cardinalità: il primo VS Smtp ( quello istanziato di default ), che si chiama
SmtpSvc11, è mappato nell’infrastruttura come Smtp Anonymous, il secondo VS Smtp ( quello
creato ) è mappato nell’infrastruttura come Smtp Authenticated ] :
Sotto Exchange System Manager Protocols SMTP rinominare il virtual server
esistente ( VS1 ) in “Auth SMTP” e impostare l’IP address di ascolto sul primo indirizzo
pubblico ( es. 192.168.150.7 ). Nella cartella “Access” “Authentication” controllare
che siano selezionati “Basic Authentication” con il nome netbios di dominio e
“Integrated Authentication”.
Abilitazione della connessione HTTPS obbligatoria su Auth SMTP :
Fare click dx sul VS properties spostarsi nel tab ACCESS click sx su
“certificate” create a new certificate scegliere se inviare la richiesta
immediatamente o se limitarsi a prepararla per inviarla in seguito
scegliere il nome del certificato (es. SSL ) proseguire lasciando le
impostazioni di default ove presenti e fornendo quelle assenti relative
all’organizzazione il certificato è ora generato e installato. Può essere
usato anche dagli altri VS che richiedono una connessione HTTPS
Dal tab ACCESS delle properties del VS Auth fare click sx su
COMMUNICATION e spuntare “require secure channel” e “require 128-bit
encryption” .
Nel Tab. “Delivery” Advanced inserire nello “smart host” l’indirizzo IP fra
parentesi quadre o il nome DNS del BACK-END.
Sotto Exchange System Manager Protocols SMTP, creare un 2ndo virtual server
SMTP e rinominarlo in “Anon SMTP” e selezionare l’ip di ascolto sul 2ndo ip disponibile,
associato alla 2nda scheda di rete ( es. 192.168.150.8 ). Nella cartella ACCESS
Authentication controllare che sia selezionato SOLO l’anonymous authentication. Nel
1 per verificarne il nome è sufficiente cliccare il pulsante dx del mouse sul VS properties spuntare “enable logging”
click sx su properties in basso nella finestra appena visualizzata è possibile leggere l’effettivo nome del VS nel campo
“Log File Name”.
124

caso in cui sia presente un relay server per indirizzare le mail verso l’esterno inserire
nel tab Delivery Advanced, sotto il campo SMARTHOST, il nome DNS o l’indirizzo IP
tra parentesi quadre del RELAY SERVER verso l’esterno.
Configurazione di IIS ( necessario per l’accesso su HTTPS da OWA )
Start Administrative Tools IIS Sotto Web Sites Default Web Site click
pulsante DX properties.
Sotto il tab DIRECTORY SECURITY Secure Communications fare click sx su SERVER
CERTIFICATE selezionare ASSIGN EXISTING CERTIFICATE e passargli il certificate
precedentemente creato confermare come porta SLL la 443.
Sotto DIRECTORY SECURITY Security Communications click sx su EDIT
spuntare REQUIRE SECURE CHANNEL e REQUIRE 128-bit CONNECTION Cliccare
APPLY e alla richiesta di applicazione dell’inheritance sui child nodes di Default Web
Site selezionare tutti i child nodes, a meno di impostazioni specifiche.
Sotto DIRECTORY SECURITY Authentication and access control fare click sx su
EDIT e spuntare BASIC AUTHENTICATION.
Sotto Web Sites Default Web Site Exchange fare click DX properties
DIRECTORY SECURITY authentication and access control click su EDIT e
disabilitare ANONYMOUS ACCESS.
125

Lo schema seguente descrive in modo schematico i virtual server che vengono istanziati su
FrontEnd e su BackEnd.
Figura 1-4 Doppi Virtual Server SMTP
Per far si che funzioni il flusso, è importante che vengano impostati gli smarthost. Verificare che :
Sui VS AuthSMTP di FE, lo smarthost punti al VS del BE.
Sui VS AnonSMTP dei FE, lo smarthost punti al relay SMTP server che invia posta verso
la rete pubblica, se presente.
Nel caso in cui i server di FE siano più di uno è necessario creare un SMTP
Connector impostando come gateway d’uscita il nome DNS o l’IP del Relay
verso l’esterno e come server legati a questo connettore i VS anonimi creati.
126

1.10.4. Modifica dei file di configurazione
I file di configurazione da modificare manualmente necessari per l’installazione della PEC sono i
seguenti ( tra parentesi, dopo il nome del file, è indicato il percorso relativo dalla root del package
ove è possibile reperire il file ) :
CertificateDomains.xml (\certificatedomains\):
Inserire le seguenti informazioni :
Domain name = il nome del dominio certificate
Certificate = il certificato con si firma quel dominio
Provider name =
mailReceipt =
providerCertificateThumprint = inserire il campo “Thumbprint” dal tab “Details” della
visualizzazione estesa del certificato ( doppio click sullo stesso ) senza spazi.
verifyCLR = revocation list
msgIdSuffix = quale deve essere il dominio inserito dopo posta-certificata@
private = se quel dominio può interoperare con altri domini certificati o solo col suo
gestore
maxDim =
Il file deve essere lo stesso su ogni macchina !!!
Configfile.reg ( BackEND ) ( \config\):
Contiene il percorso del file principale di configurazione:
Aggiornare i percorsi di installazione della PEC
Registrarlo effettuando un doppio click sul file .reg
Nel caso di un cluster di BE il file deve essere lo stesso su entrambi i nodi !!!
Configfile.reg ( FrontEND ) ( \config\):
Contiene il percorso del file principale di configurazione:
Aggiornare i percorsi di installazione della PEC
editarlo inserire il path corretto per la directory della posta certificata e
inserire il numero in “MessageIDPrefix” del FE in oggetto; si ricordi che il
numero deve essere unico per ogni FE.(nel caso del primo FE il numero sarà 0 e
poi a salire….)
e registrarlo effettuando un doppio click sul file .reg
127

Nel file EMCConfig.xml ( \config\) settare:
il Trace Level ( 1 = default; 2 = warning; 3=critical; 4=verbose ) settare 1 in
ambienti di produzione a sistema collaudato e funzionante, 4 in ambiente di
testing & deployment.
???Dumpemail = inserire l’indirizzo di posta elettronica dello user che riceverà
eventuali mail di dump del sistema ( CREARE UTENTE PER RICEVERE TALI MAIL
)
il nome ed il percorso del file delle tracce;
il percorso del file CertificateDomains.xml;
Sia nella sezione che nella sezione compilare il
campo con l’indirizzo le configurazioni di sicurezza dello SMTP
Anonimo a cui sono spedite le ricevute in uscita (ad esempio: ) e inserire il percorso locale alla directory di pickup
( o il percorso alla directory di pickup, al disco condiviso nel caso di un cluster )
inserire il percorso corretto per la directory BackupBDS (attributo
dumpemail)
la connectionstring per il collegamento al DB per i log (ip di sqlserver, login e
password)
il nome del gestore emittente ( es. MSFT )
la/e email a cui saranno indirizzate le email di DUMP ( attributo DumpEMAil )
Nel file setvars.cmd di BE ( \ ) settare:
dominio\username e password dell’utente ExAdmin
Path del pacchetto PEC e del .NET Framework
Il guidstore della systemmailbox del server di backend ( ricavare il GUID della
SystemMailbox del server Exchange di BE da Active Directory Users &
Computers: dopo aver abilitato View -> Advanced Features verificare quale
SystemMailbox tra quelle presenti in Exchange System Objects è quella del
server di BE. Copiare solo l’identificativo numerico del GUID e incollarlo nel file.
Nel file setvars.cmd di FE ( \ ) settare:
Path del pacchetto PEC e del .NET Framework
128

Nei file regevent.cmd e deregevent.cmd di BE ( \BE\Register\ ) settare:
Aggiornare il nome del server / cluster Exchange di BE con il suo attuale nome
netbios.
Aggiornare il percorso cui fanno riferimento i file register.cmd e unregister.cmd presenti nella
cartella \Microsoft.Services.PEC\
Aggiornare eventuali percorsi obsoleti nei file registerall.cmd e unregisterall.cmd
1.10.5. Installazione Applicativa
1.10.5.1. Exchange BackEnd
NOTA: durante l’installazione su cluster assicurarsi che le risorse appartengano al nodo sul quale
si sta effettuando l’installazione.
Scompattare il file Zip sotto il disco locale, se possibile in D:\Posta Certificata verranno create
le sottocartelle :
o D:\PostaCertificata\BE
o D:\PostaCertificata\COM
o D:\PostaCertificata\TraceLog
o D:\PostaCertificata\Config
o D:\PostaCertificata\PerfCountSetup
o D:\ PostaCertificata\BackupBDS
o D:\ PostaCertificata\CertificateDomains
o D:\ PostaCertificata\PecAntivirus
o D:\ PostaCertificata\ServicePECBackEndStorageBds
o ….
Sulla macchina/nodo di BE, effettuare il Logout e riaccedere come EXADMIN
Aggiungere le informazioni del file configfile.reg al registro ( pulsante Dx sul file merge )
129

Lanciare il file RegisterAll.cmd
Alla comparsa della finestra che richiede l’inserimento di un account per l’esecuzione del
servizio di sistema “Microsoft Services PEC Agent”, fornire le credenziali dello user EXADMIN.
Verificare che il file di log ( presente in D:\ secondo impostazioni di default ) non contenga
errori.
Per completezza si descrivono in seguito le azioni effettuate dal file di comandi RegisterAll.cmd
come se si dovessero effettuare manualmente:
Registrare il filtro in interop lanciando lo script regasm.cmd da dentro la cartella
D:\PostaCertificata\BE
Effettuare la registrazione della EMCsign.dll contenuta nella cartella D:\PostaCertificata\COM
con il comando REGSVR32 EMCSIGN.DLL
Registrare il filtro di BE sotto COM+:
Creare un package COM+ di tipo server chiamato "Posta Certificata"
Settarne l’identity con l’utente amministrativo ExAdmin;
Trascinare la type library del filtro di BE ("Storage Filter Sync.tlb") contenuta
all’interno della cartella D:\PostaCertificata\BE sotto il package
Registrare il filtro di BE sotto Exchange, utilizzando come autenticazione l’account
amministrativo ExAdmin e verificando che le risorse di cluster siano attive sul nodo corrente :
Installare l’Exchange SDK Tools di June 2002 (contenuto nel Kit)
Lanciare l’Exchange Explorer ed effettuare il browse dello store alla URL della
System mailbox: http://localhost/Exchange/SystemMailbox{}/. ( Il
nome esteso della SystemMailbox può essere ottenuto da Microsoft Exchange
System Obejcts di Active Directory Users And Computers dopo avere abilitato le
Advanced Features ).
Espandere i GlobalEvents degli StoreEvents e aggiungere una Event Registration
sotto gli Items, seguendo il Wizard.. Chiamarla con un nome a piacere;
selezionare l’evento sincrono sull’OnSyncSave; settare scope Any; e selezionare
130

come COM+ event sync “Storage_Filter_Sync.CSink”.
Registrare il servizio di archiviazione delle email virate sotto COM+:
Creare un package COM+ di tipo server chiamato "Posta Certificata Helper BDS"
Settarne l’identity con l’utente amministrativo ExAdmin;
Disabilitare la voce “Enforce access checks….”;
Trascinare la type library del filtro di BE ("ServicesPECBackEndStorageBds.tlb")
contenuta all’interno della cartella
D:\PostaCertificata\ ServicesPECBackEndStorageBds sotto il package
Dalla cartella D:\PostaCertificata\PerfCountSetup, eseguire il comando PERFCOUNTSETUP /Cb
(è possibile ottenerle un help del comando chiamandolo senza parametri)
Istallare nella GAC i file: EMCConfig.dll, Interop.ADODB.dll, Interop.CDO.dll, utility.dll
Effettuare un restart dell’Internet Information Server con IISRESET –STOP seguito da un
IISRESET – START o in alternativa un restart del server FE.
1.10.5.2. Exchange FrontEnd
Copiarsi il file Zip sotto il disco locale(a seconda dei dischi fisici presenti, se possibile D)
PostaCertificataFE e scompattarlo; verrà creata la cartella D:\PostaCertificata e le sotto
cartelle :
o
o
o
o
o
o
o
o
o
D:\PostaCertificata\FE
D:\PostaCertificata\Message-ID
D:\PostaCertificata\Components
D:\PostaCertificata\TraceLog
D:\PostaCertificata\Config
D:\PostaCertificata\SMTPVerify
D:\PostaCertificata\PerfCountSetup
D:\ PostaCertificata\BackupBDS
D:\ PostaCertificata\CertificateDomains
131

o
o
o
D:\ PostaCertificata\PecAntivirus
D:\ PostaCertificata\ServicePECBackEndStorageBds
…
Verificare che le path indicate nel file setvars.cmd siano corrette in relazione all’istallazione
Modificare il file batch regsink.bat nella cartella D:\PostaCertificata\SMTPVerify\Register
sostituendo al “valore” /add 1 il numero della istanza di SMTP di tipo Anonymous Virtual
Server del FE, se differente.
Modificare il file batch regsink.bat nella cartella D:\PostaCertificata\Message-ID\Register
sostituendo al “valore” /add 2 il numero della istanza di SMTP di tipo Authenticated Virtual
Server del FE, se differente.
Lanciare il file RegisterAll.cmd2
Registrare il proxy di salvataggio Email virate sotto COM+:
Tasto destro del mouse su COM+ Application
Attivare New\Application
Selezionare il file proxy.MSI
Effettuare un restart di IIS con IISRESET /STOP seguito da un IISRESET /START.
2 Il file RegisterAll.cmd, presente nella root del package, differisce tra Front-End e Back-End. Devono
essere, quindi, modificati tutti i riferimenti relativi alle directory d’installazione, rispettivamente, di:
Sistema Operativo, Applicativo PEC o Exchange, se essi non risultano secondo standard e quindi
sotto:
- C:\Win2k3 (Sistema operativo)
- D:\Exchsrvr (Exchange 2003)
- D:\Posta certificata (applicativo PEC)
…e qualsivoglia altro prodotto investito per il corretto funzionamento dell’ambiente.
132

Per completezza si descrivono nel seguito le azioni effettuate dal file di comandi RegisterAll.cmd
come se si dovessero effettuare manualmente
Registrare il filtro in interop lanciando lo script regasm.cmd da dentro la cartella
D:\PostaCertificata\FE\Bin
Effettuare la registrazione della EMCsign.dll contenuta nella cartella
D:\PostaCertificata\Components con il comando REGSVR32 EMCSIGN.DLL
Lanciare i batch “registerVSC1.bat” e “registerVSC2.bat” contenuti nella cartella
D:\PostaCertificata\FE\Register; questi registrano i filtri della posta certificata sui servizi SMTP
anonynous e authenticated.
Effettuare la registrazione della SMTPVerify.dll contenuta nella cartella
D:\PostaCertificata\SMTPVerify con la riga di comando regsvr32 SMTPVerify.dll
Modificare il file batch regsink.bat nella cartella D:\PostaCertificata\SMTPVerify\Register
sostituendo al “valore” /add 1 il numero della istanza di SMTP di tipo Anonymous Virtual
Server del FE (tale valore dovrebbe essere = 2 o viceversa).
Lanciare il batch regsink.bat per registrare il filtro della verifica della firma per le mail
certificate provenienti dall’esterno sull’Anon. SMTP, tutto ciò dalla cartella
D:\PostaCertificata\SMTPVerify\Register
Effettuare la registrazione della SMTPsink.dll contenuta nella cartella
D:\PostaCertificata\Message-ID con la riga di comando regsvr32 SMTPsink.dll
Modificare il file batch regsink.bat nella cartella D:\PostaCertificata\Message-ID\Register
sostituendo al “valore” /add 2 il numero della istanza di SMTP di tipo Authenticated Virtual
Server del FE (tale valore dovrebbe essere = 1 o viceversa).
133

Lanciare il batch regsink.bat per registrare il filtro del cambio del messageID sull Authenticated
SMTP, tutto ciò dalla cartella D:\PostaCertificata\Message-ID\Register
Dalla cartella D:\PostaCertificata\PerfCountSetup, eseguire il comando PERFCOUNTSETUP /Cf
(è possibile ottenerle un help del comando eseguendolo senza parametri)
Istallare nella GAC i file: EMCConfig.dll, Interop.ADODB.dll, Interop.CDO.dll, utility.dll
Effettuare un restart dell’Internet Information Server con IISRESET –STOP seguito da un
IISRESET – START o in alternativa un restart del server FE.
1.10.6. Database SQL
Fare il restore del Database di Log della Posta Certificata (la sua connection string è inserita in
tutte le copie del EMCConfig.xml)
Verificare che il PathTarget dell’IDEntity 0 della tabella “Tabcfgreport” sia corretto
Configurare l’agent per la visualizzazione dei report:
Copiare CertifiedMailAgent.exe in un a cartella a piacere di un server a piacere.
Lanciarlo con l’opzione “-setup” per configurarlo
Creare uno shortcut con l’opzione “-viewer” per l’automatica apertura del file file di log
in formato testo
1.10.7. Patch per PEC
Per far funzionare correttamente la WEBmail di OWA con la Posta Certificata, è stato necessario
far sviluppare una patch dai gruppi di sviluppo prodotto di Exchange2000. Ciò è dovuto al fatto
che il client OWA di Exchange2000 non è un client S/MIME compatibile. La patch permette al client
OWA di aggirare la limitazione. La patch è identificata dal supporto Microsoft come
Exchange 2003 Hotfix (SP1) KB872822
(sui Server di Back-End, per risolvere il problema dello stacco del Filtro SMTP in caso di
Failover in una configurazione attiva/passive del cluster Exchange)
Patch OWA di Exchange 2003 KB883543
(su tutti i Server di Front-End e Back-End, per risolvere il problema della visualizzazione
dell’Outlook Web Access correttamente)
134

Patch OWA per S-MIME di Exchange 2003 KB831464
(su tutti i Server di Front-End e Back-End, per risolvere il problema della visualizzazione del
plug-in per l’invio rie mail firmate e crittografate)
135

5.4. Bibliografia
[1] Microsoft Virtual Server 2005 - Panoramica tecnica
http://www.microsoft.com/italy/windowsserversystem/virtualserver/overview/vs2005tech.
mspx
[2] Microsoft Operations Framework (MOF)
http://www.microsoft.com/italy/technet/itsolutions/mo/mof/default.mspx
[3] Microsoft Solutions Framework
http://www.microsoft.com/technet/itsolutions/msf/default.mspx
[4] Sito Web di Poste Italiane
http://www.posteitaliane.it
[5] Regole tecniche per la formazione, la trasmissione e la validazione della PEC
http://www.cnipa.gov.it/site/_files/DECRETO%202%20novembre%202005.pdf
[6] Le modalità di accreditamento nell'elenco pubblico dei gestori (Circolare Cnipa 49/2005)
http://www.cnipa.gov.it/site/_files/Circolare%20CR_49.pdf
[7] Modello a spirale
http://it.wikipedia.org/wiki/Modello_a_spirale
Articoli ONLINE
Request For Comments
RFC 821 - Simple Mail Transfer Protocol (SMTP), J. Postel
RFC 1847 - Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted , J. Galvin, S.
RFC 1891 - SMTP Service Extension for Delivery Status Notifications, K. Moore, P. Murphy, S.
Crocker, N. Freed
RFC 1912 - Common DNS Operational and Configuration Errors D. Barr
RFC 2045 - Multipurpose Internet Mail Extensions (MIME) - Part 1, N. Freed, N. Borenstein
RFC 2046 - Multipurpose Internet Mail Extensions (MIME) - Part 2, N. Freed, N. Borenstein
RFC 2047 - Multipurpose Internet Mail Extensions (MIME) - Part 3, N. Freed, N. Borenstein
RFC 2048 - Multipurpose Internet Mail Extensions (MIME) - Part 4, N. Freed, N. Borenstein
RFC 2049 - Multipurpose Internet Mail Extensions (MIME) - Part 5, N. Freed, N. Borenstein
RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels, S. Bradner
RFC 2252 - Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, M. Wahl, A.
Coulbeck, T. Howes, S. Kille
136

RFC 2633 - S/MIME Version 3 Message Specification, B. Ramsdell
RFC 2821 - Simple Mail Transfer Protocol, J. Klensin
RFC 2822 - Internet Message Format, P. Resnick
RFC 2849 - The LDAP Data Interchange Format (LDIF) - Technical Specification, G. Good
RFC 3174 - US Secure Hash Algorithm 1 (SHA1) D. Eastlake 3rd, P. Jones
RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security, P. Hoffman
RFC 3280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile, R. Housley, W. Polk, W. Ford, D. Solo
RFC 3850 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate
Handling, B. Ramsdell
Risorse Microsoft
Installing Windows Server 2003 as a Domain Controller
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory
/activedirectory/stepbystep/domcntrl.mspx
Installing a Windows XP Professional Workstation and Connecting It to a Domain
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory
/activedirectory/stepbystep/domxppro.mspx
Setting Up Additional Domain Controllers
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory
/activedirectory/stepbystep/addomcon.mspx
Managing Active Directory
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory
/activedirectory/stepbystep/admng.mspx
Understanding the Group Policy Feature Set
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory
/activedirectory/stepbystep/gpfeat.mspx
Using the Group Policy Management Console
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory
/activedirectory/stepbystep/gpmcinad.mspx
137

Enforcing Strong Password Policies
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory
/activedirectory/stepbystep/strngpw.mspx
Digitally Signed and Encrypted E-Mail
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory
/activedirectory/stepbystep/ncrypte.mspx
Active Directory Sites and Services
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory
/activedirectory/stepbystep/adsrv.mspx
Change the account under which the Cluster service runs
6403f974657f1033.mspx?mfr=true
Configuring Exchange 2003 for Client Access
http://www.microsoft.com/technet/prodtechnol/exchange/Guides/Ex2k3DepGuide/0142e2
28-d939-4a3c-b718-fc1cca389fdd.mspx
Installing New Exchange 2003 Servers
http://www.microsoft.com/technet/prodtechnol/exchange/Guides/Ex2k3DepGuide/a3318f5
7-3536-4e65-9309-9300cda23c73.mspx
Exchange Server Deployment Guide
http://www.microsoft.com/technet/prodtechnol/exchange/Guides/Ex2k3DepGuide/fa02f08
7-7fe7-4eb7-b859-12632d762f9e.mspx
Implementing a Two Node Cluster with Windows 2003 Enterprise
http://technet2.microsoft.com/WindowsServer/en/library/ec513ba0-08a6-493b-889f-
http://www.msexchange.org/tutorials/Implementing-Two-Node-Cluster-Windows-2003-
Enterprise.html
Front-End and Back-End Server Topology Guide for Exchange Server 2003 and Exchange 2000
Server
138

http://www.microsoft.com/technet/prodtechnol/exchange/Guides/E2k3FrontBack/3beec46
b-188a-4067-9f1e-c9fe17e1cb9f.mspx?mfr=true
Exchange Server 2003 Technical Documentation Library
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/default.mspx
User Group Italiano Microsoft Exchange
http://www.ugimex.org/forum/default.asp?b=1
Configuring Exchange 2003 HTTP Remote Access
http://www.msexchange.org/tutorials/Configuring-Exchange2003-HTTP-Remote-
Access.html
Deploying Exchange Server 2003 in a Cluster
http://www.microsoft.com/technet/prodtechnol/exchange/Guides/Ex2k3DepGuide/9f5b91c
d-d7c2-409d-81a0-033a23e1faee.mspx?mfr=true
Using Microsoft Virtual Server 2005 to Create and Configure a Two-Node Microsoft Windows
Server 2003 Cluster
http://www.microsoft.com/technet/prodtechnol/virtualserver/deploy/cvs2005.mspx
A global event sink is not triggered after you restart the Microsoft Exchange Information Store
service in Exchange Server 2003 Service Pack 1
http://support.microsoft.com/?id=872822
Risorse CNIPA
Note integrative alle Regole tecniche della PEC
http://www.cnipa.gov.it/site/_files/Note%20integrative%20alle%20Regole%20Tecniche.pd
f
Risorse http://punto-informatico.it
La PA italiana si scopre digitale
http://punto-informatico.it/p.asp?id=1528458
La tecnologia? E' un diritto
139

http://punto-informatico.it/p.asp?id=1389040
Chi sono i certificatori della PEC?
http://punto-informatico.it/p.asp?id=1373120
Cassandra Crossing/ La privatizzazione del Tempo
http://punto-informatico.it/p.asp?id=1318397
Risorse http://www.interlex.it
Emendamenti in libertà: la baruffa sulla carta d'identità elettronica
http://www.interlex.it/docdigit/emendam1.htm
FAQ: Domande e risposte sulla firma digitale
http://www.interlex.it/docdigit/faq/faq36.htm
FAQ: Domande e risposte sulla firma digitale
http://www.interlex.it/docdigit/faq/faq45.htm
A. Chiloiro - La firma digitale da Bruxelles a Londra - 2
http://www.interlex.it/docdigit/chiloiro2.htm
Carta d'identità elettronica e archivi delle pubbliche amministrazioni. Il Garante chiede maggiori
garanzie per i cittadini
http://www.interlex.it/675/tutela/cie1.htm
Decreto del Presidente del Consiglio dei Ministri 22 ottobre 1999, n. 437
http://www.interlex.it/testi/dpc99437.htm
A. Monti - Posta certificata: luci, ombre ed effetti collaterali
http://www.interlex.it/docdigit/amonti77.htm
A. Monti - PEC, PIN, PUK, patatrac
http://www.interlex.it/docdigit/amonti82.htm
La firma "scannerizzata" non è una firma elettronica
http://www.interlex.it/docdigit/quesiti.htm
M. Cammarata - PEC: scrivere (e leggere) bene le norme...
http://www.interlex.it/docdigit/pec1.htm
InterLex - Firma digitale - INDICE
http://www.interlex.it/docdigit/indice.htm
C. Giurdanella - E. Guarnaccia - Amministrazione digitale
http://www.interlex.it/pa/giurguar4.htm
Firma digitale: tutto quello che dobbiamo sapere
http://www.interlex.it/seminari/genn2004/intro.htm
140

Risorse Cartacee
Mastering Microsoft Exchange Server 2003, Barry Gerber, Sybex
Exchange Server 2003 Advanced Administration, Jim McBee, Wiley
141