Posta certificata in arrivo

A pochi giorni dal varo della normativa che dà il via all'email certificata arrivano le prime soluzioni software dedicate. Rimane da vedere se la nuova email sarà la revolution descritta dal Governo

Roma - Secondo il Governo sarebbe una piccola ma importante rivoluzione il fatto che l'email possa con facilità essere certificata, e quindi equivalere a tutti gli effetti ad una comunicazione scritta come, per esempio, la raccomandata tradizionale. Non stupisce dunque che su questo mercato, aperto dal decreto del Presidente della Repubblica dello scorso 25 marzo, si stiano fiondando operatori e softwarehouse.

Per sfruttare la posta elettronica certificata, amministrazioni pubbliche o aziende devono avvalersi di un sistema in grado di registrare in maniera univoca il traffico dei messaggi in entrata e in uscita, di assicurare l'integrità e la riservatezza delle informazioni trasmesse e di attestare l'effettivo recapito del messaggio, come avviene con una raccomandata con ricevuta di ritorno con il servizio di posta tradizionale. Il sistema di posta elettronica firma con un proprio certificato la "busta digitale" che contiene il messaggio inviato, garantendo in questo modo al destinatario la perfetta integrità dei contenuti ricevuti, e invia al mittente in automatico, tramite server, una ricevuta di avvenuta consegna del messaggio non appena questo è stato recapitato.

Il CNIPA, l'agenzia governativa incaricata di dare il via libera alle imprese che intendono certificare l'email e fornire supporto allo sviluppo del nuovo ambiente, ha già pubblicato sul proprio sito una serie di materiali, come la lista dei client di posta elettronica che possono essere usati per l'invio e la ricezione dell'email certificata. Tra questi anche Mozilla, Opera, Eudora e Microsoft Outlook.
Proprio Microsoft nei giorni scorsi ha lanciato la propria soluzione per l'email certificata realizzata in collaborazione con EDS. Basata su Exchange 2003, è un ambiente rivolto ad enti e aziende e che comprende, ha spiegato, l'adozione di tecnologie di firma digitale per garantire l'identità del mittente e la confidenzialità della comunicazione.

