RFC 6109: dentro la PEC

Nel panorama delle comunicazioni digitali italiane, la Posta Elettronica Certificata (PEC) è diventata uno strumento chiave per dare valore legale alle e‑mail. Il documento che ne formalizza l’architettura e i protocolli è l’RFC 6109, pubblicato nell’aprile 2011.

Un RFC (Request for Comments) è un documento tecnico ufficiale dell’IETF. Alcuni RFC descrivono semplici linee guida, altri definiscono protocolli fondamentali (come TCP/IP, HTTP, DNS). Gli RFC sono numerati, consultabili pubblicamente e, a seconda della categoria (Standard Track, Informational, Experimental), hanno peso diverso nell’ecosistema Internet. La principale differenza tra email e PEC è che l’email è regolata da RFC standardizzati a livello globale, mentre la PEC è una variante italiana “certificata”, definita da normativa nazionale e documentata in un RFC informativo (RFC 6109), senza valenza di standard internazionale.

Panoramica di RFC 6109

  • Titolo: Certified Electronic Mail
  • Categoria: Informational
  • Autori: Claudio Petrucci (DigitPA), Francesco Gennai, Alba Shahin (ISTI‑CNR), Alessandro Vinciarelli (DigitPA)
  • Data: aprile 2011 (rfc-editor.org)
  • Obiettivo: descrivere in inglese le “Regole tecniche” italiane per la PEC (D.M. 2 novembre 2005), fornendo un’integrazione architetturale e protocollare per implementazioni interoperabili.

Perché è nato RFC 6109?

Dal 2005 l’Italia aveva già una normativa (DPR 68/2005 e D.M. 2 novembre 2005) che definiva la PEC a livello nazionale. Tuttavia, per favorire interoperabilità e adozione anche al di fuori di ambienti puramente “statali”, era utile una documentazione tecnica internazionale, messa a disposizione dall’IETF, che illustrasse:

  1. Architettura complessiva: punti di accesso, punti d’ingresso, storage e delivery (rfc-editor.org)
  2. Tipi di messaggi: notifiche di accettazione, consegna, scarto per virus o timeout
  3. Formato: envelope MIME, certificazione dati, LDAP directory dei provider
  4. Aspetti di sicurezza: firma digitale server‑side, autenticazione TLS, gestione certificati S/MIME

Contenuti Chiave di RFC 6109

SezioneDescrizione
2. PEC ModelModello concettuale: Access Point, Incoming Point, Delivery Point, Storage, Log (rfc-editor.org)
3. Message ProcessingFlussi di elaborazione: controlli formali, notifiche di errori, virus, accettazione e consegna
4. FormatsStruttura del body PEC: testo utente, messaggio originale, dati di certificazione
5. Security-RelatedFirma digitale (CMS/S/MIME), autenticazione server‑to‑server, requisiti TLS
8. IANA ConsiderationsRegistrazione di header PEC proprietari (X-Ricevuta, X-VerificaSicurezza, ecc.)

Il “Vantaggio” PEC

A differenza di un sistema di critografia end‑to‑end (che richiede chiavi e competenze per ogni utente), la PEC:

  • Firma i messaggi a server (semplificando il client)
  • Garantisce non‑ripudio e tracciatura legale, con notifiche certificate
  • Utilizza SMTP/TLS obbligatorio e standard S/MIME (RFC 5751) per payload firmati (rfc-editor.org)

TL;DR

  • RFC 6109 traduce in inglese e arricchisce di dettagli tecnici le “Regole tecniche” italiane per la PEC.
  • Descrive architettura, flussi di messaggio, formati e sicurezza.
  • Fondamentale per chi implementa o integra servizi PEC (provider, software house, sysadmin).

Parole chiave SEO consigliate

RFC 6109 PEC spiegazione
Posta Elettronica Certificata RFC
architettura PEC modello access point
formato messaggio PEC RFC6109
sicurezza PEC TLS S/MIME
introdurre RFC 6109

Esempi di header PEC (X-Ricevuta, X-Trasporto…)

Certo! Gli header della Posta Elettronica Certificata (PEC) sono fondamentali per distinguere i messaggi certificati e per garantire la tracciabilità delle comunicazioni. L’RFC 6109 e le “Regole tecniche” italiane specificano una serie di intestazioni (header) custom utilizzate nelle ricevute PEC. Qui sotto trovi una panoramica con esempi reali.

Esempi di header PEC

Header PECDescrizione
X-RicevutaTipo di ricevuta (es. accettazione, avvenuta-consegna, errore)
X-TipoRicevutaSpecifica di ricevuta (completa, breve, sintetica)
X-TrasportoMezzo di trasporto (posta-certificata)
X-VerificaSicurezzaStato dei controlli di sicurezza (es. ok)
X-TipoMessaggioTipo di messaggio (posta-certificata, errore-consegna, notifica-smime)
X-ErroreConsegnaCodice e descrizione errore (se presente)
X-Riferimento-Message-IDMessage-ID del messaggio originale

Esempio 1: Ricevuta di accettazione

X-Ricevuta: accettazione
X-TipoRicevuta: completa
X-Trasporto: posta-certificata
X-VerificaSicurezza: ok
X-TipoMessaggio: posta-certificata
X-Riferimento-Message-ID: <abc123@example.it>

Cosa significa:
Il messaggio è una ricevuta di accettazione generata dal provider PEC mittente. Il messaggio originale è stato formalmente preso in carico.

Esempio 2: Avvenuta consegna

X-Ricevuta: avvenuta-consegna
X-TipoRicevuta: completa
X-Trasporto: posta-certificata
X-VerificaSicurezza: ok
X-TipoMessaggio: posta-certificata
X-Riferimento-Message-ID: <abc123@example.it>