Va detto, però, che sono molte le imprese, anche softwarehouse italiane, che stanno lavorando per proporre al mercato le proprie soluzioni. Aumentano, peraltro, anche il numero degli operatori di posta certificata che hanno superato i test previsti dal DPR per poter fornire i servizi relativi. La lista è disponibile su questa pagina, dove sono presenti anche i contatti delle imprese interessate. Da segnalare che non si tratta soltanto di imprese ma anche, come è ovvio vista la centralità dell'email certificata per la pubblica amministrazione, di enti locali, come la Regione Lazio o la Regione Campania.
TAG: italia
34 Commenti alla Notizia Posta certificata in arrivo
Ordina
  • ma cristo ... siamo su INTERNET mica in italietta, no? non è possibile usare un sistema internazionale interessare il w3c o quella gente li ... la comunità internazionale, le università e fare qualcosa che sia free , open, valido per tutti e supportato da tutto e tutti ?

    ma che schifo!!!!!!
    non+autenticato
  • No, non è possibile.
    Il fatto è che non si tratta di tecnologia. QUi si parla di leggi. La tecnologia è fuori da questa cosa.
    Tant'è che è stata implementata da diversi fornitori su diverse piattaforme, ma tutte in ottemperanza con la legge.
    E la legge dice che deve essere fatta usando SMTP e POP3/IMAP4, con dei workflow che si allacciano alle leggi nazionali.
    La PEC deve essere fatta in modo che un messaggio di PEC abbia valore legale davanti ad un giudice.
    La norma della PEC ha fatto un lungo giro di verifiche tra i legali, costituzionalisti e simili.

    Non c'è W3C e simili che possano scrivere cose di questo genere.

    Non siamo in italietta. Siamo in Italia. E Internet non è un logo, è uno strumento per mettere in comunicazione utenti, aziende, enti e amministrazioni ITALIANE.

    Ciao
    non+autenticato

  • - Scritto da: Anonimo


    > Non c'è W3C e simili che possano
    > scrivere cose di questo genere.

    non sono per nulla d'accordo.
    mettendo a confronto tutti gli stati per la medesima esigenza (che è una sola!) e i tecnici di tutti gli stati sempre per la medesima risposta (una sola!) si può fare eccome, imho

    > Non siamo in italietta. Siamo in Italia.

    l'italietta è sita in Italia, questo è vero.

    > E
    > Internet non è un logo

    mai detto.
    però è un "luogo" , virtuale, un mezzo, è vero, ma è anche un luogo. In questo luogo tutti si affacciano, non solo l'Italia e allora perchè non aprirsi SUBITO ad uno standard comune per rispondere ad una esigenza che è poi quella della ricevuta di ritorno assicurata?

    >, è uno
    > strumento per mettere in comunicazione
    > utenti, aziende, enti e amministrazioni
    > ITALIANE.

    ah adesso internet è italiano (rileggi il tuo messaggio, io l'ho fatto più volte)
    non+autenticato
  • > ma cristo ... siamo su INTERNET mica in
    > italietta, no? non è possibile usare
    > un sistema internazionale interessare il w3c
    > o quella gente li ... la comunità
    > internazionale, le università e fare
    > qualcosa che sia free , open, valido per
    > tutti e supportato da tutto e tutti ?

    Vuoi uno standard? Scrivi una RFC!
    Per ora, nessuno lo sta facendo; ma, visto che è già previsto dalla normativa di uno stato europeo, non ci vuole molto a tradurre il regolamento della P.A. in un documento di IETF.

    > ma che schifo!!!!!!

    .. e se invece di protestare ti mettessi ad organizzare la cosa? Internet è stata fatta dai volenterosi, su base volontaria. Non da i critici per partito preso ...
    non+autenticato
  • Una piccola precisazione a quanto scritto nell'articolo.
    La lista dei client segnalata è quella che la RUPA ha testato, non quelli "autorizzati".
    La normativa prevede che possa essere utilizzato qualsiasi client POP3/SMTP/IMAP4/HTTP in grado di gestire SSL e S/MIME. In pratica tutti i client.
    Quindi anche un client "home made" va bene, purchè rispetti le specifiche sopra descritte.

    Ovviamente la lista dei client è stata fatta per il maggior numero di informazioni ai possibili utilizzatori, ma non è omnicomprensiva Sorride

    Ciao,
    Corrado
    non+autenticato

  • - Scritto da: Anonimo
    > Una piccola precisazione a quanto scritto
    > nell'articolo.
    > La lista dei client segnalata è
    > quella che la RUPA ha testato, non quelli
    > "autorizzati".
    > La normativa prevede che possa essere
    > utilizzato qualsiasi client
    > POP3/SMTP/IMAP4/HTTP in grado di gestire SSL
    > e S/MIME. In pratica tutti i client.
    > Quindi anche un client "home made" va bene,
    > purchè rispetti le specifiche sopra
    > descritte.
    >
    > Ovviamente la lista dei client è
    > stata fatta per il maggior numero di
    > informazioni ai possibili utilizzatori, ma
    > non è omnicomprensivaSorride

    quindi the bat e dialog a posto?
    non+autenticato
  • diciamo che la RUPA ha testato quei client con la SUA implementazione, non con quella degli altri gestori.. quindi la lista non vuol dire niente. Certi client che non sono per esempio in grado di parlare bene TLS/SSL (come Opera) per colpa di bug/mancanze varie, potrebbero non funzionare con certi gestori.
    non+autenticato
  • Per quale assurdo motivo anziche' utilizzare del software gia' disponibile e ben collaudato (leggasi PGP e le sue varianti opensource), ci si debba complicare la vita alla ricerca di nuove soluzioni, rigorosamente proprietarie?
    non+autenticato
  • Perchè esistono delle leggi dello stato che richiedono certi flussi.
    Ecco perchè.
    Lo stato non è fatto solo di nerd tecnologici...
    non+autenticato
  • perchè succederebbe un casino inimmaginabile se ognuno usasse le proprie chiavi pubbliche e private... e inoltre, come potrebbe tornare indietro la ricevuta che il messaggio è arrivato se non c'è qualche server APPOSITO che la prepara? questo non lo puoi ottenere al momento solo con PGP e simili.
    non+autenticato

  • - Scritto da: Anonimo
    > perchè succederebbe un casino
    > inimmaginabile se ognuno usasse le proprie
    > chiavi pubbliche e private... e inoltre,
    > come potrebbe tornare indietro la ricevuta
    > che il messaggio è arrivato se non
    > c'è qualche server APPOSITO che la
    > prepara? questo non lo puoi ottenere al
    > momento solo con PGP e simili.


    sarebbe stato comunque meglio affidare alla comunità TECNOLOGICA - INTERNAZIONALE un simile compito e se si vuol dare il merito all'italia di aver fatto pressioni ben venga, ma non facciamo il nostro orticello ... meglio il campo di tutta la terra ... valido per tutti, con migliaia di server a disposizione in tutto il mondo e uno standard aperto, libero, comune a tutto il globo e valido per tutto e tutti per sempre
    non+autenticato

  • - Scritto da: Anonimo
    > Perchè esistono delle leggi dello
    > stato che richiedono certi flussi.
    > Ecco perchè.
    > Lo stato non è fatto solo di nerd
    > tecnologici...

    ed è per questo che degli incompetenti hanno l'arroganza di inserirsi in un ambiente che invece è FATTO dai nerd tecnologici che capiscono l'ambiente che hanno creato meglio di chi sta per generare solo casini burocratici.

    non+autenticato
  • > Per quale assurdo motivo anziche' utilizzare
    > del software gia' disponibile e ben
    > collaudato (leggasi PGP e le sue varianti
    > opensource),

    Il software di cui parli non garantisce la consegna: PGP serve a garantire il contenuto del messaggio, ma non che questo sia arrivato a destinazione.

    >                        ci si debba complicare la vita
    > alla ricerca di nuove soluzioni,
    > rigorosamente proprietarie?

    Non è vero che le soluzioni debbano essere rigorosamente proprietarie: lo Stato Italiano ha deciso i criteri che un mail server deve soddisfare per poter inviare una "Raccomandata A.R." via posta elettronica, soluzione che prima non esisteva.

    [E, tra l'altro, uno dei prodotti che aspira alla certificazione è OpenPEC (www.openpec.org) che "vuole essere il primo sistema completamente OpenSource compatibile con le specifiche tecniche emesse e certificato dal Centro Tecnico per la RUPA"]

  • - Scritto da: tullio
    >
    > Il software di cui parli non garantisce la
    > consegna: PGP serve a garantire il contenuto
    > del messaggio, ma non che questo sia
    > arrivato a destinazione.

    Vero, a questo non avevo pensato in effetti. E' pur vero che e' adattabile a questa necessita', ma se c'e' da metterci le mani diventa un prodotto come gli altri...


    > Non è vero che le soluzioni debbano
    > essere rigorosamente proprietarie: lo Stato
    > Italiano ha deciso i criteri che un mail
    > server deve soddisfare per poter inviare una
    > "Raccomandata A.R." via posta elettronica,
    > soluzione che prima non esisteva.

    Quindi se non ho capito male parte del processo coinvolge anche il mail server?

    >
    > [E, tra l'altro, uno dei prodotti che aspira
    > alla certificazione è OpenPEC
    > (www.openpec.org) che "vuole essere il primo
    > sistema completamente OpenSource compatibile
    > con le specifiche tecniche emesse e
    > certificato dal Centro Tecnico per la RUPA"]

    Questo anche non lo sapevo, ed e' una notizia che mi rende felice. Poter contare su un prodotto open source e' importante secondo me, poiche' permette a chiunque di avvalersi di certe tecnologie a costo 0, com'e', IMHO, giusto che sia.

    Saluti,
    Simone.
    non+autenticato
  • > Quindi se non ho capito male parte del
    > processo coinvolge anche il mail server?


    Ovviamente non può non essere così.

    > > alla certificazione è OpenPEC
    > > (www.openpec.org) che "vuole essere il
    > primo
    > > sistema completamente OpenSource
    > compatibile
    > > con le specifiche tecniche emesse e
    > > certificato dal Centro Tecnico per la
    > RUPA"]


    Peccato che sono ancora in altissimo mare... Sorride

    non+autenticato

  • - Scritto da: Anonimo


    > > compatibile
    > > > con le specifiche tecniche emesse e
    > > > certificato dal Centro Tecnico per
    > la
    > > RUPA"]
    >
    >
    > Peccato che sono ancora in altissimo mare...
    >Sorride
    >

    peccato soprattutto che non ne si faccia una cosa internazionale!
    non+autenticato

  • - Scritto da: tullio

    .
    >
    > [E, tra l'altro, uno dei prodotti che aspira
    > alla certificazione è OpenPEC
    > (www.openpec.org) che "vuole essere il primo
    > sistema completamente OpenSource compatibile
    > con le specifiche tecniche emesse e
    > certificato dal Centro Tecnico per la RUPA"]


    fiuuuuuuuuu :-°
    non+autenticato

  • - Scritto da: Anonimo
    > Per quale assurdo motivo anziche' utilizzare
    > del software gia' disponibile e ben
    > collaudato (leggasi PGP e le sue varianti
    > opensource), ci si debba complicare la vita
    > alla ricerca di nuove soluzioni,
    > rigorosamente proprietarie?

    eeeeeeesatto.
    non+autenticato
  • So che la crittografia a chiave pubblica garantisce tutte queste cose (Non ripudiazione, Non Alterazione, etc).
    Per fare cio' pero' gli individui si devono dotare di una "coppia di chiavi" nota al grande pubblico come Firma Digitale.
    Senza questa, un mittente puo' rinnegare la paternita' di un messaggio e un ricevente quella della conferma di ricezione.
    Quindi tecnicamente e' facile implementare un sistema di posta garantita. L'ostacolo e' la capillare diffusione di firme digitali alla popolazione.
    Mi chiedo dunque in cosa consistono queste "soluzioni" proposte da questi fornitori? Qualcuno ne ha visto qualcuno in funzione?

    non+autenticato
  • Si, io ne ho viste un paio in funzione: in pratica le soluzioni delle aziende permettono di non distribuire per ogni persona una coppia di chiavi pubblica/privata (visto che molte persone non sanno cosa significa), in pratica ogni gestore diventa l'unico responsabile di tenere traccia delle email spedite e delle ricevute e di firmare i messaggi e le ricevute
    non+autenticato
  • > So che la crittografia a chiave pubblica
    > garantisce tutte queste cose (Non
    > ripudiazione, Non Alterazione, etc).

    Non è questo il problema che si vuole affrontare.
    Il problema che l'e-mail sia riservata e non sia falsificabile è già risolto da i sistemi di firma digitale; ma quello che mancava ancora è LA GARANZIA DI CONSEGNA, quella che la raccomandata A.R. offre e l'e-mail tradizionale no.

    Se invio un'e-mail firmata digitalmente, posso garantirmi che il destinatario sappia che l'ho scritta davvero io, e anche che la potrà leggere solo lui: ma non posso garantirmi che l'abbia ricevuta! Con la P.E.C., invece, i server interessati alla trasmissione mi faranno avere una sorta di "ricevuta di ritorno" che mi farà capire che la posta è arrivata a destinazione - e se non la ricevo, che può essere andata perduta.

    non+autenticato

  • - Scritto da: Anonimo
    > > So che la crittografia a chiave pubblica
    > > garantisce tutte queste cose (Non
    > > ripudiazione, Non Alterazione, etc).
    >
    > Non è questo il problema che si vuole
    > affrontare.
    > Il problema che l'e-mail sia riservata e non
    > sia falsificabile è già
    > risolto da i sistemi di firma digitale; ma
    > quello che mancava ancora è LA
    > GARANZIA DI CONSEGNA, quella che la
    > raccomandata A.R. offre e l'e-mail
    > tradizionale no.

    consegna AL SERVER o download del destinatario e lettura?
    ad esempio se io ricevo delle mail che il mio antispam considera da cencellare, io non le riceverò mai.


    non+autenticato
  • > consegna AL SERVER o download del
    > destinatario e lettura?
    > ad esempio se io ricevo delle mail che il
    > mio antispam considera da cencellare, io non
    > le riceverò mai.

    Consegna nella tua "buca delle lettere".

    Anche le raccomandate "di carta", se il portinaio le ritira, firma e poi non te le consegna, tu non le leggi. Come non le leggi se le butti via senza aprirle. Ma poi non ti lamentare se l'ufficiale giudiziario è venuto a pignorarti il televisore nuovo, quando non eri in casa ...

    P.S.: se il tuo filtro antispam considera da cancellare una e-mail certificata arrivata in una casella postale certificata, cambialo!
    non+autenticato
  • Situazione 1
    A possiede una casella di posta certificata ed un client adatto
    B ha una normale e-mail

    Situazione 2
    A e B possiedono una casella di posta certificata ed un client adatto

    Non ho sinceramente capito se la posta certificata si possa utilizzare nella situazione 1 o se sia necessaria la situazione 2

    Grazie
    non+autenticato
  • Perchè l'intero flusso sia legalmente valido, è necessario che entrambe le caselle siano di Posta Certificata.
    Le soluzioni dovrebbero (quella Microsoft lo è) essere client-indipendent.
    Un client generico deve essere SMTP/POP3 e in grado di gestire S/MIME.

    Ciao,
    Corrado
    non+autenticato

  • - Scritto da: Anonimo
    > Perchè l'intero flusso sia legalmente
    > valido, è necessario che entrambe le
    > caselle siano di Posta Certificata.
    > Le soluzioni dovrebbero (quella Microsoft lo
    > è) essere client-indipendent.
    > Un client generico deve essere SMTP/POP3 e
    > in grado di gestire S/MIME.

    che è s/mime ? quello che porta i virus o non c'entra nulla?

    scusate ma ... ho sempre pensato al plaintext come il Giusto.
    non+autenticato
  • si è possibile: A invierà un'email a B, e A riceverà dal proprio server la conferma che il messaggio è stato inviato. Il messaggio di posta certificata verrà firmato digitalmente e mandato al destinatario B, il quale lo riceverà normalmente. La differenza è che A non riceverà la ricevuta di avvenuta consegna, in quando B non è un destinatario di posta certificata: in pratica A non avrà la certezza che il messaggio sia arrivato a B, e quindi non ci sarà la valenza legale. In questo caso l'unico vantaggio è che comunque B riceverà un messaggio firmato digitalmente, la cui firma è verificata dal client stesso che lui usa (se il suo client capisce l'S/MIME come tutti i principali).

    Spero di aver chiarito il tuo dubbio!
    non+autenticato

  • - Scritto da: Anonimo
    >
    > verificata dal client stesso che lui usa (se
    > il suo client capisce l'S/MIME come tutti i
    > principali).
    >
    > Spero di aver chiarito il tuo dubbio!

    io ho il dubbio di cosa sia s/mime ! Triste
    non+autenticato

  • - Scritto da: Anonimo

    > io ho il dubbio di cosa sia s/mime !Triste

    A grandi linee e' il sistema che permette di far passare file binari sui canali della posta elettronica che, per come sono nati, prevedono il passaggio di dati su 6 bit.
    Sfruttando s/mime anche una bitmap, un filmato o anche un virus vengono codificati a 6 bit per essere trasmessi. Il client che li riceve, se supporta s/mime, li riporta a 8 bit quindi al formato originale.

    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    >
    > > io ho il dubbio di cosa sia s/mime !Triste
    >
    > A grandi linee e' il sistema che permette di
    > far passare file binari sui canali della
    > posta elettronica che, per come sono nati,
    > prevedono il passaggio di dati su 6 bit.
    > Sfruttando s/mime anche una bitmap, un
    > filmato o anche un virus vengono codificati
    > a 6 bit per essere trasmessi. Il client che
    > li riceve, se supporta s/mime, li riporta a
    > 8 bit quindi al formato originale.


    in sostanza tutti i client che supportano l'attachment, giusto?

    non+autenticato

  • - Scritto da: Anonimo
    [CUT]
    > io ho il dubbio di cosa sia s/mime !Triste
    S/MIME (Secure/Multipurpose Internet Mail Extensions) (RFC 2633) è lo standard IETF per cifrare e firmare la e-mail; utilizza i certificati X.509, a differenza di PGP che si basa su un sistema di garanzie "a catena".
    non+autenticato
  • Per usufruire delle peculiarità della P.E.C. è necessario che entrambi gli account appartengano a domini certificati.

    Vediamo cosa accade nella situazione 1, ad es. nel caso in cui l'utente B mandi una mail all'utente A: il sistema di posta certificata dell'utente A non riconoscerà la mail proveniente dall'utente B come proveniente da un dominio certificato; la mail sarà consegnata all'utente A, ma con un messaggio di errore (anomalia di trasporto) che evidenzia che il mittente non è certificato.


    - Scritto da: Anonimo
    > Situazione 1
    > A possiede una casella di posta certificata
    > ed un client adatto
    > B ha una normale e-mail
    >
    > Situazione 2
    > A e B possiedono una casella di posta
    > certificata ed un client adatto
    >
    > Non ho sinceramente capito se la posta
    > certificata si possa utilizzare nella
    > situazione 1 o se sia necessaria la
    > situazione 2
    >
    > Grazie
    non+autenticato

  • - Scritto da: Anonimo
    > Per usufruire delle peculiarità della
    > P.E.C. è necessario che entrambi gli
    > account appartengano a domini certificati.


    il che significa?
    che una terza parte ne garantisce l'identità, come con SSL ?
    corretto?

    ciao!
    non+autenticato