Cosa significa:
Il messaggio originale è stato consegnato con successo al provider del destinatario.

Esempio 3: Errore di consegna

X-Ricevuta: errore
X-TipoRicevuta: sintetica
X-Trasporto: posta-certificata
X-VerificaSicurezza: ok
X-TipoMessaggio: errore-consegna
X-ErroreConsegna: 550 Utente inesistente
X-Riferimento-Message-ID: <abc123@example.it>

Cosa significa:
Il messaggio non è stato consegnato, per esempio perché l’indirizzo PEC di destinazione non esiste o non è attivo. L’errore è indicato esplicitamente.

✉️ A cosa servono questi header?

  • Permettono di distinguere le varie fasi del ciclo di vita del messaggio PEC
  • Sono fondamentali per la ricostruzione forense o legale in caso di contestazioni
  • Possono essere parsati da software di archiviazione o da log parser per audit

Bonus: Parsing con Python

from email import message_from_string

raw_msg = open("ricevuta.eml").read()
msg = message_from_string(raw_msg)

print("Tipo di ricevuta:", msg["X-Ricevuta"])
print("Errore:", msg.get("X-ErroreConsegna", "Nessun errore"))

Parsing LDAP per la Directory dei Provider PEC

Ecco una sezione “how‑to” dedicata al parsing LDAP per recuperare le informazioni sui provider PEC da una directory LDAP, secondo quanto previsto dall’RFC 6109.

Le Regole tecniche PEC (D.M. 2 novembre 2005) prevedono che ogni provider PEC metta a disposizione una directory LDAP pubblica contenente i metadati sui propri Access Point, Incoming Point e Delivery Point. Grazie a questo meccanismo, un client o un gateway PEC può:

  1. Scoprire dinamicamente gli endpoint SMTP/TLS da contattare
  2. Verificare i certificati S/MIME del server
  3. Applicare politiche di retry e fallback secondo i tempi definiti

1. Struttura di base della Directory

Una directory tipica ha un base DN simile a:

dc=pec,dc=provider,dc=it

All’interno troviamo entry per ciascun ruolo:

  • cn=AccessPoint,dc=pec,dc=provider,dc=it
  • cn=IncomingPoint,dc=pec,dc=provider,dc=it
  • cn=DeliveryPoint,dc=pec,dc=provider,dc=it

Ogni entry ha attributi come:

AttributoDescrizione
objectClasspkiUser, pkiCA, pecService
pecSmtpHosthostname SMTP es. smtp.pec.provider.it
pecSmtpPortporta (normalmente 25 o 587)
pecTlsRequiredTRUE/FALSE
pecCertificatecertificato X.509 del server (base64 DER)
pecDeliveryTimeouttimeout in secondi per retry consegna

2. Query con ldapsearch

Un esempio di comando shell per recuperare i punti di Access:

ldapsearch -x -H ldap://ldap.pec.provider.it \
  -b "cn=AccessPoint,dc=pec,dc=provider,dc=it" \
  "(objectClass=pecService)" \
  pecSmtpHost pecSmtpPort pecTlsRequired pecCertificate
  • -x → autenticazione anonima
  • -H ldap://… → URI del server LDAP
  • -b … → base DN
  • Filtro: (objectClass=pecService)
  • Attributi richiesti: pecSmtpHost, pecSmtpPort, pecTlsRequired, pecCertificate

3. Script Python con ldap3

Per integrare il parsing in un client PEC, si può usare la libreria ldap3:

from ldap3 import Server, Connection, ALL, SUBTREE

# Configurazione server LDAP del provider
LDAP_URI = 'ldap://ldap.pec.provider.it'
BASE_DN = 'dc=pec,dc=provider,dc=it'
SERVICE_DN = 'cn=AccessPoint,' + BASE_DN

# Connessione anonima
server = Server(LDAP_URI, get_info=ALL)
conn = Connection(server, auto_bind=True)

# Ricerca delle entry pecService
conn.search(
    search_base=SERVICE_DN,
    search_filter='(objectClass=pecService)',
    search_scope=SUBTREE,
    attributes=[
        'pecSmtpHost',
        'pecSmtpPort',
        'pecTlsRequired',
        'pecCertificate'
    ]
)

# Parsing dei risultati
for entry in conn.entries:
    host = entry.pecSmtpHost.value
    port = int(entry.pecSmtpPort.value)
    tls = entry.pecTlsRequired.value == 'TRUE'
    cert_pem = entry.pecCertificate.value  # base64 DER

    print(f"→ Host: {host}")
    print(f"  Port: {port} (TLS required: {tls})")
    print(f"  Cert:\n{cert_pem}\n")

conn.unbind()

Spiegazione snippet

  • Server/Connection: connessione anonima al server LDAP.
  • search(): filtro su objectClass=pecService sotto il DN di AccessPoint.
  • entry.pecCertificate.value: recupera il certificato in formato base64 DER, che poi potrai convertire in PEM per verifiche con OpenSSL.

4. Validazione del Certificato

Il certificato X.509 recuperato va:

  1. Convertito in PEM:
    openssl base64 -d -in cert.der | openssl x509 -inform DER -out cert.pem

  2. Verificato:
    openssl verify -CAfile ca-bundle.pem cert.pem

    dove ca-bundle.pem contiene le CA italiane abilitate per la PEC.

Con questi passaggi il tuo client PEC potrà scoprire automaticamente gli endpoint SMTP/TLS dei provider, prelevare i certificati di sicurezza e configurarsi in modo dinamico per garantire interoperabilità e compliance con RFC 6109.

Tag: