RFC 6109

La Posta Elettronica Certificata - Italian Certified Electronic Mail

📅 published April 2011, from ietf

Part 1 of 12 💖

RFC 6109: La Posta Elettronica Certificata 💌

Okay bestie, this one is about Italian Certified Electronic Mail (Posta Elettronica Certificata, or PEC) 📮. It's an Informational RFC, so it's not a Standards Track spec, it's just here to document how Italy's system works.

Who wrote it: C. Petrucci from DigitPA, plus F. Gennai and A. Shahin from ISTI-CNR, and A. Vinciarelli. 🫶

Date: April 2011 🗓️

Category: Informational 🦋

ISSN: 2070-1721

Obsoletes and updates: nothing is listed in this header, so nothing gets replaced or patched here. ✨

Abstract

Since 1997, Italian law has recognized electronic delivery systems as legally usable 👑. In 2005, after two years of technical tests, the rules for an official electronic delivery service called certified electronic mail (Posta Elettronica Certificata) were defined, and that gave the whole system legal standing 🎀.

DigitPA designed the whole system, and then the implementation and testing came after. DigitPA handed the job of testing service providers to the Italian National Research Council (CNR), specifically the Institute of Information Science and Technologies at the CNR (ISTI). The goal was to make sure everything was implemented correctly and that providers could talk to each other 🤝. This document describes the certified email system adopted in Italy as it stands at the time of writing. It follows the technical regulations written under the Italian Law DPR. November 2, 2005. 💅

Status of This Memo

This document is not an Internet Standards Track specification, it's published for information only 📚.

It's a product of the Internet Engineering Task Force (IETF) and it was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈.

For the current status, any errata, or to send feedback, go to http://www.rfc-editor.org/info/rfc6109 🔗.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they were in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, just like the Simplified BSD License says 🌈.

Table of Contents 📑

   1. Introduction ....................................................5
      1.1. Scope ......................................................5
      1.2. Notational Conventions .....................................6
           1.2.1. Requirement Conventions .............................6
           1.2.2. Acronyms ............................................6
           1.2.3. Terminology and Definitions .........................7
   2. PEC Model .......................................................8
      2.1. System-Generated Messages ..................................8
           2.1.1. Message Types ......................................10
      2.2. Basic Structure ...........................................12
           2.2.1. Access Point .......................................12
           2.2.2. Incoming Point .....................................14
           2.2.3. Delivery Point .....................................16
           2.2.4. Storage ............................................17
           2.2.5. Provider Service Mailbox ...........................17
           2.2.6. Provider Service Email Address .....................17
      2.3. Log .......................................................17
   3. Message Processing .............................................18
      3.1. Access Point ..............................................18
           3.1.1. Formal Checks on Messages ..........................18
           3.1.2. Non-Acceptance PEC Notification Due to
                  Formal Exceptions ..................................19
           3.1.3. Non-Acceptance PEC Notification Due to
                  Virus Detection ....................................20
           3.1.4. Server-User Acceptance PEC Notification ............20
           3.1.5. PEC Transport Envelope .............................21
           3.1.6. Timeout Delivery Error PEC Notification ............23
      3.2. Incoming Point ............................................24
           3.2.1. Server-Server Acceptance PEC Notification ..........24
           3.2.2. PEC Anomaly Envelope ...............................25
           3.2.3. Virus Detection PEC Notification ...................27
           3.2.4. Virus-Induced Delivery Error PEC notification ......28
      3.3. Delivery Point ............................................29
           3.3.1. Checks on Incoming Messages ........................29
           3.3.2. Delivery PEC Notification ..........................29
           3.3.3. Non-Delivery PEC Notification ......................34
      3.4. Sender and Receiver Belonging to the Same Domain ..........34
      3.5. Example: Complete Transaction between Two PEC Domains .....34
   4. Formats ........................................................35
      4.1. Temporal Reference ........................................35
      4.2. User Date/Time ............................................36
      4.3. Format of a PEC Message Body ..............................36
           4.3.1. User Readable Text .................................37
           4.3.2. Original Message ...................................37
           4.3.3. Certification Data .................................37
      4.4. Certification Data Scheme .................................37
      4.5. PEC Providers Directory Scheme ............................39
           4.5.1. providerCertificateHash Attribute ..................41
           4.5.2. providerCertificate Attribute ......................41
           4.5.3. providerName Attribute .............................41
           4.5.4. mailReceipt Attribute ..............................42
           4.5.5. managedDomains Attribute ...........................42
           4.5.6. LDIFLocationURL Attribute ..........................43
           4.5.7. providerUnit Attribute .............................43
           4.5.8. LDIFLocationURLObject Object Class .................44
           4.5.9. Provider Object Class ..............................44
           4.5.10. LDIF File Example .................................44
   5. Security-Related Aspects .......................................48
      5.1. Digital Signature .........................................48
      5.2. Authentication ............................................48
      5.3. Secure Interaction ........................................49
      5.4. Virus .....................................................49
      5.5. S/MIME Certificate ........................................49
           5.5.1. Provider-Related Information (Subject) .............50
           5.5.2. Certificate Extensions .............................50
           5.5.3. Example ............................................51
      5.6. PEC Providers Directory ...................................55
   6. PEC System Client Technical and Functional Prerequisites .......55
   7. Security Considerations ........................................55
   8. IANA Considerations ............................................56
      8.1. Registration of PEC Message Header Fields .................56
           8.1.1. Header Field: X-Riferimento-Message-ID: ............56
           8.1.2. Header Field: X-Ricevuta: ..........................56
           8.1.3. Header Field: X-VerificaSicurezza: .................57
           8.1.4. Header Field: X-Trasporto: .........................57
           8.1.5. Header Field: X-TipoRicevuta: ......................57
           8.1.6. Header Field: X-Mittente: ..........................58
      8.2. Registration of LDAP Object Identifier Descriptors ........58
           8.2.1. Registration of Object Classes and
                  Attribute Types ....................................58
   9. References .....................................................59
      9.1. Normative References ......................................59
      9.2. Informative References ....................................61
   10. Acknowledgments ...............................................62
   Appendix A. Italian Fields and Values in English ..................63

1. Introduction ✨

Since 1997, Italian law has recognized electronic delivery systems as legally usable 👑. In 2005, after two years of technical tests, the rules for an official electronic delivery service called certified electronic mail (in Italian Posta Elettronica Certificata, from now on "PEC") were defined, and the system got legal standing 🎀.

This document is the English version of the Italian specifications at http://www.digitpa.gov.it/sites/default/files/normativa/Pec_regole_tecniche_DM_2-nov-2005.pdf. The Italian version is the normative PEC reference, so if the two ever disagree, Italian wins 🇮🇹.

IETF review didn't reach community consensus. 🙃 Since this specification describes existing deployment and implementation, the issues the IETF community raised were not fixed in this document. Still, those issues would need to be addressed before a successor to this document could be published 🧐. At a minimum, the successor would need to include:

A clear statement of the requirements/goals that need to be satisfied by the protocol;
A comprehensive diagram and description of the overall message flow and delivery sequence required to achieve the requirements;
Alignment with traditional terminology for IETF email and security
A review of prior art; and
A replacement of the unregistered LDAP DN name space used in this specification, which may lead to conflict with other registered or unregistered names, with a registered name space. 💜

1.1. Scope

Okay bestie, so the goal here is keeping electronic messages secure: making sure the sender is who they say they are, nobody has messed with the message, it stays private, and the sender can't just deny sending it 🔐. End-to-end crypto can do all of this, and some of it is seriously strong 💪. The catch is that everyone needs asymmetric keys and certificates signed by a Certification Authority, and they also need enough know-how to actually use all that 😵‍💫. Not everyone has that, so it's a lot to ask.

PEC takes a different route 🦋. Applications running on servers do the digital signing, so the user only needs a regular mail client. That skips the complicated part entirely ✨. The tradeoff is that security is weaker, since the protection doesn't cover the whole journey from start to finish. Still, it's way simpler to use and needs no special skills, so it's easily more popular with everyday users 🌸.

This document explains PEC's technical side and features 📚. It goes through the protocol details and the messages that get exchanged between service providers, and it introduces the system the Italian government adopted for certified email 🇮🇹💌.

1.2. Notational Conventions

1.2.1. Requirement Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [REQ]. Read those as the official rule-words they are 📏🫶.

1.2.2. Acronyms

Here's the acronym list, the alphabet soup you'll see all over this doc 🍜:

      CMS:      Cryptographic Message Syntax
      CNIPA:    Italian National Agency for Digital Administration
                (Centro Nazionale per l'Informatica nella Pubblica
                Amministrazione)
      CNR:      Italian National Research Council (Consiglio Nazionale
                delle Ricerche)
      CRL:      Certificate Revocation List
      CRL DP:   Certificate Revocation List Distribution Point
      DNS:      Domain Name Service
      DTD:      Document Type Definition
      FQDN:     Fully Qualified Domain Name
      ISTI:     The Institute of Information Science and Technologies
                at the CNR (Istituto di Scienza e Tecnologie
                dell'Informazione "A.Faedo")
      LDAP:     Lightweight Directory Access Protocol
      LDIF:     LDAP Data Interchange Format
      MIME:     Multipurpose Internet Mail Extensions
      PEC:      Certified Electronic Mail (Posta Elettronica
                Certificata)
      S/MIME:   Secure/MIME
      SMTP:     Simple Mail Transfer Protocol
      TLS:      Transport Layer Security
      XML:      eXtensible Markup Language

1.2.3. Terminology and Definitions

Time for the glossary, the vocab you need to keep the vibes straight 💅:

Certification data: A bundle of data that the sender's PEC provider certifies, describing the original message 🧾. It covers the date and time it was sent, the sender's email address, the recipient(s) email address(es), the subject, and the message identifier.

Certified electronic mail: A service built on email, as defined by the [EMAIL] and [SMTP] standards and their extensions 📮. It lets you send documents made with computer tools.

DigitPA: The former CNIPA 🏛️.

Holder: The person or organization a PEC mailbox has been assigned to 🫶.

Message sent: A PEC message counts as sent once the sender's PEC provider has run several checks, accepted the email, and sent back a server-user acceptance PEC notification to the sender ✅.

Message received: A PEC message counts as received once it's stored in the receiver's mailbox. After that, the receiver's PEC provider sends a delivery PEC notification back to the sender 💫.

Msgid: The message identifier the email client generates, as defined in [EMAIL], before the message gets submitted to the PEC system 🆔.

Ordinary mail: Regular non-PEC email messages 📬.

Original message: The message the user wrote, before it reaches the sender Access Point 💭. The original message gets delivered to the recipient inside a PEC transport envelope 💌.

PEC domain: A DNS domain set aside for the holders' mailboxes 🌐.

PEC mailbox: An electronic mailbox that gets delivery PEC notifications whenever it receives PEC messages 📥. A mailbox like this can be defined only within a PEC domain.

PEC msgid: A unique identifier made by the PEC system, which takes the place of the msgid 🪪.

PEC provider: The entity that runs one or more PEC domains, along with their Access, Reception, and Delivery points 🏢. It holds the key used to sign PEC notifications and envelopes, and it talks to other PEC providers so holders can reach each other 🤝.

PEC provider's key: A key DigitPA hands out to every PEC provider 🔑. It's used to sign PEC notifications and envelopes, and to authorize access to the PEC providers directory.

PEC providers directory: An LDAP server sitting somewhere every PEC service provider can reach 🗂️. It's the technical backbone of the public list of PEC service providers, and it holds the list of PEC domains and service providers along with their relevant certificates.

Service mailbox: A mailbox used only by the provider, for receiving server-server acceptance and virus detection PEC notifications 🛡️.

Time stamp: Digital evidence that attaches a time reference, one that can't be denied, to one or more documents ⏰.

2. PEC Model ✨

2.1. System-Generated Messages

The PEC system makes messages in MIME format 🎀. Each one has a descriptive text part plus some other [MIME1] parts, and the number and content of those depend on what kind of message it is 🧩.

A system-generated message falls into one of these categories:

Notifications;
Envelopes.

The message gets put into an S/MIME v3 structure in CMS format and signed with the PEC provider's private key 🔏. The X.509v3 certificate tied to that key MUST be included in this structure 🪪. The S/MIME format used to sign system-generated messages is the "multipart/signed" format (.p7s), as described in section 3.4.3 of [SMIMEV3] 💅.

To make sure signatures can be checked on as many mail clients as possible, X.509v3 certificates used by certified email systems MUST abide by the profile found in section 6.5 🫶.

For the receiving mail client to verify the signature, the sender address MUST coincide with the one in the X.509v3 certificate 🔍. So for this to work, PEC transport envelopes MUST indicate in the "From:" field a single author's address that is different from the one in the original message 🎭. To keep things usable for the person receiving it, the author's address from the original message gets put in as a "display name" 🌸. Here's an example. A "From:" field like this:

      From: "John Smith" <john.smith@domain.example.com>

would turn into this "From:" value in the matching PEC transport envelope:

      From: "On behalf of: john.smith@domain.example.com"
                               <certified-mail@provider.example.com>

Both "From:" and "Sender:" fields MUST contain the same value 👯. And so replies get sent back to the right place, the "Reply-To:" field in the PEC transport envelope MUST contain the same unaltered value as the original message's "Reply-To:" field 💌. If the original message doesn't explicitly have one, the system making the PEC transport envelope creates it by pulling the information from the original message's "From:" field 🕵️‍♀️.

When PEC notifications get sent, the system MUST use the original message sender's address as the destination address, as specified in the reverse path data of the SMTP protocol 🎯. PEC notifications MUST be sent to the sender's PEC mailbox, ignoring the "Reply-To:" field that might be in the original message's header 🙅‍♀️.

Every system-generated PEC message can be spotted by a specific header that PEC defines for its message type 👀.

To work out the certification data, the system uses the same elements that handle the actual routing of the message 🛤️. During the SMTP dialog, the reverse path and forward path data (the "MAIL FROM" and "RCPT TO" commands) count as certification data for the sender and the recipients, respectively 📨. The addressing data in the message body ("To:" and "Cc:" fields) is only used to tell primary recipients apart from carbon copy recipients when that's needed 🧐. Addressing data in the "Bcc:" field MUST be considered invalid by the system 🚫.

2.1.1. Message Types

All system-generated messages inherit their header fields and values from the original message, and then get extra fields depending on what type they are 🧃.

2.1.1.1. PEC Notifications

Notifications keep the sending user and the other providers in the loop on how the message is moving through the PEC network 📡.

2.1.1.1.1. Success PEC Notifications

These notifications confirm that the provider on the other end received or handled a PEC message 🥳. More specifically, one of three situations can be indicated: server-user acceptance, server-server acceptance, or delivery 🎉.

The added header fields are:

X-Ricevuta:
X-Riferimento-Message-ID:

The X-Ricevuta: field says which type of PEC notification is in the message, while X-Riferimento-Message-ID: holds the message identifier the mail client generated (the msgid) 🏷️.

The body contents depend on the notification type, and section 3 explains that in more detail 📖.

A server-user acceptance PEC notification tells the user that their provider accepted the message and will pass it along to the addressee's provider(s) 🚀.
A server-server acceptance PEC notification is for inter-provider communication only, so it MUST NOT be sent to the users 🙊. With it, the receiving provider just tells the sending provider it got a PEC message and will take responsibility for forwarding it to the addressee(s) 🤝. From that point on, the sending provider isn't responsible for where the message ends up, and it only has to tell its user whether delivery worked or failed 📬.
Delivery PEC notifications come as the very last step of a transaction, signaling overall success in handing the message to the addressee(s) 🏁.

2.1.1.1.2. Delay PEC Notifications

Delay PEC notifications go out 12 hours after a message was dispatched from the sending provider, as long as no server-server acceptance or delivery PEC notification has come back ⏳. They exist for one reason only: to let the user know there's a delay 🐢.

If another 12 hours pass with no sign of a server-server acceptance or delivery PEC notification (that's a 24-hour delay total), another delay PEC notification gets sent to the user, letting them know delivery may have failed 😬. After that, the provider stops tracking the delay 🫡.

2.1.1.1.3. Failure PEC Notifications ❌

okay so failure PEC notifications get sent when something goes wrong during transmission or reception 💀 more specifically, a failure PEC notification can indicate either a formal-exception error or a virus detection 🦋

added header fields are:

X-Ricevuta:
X-Riferimento-Message-ID:
X-VerificaSicurezza: [optional]

"X-Ricevuta:" and "X-Riferimento-Message-ID:" do the same job they do in section 2.1.1.1.1 (Success Notifications) 🫶 "X-VerificaSicurezza:" (security verification) is an optional header field, used for virus-related PEC notifications ✨

body contents change depending on the notification type 🎀 this is explained more thoroughly in section 3.

2.1.1.2. PEC Envelopes 📮

messages entering the PEC network get tucked inside special PEC messages called envelopes before they're allowed to keep circulating in the network 💅 these envelopes MUST inherit the following header fields, along with their unmodified values, from the message itself:

Received:
To:
Cc:
Return-Path:
Reply-To: (if present)

depending on the type of message asking to get into the PEC network, it'll go into either a PEC transport envelope or a PEC anomaly envelope 🌸 you can tell which one through the addition of the "X-Trasporto:" header field 🔍

2.2. Basic Structure 🧱

                +-------------+               +------------+
                |    +--+     |               |            |
                |    |AP|     |      PEC      |            |
      +----+    |    +--+     |   messages &  | +---+ +--+ |    +----+
      |user|<-->|             |<------------->| |InP| |DP| |<-->|user|
      +----+    | +--+  +---+ | notifications | +---+ +--+ |    +----+
                | |DP|  |InP| |               |            |
                | +--+  +---+ |               |            |
                +-------------+               +------------+
                     PEC                            PEC
                    sender                        receiver
                   provider                       provider

where:

AP = Access Point
DP = Delivery Point
InP = Incoming Point

2.2.1. Access Point 👀

this is what the user client on the sender side talks to 💖 it gives the user access to the PEC services the provider has set up.

such access MUST be preceded by user authentication on the system (see section 5.2). the Access Point receives the original messages its user wants to send, runs some formal checks, and acts according to the outcome:

if the message passes all checks, the Access Point generates a server-user acceptance PEC notification and inserts the original message inside a PEC transport envelope;
if a formal exception is detected, the Access Point refuses the message and emits the relevant non-acceptance PEC notification (see section 3.1.1);
if a virus is detected, the Access Point generates a non-acceptance PEC notification and inserts the original message as is in the provider's special store.

generating the server-user acceptance notification tells the user that the system accepted the message, and it also certifies the date and time of the event ⏰ the notification MUST contain user-readable text, and an XML part containing the certification data 📜 the notification MAY also contain other attachments for extra features the provider offers ✨

using the data in the PEC providers directory (see section 4.5), the Access Point runs checks on every recipient in the "To:" and "Cc:" fields of the original message 🔎 it's checking whether each one belongs to the PEC infrastructure or to a non-PEC domain. these checks are done by verifying the existence, through a case-insensitive search, of the recipients' domains in the "managedDomains" attribute found within the PEC providers directory. so the server-user acceptance PEC notification (and its certification data) relates, for each address, to the typology of its domain: PEC or non-PEC 🌈

the message identifier (PEC msgid) of accepted original messages within the PEC infrastructure MUST be unambiguous, so that messages and their relative PEC notifications can be tracked correctly 🧚 the format of this identifier is:

[alphanumeric string]@[provider mail domain]

or:

[alphanumeric string]@[FQDN mail server]

so both the original message and the corresponding PEC transport envelope MUST contain the following header field:

Message-ID: <[unique identifier]>

when an email client interacting with the Access Point has already inserted a message identifier (msgid) in the original message, that msgid SHALL be substituted by a PEC msgid 💫 so the sender can link the message they sent with the relative PEC notifications, the msgid MUST be inserted in the original message as well as in the relative PEC notifications and transport envelope. if present, the msgid is REQUIRED in the original message's header by adding the following header field:

X-Riferimento-Message-ID: <[msgid]>

which will also be inserted in the PEC transport envelope and notifications, and related in the certification data (see section 4.4).

2.2.2. Incoming Point 🚪

this point permits the exchange of PEC messages and notifications between PEC providers 🤝 it's also the point where ordinary mail messages can be inserted into the system of certified mail 📬

the exchange of messages between providers takes place through SMTP-based transactions, as defined in [SMTP] 💌 if SMTP communication errors occur, they MAY be handled using the standard error notification mechanisms provided by SMTP in [SMTP] and [SMTP-DSN]. the same mechanism is also adopted for handling transitory errors that result in long idling periods during an SMTP transmission phase. in order to guarantee that an error is returned to the user, as defined in section 3.3.3, the system that handles PEC traffic MUST adopt a time limit for message idleness equal to 24 hours ⏳

once a message arrives, the Incoming Point runs the following list of checks and operations:

verifies correctness and type of the incoming message;
if the incoming message is a correct and undamaged PEC transport envelope:
- emits a server-server acceptance PEC notification towards the sender provider (section 3.2.1);
- forwards the PEC transport envelope to the Delivery Point (section 3.3).
if the incoming message is a correct and undamaged PEC notification, forwards the notification to the Delivery Point.
if the incoming message does not conform to the prerequisites of a correct and undamaged PEC transport envelope or notification, but comes from a PEC provider, i.e., passes the verifications regarding existence, origin, and validity of the signature, then the message MUST be propagated towards the recipient. therefore, the Incoming Point:
- inserts the incoming message in a PEC anomaly envelope (section 3.2.2);
- forwards the PEC anomaly envelope to the Delivery Point.
if the incoming message does not originate from a PEC system, i.e., fails verifications regarding existence, origin, and validity of the signature, then the message will be treated as ordinary email, and, if propagated to the recipient:
- is inserted in a PEC anomaly envelope (section 3.2.2);
- the PEC anomaly envelope is forwarded to the Delivery Point.

the server-server acceptance PEC notification is generated by the receiving provider and sent to the sending provider 🔁 its purpose is to keep track of the message as it moves from one provider to another, so it's strictly intra-provider communication. the end user knows nothing about it 🙈

to check the correctness and integrity of a PEC transport envelope or notification, the Incoming Point runs the following tests:

Signature existence - the system verifies the presence of an S/MIME signature structure within the incoming message;
Signature origin - the system verifies whether or not the signature belongs to a PEC provider by extracting the certificate used for signing and verifying its presence in the PEC providers directory. to ease the check, it's possible to calculate the certificate's [SHA1] hash value and perform a case-insensitive search of its hexadecimal representation within the "providerCertificateHash" attribute found in the PEC providers directory. this operation makes it easy to identify the sender provider for the subsequent matching checks between the extracted certificate and the one present in the provider's record;
Signature validity - S/MIME signature correctness is verified by recalculating the signature value, checking the entire certification path, and verifying the [CRL] and temporal validity of the certificate. in case some caching mechanism is used for CRL contents, an update interval MUST be adopted so that the most up-to-date data is guaranteed, thus minimizing the possible delay between a publication revocation by the Certification Authority and the variation acknowledgment by the provider 🕰️;
Formal correctness - the provider performs sufficient and necessary checks to guarantee that the incoming message is compliant with the formats specified in this document (PEC transport envelope and notifications).

if a virus-infected PEC transport envelope passes the checks just mentioned, it's still considered correct and undamaged 🦠 the presence of the virus will be detected in a second phase, during which the contents of the PEC transport envelope are verified. so the Incoming Point will refrain from forwarding the message to the recipient, and will instead send the appropriate PEC notification of non-delivery and store the virus-infected message in the provider's special storage 🔒

in case ordinary mail messages are received, the PEC provider SHALL perform virus checks to prevent potentially dangerous mail messages from infiltrating the PEC system 🛡️ if a virus is detected in an ordinary mail message, that message can be discarded at the Incoming Point before it enters the PEC system. in other words, no special treatment is reserved for the error; it's handled in a manner conformant to the procedures usually followed for messages going through the Internet 🌐

when the receiving provider detects a virus inside a PEC transport envelope during the reception phase, it emits a virus detection PEC notification to the sending provider, which then realizes its checks failed to detect that virus 😭 when this happens, the sending provider MUST:

check what virus typologies were not detected by its own antivirus to verify the possibility of interventions;
send a virus-induced non-delivery PEC notification to the sender's mailbox.

2.2.3. Delivery Point ✨

okay so the Delivery Point is the one that catches messages from the Incoming Point and passes them along to the final recipient 📬

it MUST run a bunch of tests on each message before it goes to the user (see section 3.3.1) 🕵️‍♀️ first it checks the typology of the message and decides if a PEC notification should go back to the sender. the delivery PEC notification (section 3.3.2) only goes out after the message lands in the recipient's PEC mailbox, and only when it gets a valid PEC transport envelope (sections 2.2.2 and 3.1.5) 💌

in every other case, like PEC anomaly envelopes and PEC notifications, the delivery PEC notification is NOT emitted. no cap, but even then the message the Delivery Point gets MUST be delivered unmodified to the recipient's mailbox 🫶 nothing gets edited, periodt 💅

the delivery PEC notification is basically the sender's receipt saying "yep, your message actually reached that person's mailbox" 🎀 it certifies the date and time of delivery with readable text and an XML part full of certification data, plus any extra attachments the provider adds for fancy features ✨

if a PEC transport envelope hits the Delivery Point and can't be delivered to the destination mailbox, the Delivery Point sends out a non-delivery PEC notification (section 3.3.3) 😭 but if the delivery error is for a message coming from the Internet (so, a non-PEC message), no notification gets sent at all 🦋

2.2.4. Storage 🗄️

each provider MUST set aside a special storage spot for any virus-infected messages it runs into 🦠 whether the virus is caught by the sender's Access Point or the receiver's Incoming Point, the provider that catches it MUST store the mail message in its own storage and keep it for 30 months 🔒 that's a long time, bestie 💀

2.2.5. Provider Service Mailbox 📮

this one is for exclusive use of the provider only 👑 it's dedicated to receiving PEC notifications in two cases, and only two:

server-server acceptance notification; and
virus detection notification.

2.2.6. Provider Service Email Address ✉️

each provider MUST register a special purpose email address for sending PEC transport envelopes and notifications, as laid out in section 3 🌸 this address MAY be the same as the service mailbox from section 2.2.5, so you don't have to make a whole new one if you don't want to 🧚

2.3. Log 📝

the server administrator MUST keep track of any and all operations in a specific message log file 🕵️‍♀️ for each operation, the log keeps the following info:

message identifier (msgid)
date and time of event
sender of original message
recipient(s) of original message
subject of original message
event type (reception, delivery, PEC notification emission, etc.)
message identifiers of related generated messages
sending provider

the service provider MUST store this data and keep it unmodified 🔐 Italian laws say the service provider has to hang on to the data for 30 months, so it's a whole vibe 🇮🇹

3. Message Processing 💫

3.1. Access Point 🚪

the Access Point acts as a submission service, as defined in [SUBMISSION] 🎀

3.1.1. Formal Checks on Messages 📋

when the Access Point gets a message the user wants to send, it MUST guarantee that the message is formally conformant as defined in [EMAIL] 🧐 it also has to verify that:

the [EMAIL] header section has a "From:" header field holding an [EMAIL] compliant email address;
the [EMAIL] header section has a "To:" header field holding one or more [EMAIL] compliant email addresses;
the sender's address, from the SMTP reverse path, matches the one in the message's "From:" header field;
the recipients' addresses in the SMTP forward path match the ones in the "To:" or "Cc:" header fields of the message;
the "Bcc:" header field does NOT contain any value;
the total message size falls within the limits the provider accepts 📏 those limits also depend on how many recipients there are, so multiply the number of recipients by the message size and the outcome MUST fall within the limits the provider accepts. Italian laws set this limit at 30 MB.

if the message doesn't pass these tests, the Access Point MUST NOT accept it into the PEC system, and it sends out the matching PEC notification of non-acceptance 🙅‍♀️

3.1.2. Non-Acceptance PEC Notification Due to Formal Exceptions 🚫

when the Access Point can't forward a message because it failed the formal checks, the sender gets told about it 📣 if the message failed the size checks, a non-acceptance PEC notification is sent as long as the size stays under a certain limit. if it's bigger than that limit, error handling is left up to SMTP 🤷‍♀️

the notification header will contain these fields:

X-Ricevuta: non-accettazione
Date: [date of notification emission]
Subject: AVVISO DI NON ACCETTAZIONE: [original subject]
From: posta-certificata@[mail domain]
To: [original sender]
X-Riferimento-Message-ID: [msgid]

the notification body has a text part that's the readable version of the notification, following this model:

Error in message acceptance
On [date] at [time] ([time zone]), in the message "[subject]"
originating from "[original sender]" and addressed to:
[recipient_1]
[recipient_2]
[recipient_n]
a problem was detected that prevents its acceptance due to
[error description].
The message was not accepted.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the same certification info also goes into an XML file added to the notification body, so automatic checks can happen on the message (section 4.4) 🤖 parsing MUST be done on the XML part ONLY 🫵 the provider MAY include additional parts for provider-specific services. either way, the original message MUST NOT be included, and the message MUST follow the format described in section 4.3 💖

3.1.3. Non-Acceptance PEC Notification Due to Virus Detection 🦠

the Access Point MUST run some tests on the content of messages it gets from its users, and reject them if a virus is detected 🛡️ when that happens, a virus-detection-induced non-acceptance PEC notification MUST be emitted so the user clearly knows why the message got refused 🫶

the notification header contains these fields:

X-Ricevuta: non-accettazione
X-VerificaSicurezza: errore
Date: [notification emission date]
Subject: AVVISO DI NON ACCETTAZIONE PER VIRUS: [original
         subject]
From: posta-certificata@[mail domain]
To: [original sender]
X-Riferimento-Message-ID: [msgid]

the body has a readable text part following this model:

Error in message acceptance due to virus presence
On [date] at [time] ([time zone]), in the message "[subject]"
originating from "[original sender]" and addressed to:
[recipient_1]
[recipient_2]
[recipient_n]
a security problem was detected [ID of detected content type].
The message was not accepted.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the same certification data goes into an XML file added to the notification so automatic checks are possible (section 4.4). parsing MUST be done on the XML part ONLY 🧾 additional parts MAY be included by the provider for provider-specific services. regardless, the original message MUST NOT be included, and the message MUST follow the format described in section 4.3 ✨

3.1.4. Server-User Acceptance PEC Notification 🎉

the server-user acceptance PEC notification is a message the server sends to the sender 💌 it has the date and time the message was accepted into the system, the sender and recipient data, and the subject 🌷

the header contains these fields:

X-Ricevuta: accettazione
Date: [actual date of server-user acceptance]
Subject: ACCETTAZIONE: [original subject]
From: posta-certificata@[mail domain]
To: [original sender]
X-Riferimento-Message-ID: [msgid]

the body has a readable text part following this model:

Server-User Acceptance PEC notification
On [date] at [time] ([time zone]), the message "[subject]"
 originating from "[original sender]" and addressed to:
[recipient_1] (["certified mail" | "ordinary mail"])
[recipient_2] (["certified mail" | "ordinary mail"])
[recipient_n] (["certified mail" | "ordinary mail"])
was accepted by the system and forwarded to the recipient(s).
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the same certification data goes into an XML file added to the notification message, so automatic checks can be done on it (section 4.4) 🤖 parsing MUST be done on the XML part ONLY. additional parts MAY be included by the provider for provider-specific services. the message MUST follow the format described in section 4.3 🫶

3.1.5. PEC Transport Envelope 💜

a PEC transport envelope is a message the Access Point generates, and it holds the original message AND the certification data 🎁

as mentioned in section 2.1.1.2, the PEC transport envelope inherits these header field values from the original message, which MUST be related unmodified:

Received:
To:
Cc:
Return-Path:
Reply-To: (if present)

on the other hand, the following fields MUST be modified, or inserted if necessary:

X-Trasporto: posta-certificata
Date: [actual date of server-user acceptance]
Subject: POSTA CERTIFICATA: [original subject]
From: "On behalf of: [original sender]"
                     <certified-mail@[mail_domain]>
Reply-To: [original sender] (inserted only if not present)
Message-ID: [PEC msgid generated as in section 2.2.1]
X-Riferimento-Message-ID: [msgid]
X-TipoRicevuta: [completa/breve/sintetica]

the "X-TipoRicevuta:" field shows which type of delivery PEC notification the sender wants to get: complete, brief, or concise 🎀

the body of the PEC transport envelope has a text part that's the readable version of the message, following this model:

Certified mail message
On [date] at [time] ([time zone]), the message "[subject]" was
sent by "[original sender]" and addressed to:
[recipient_1]
[recipient_2]
[recipient_n]
The original message is included in attachment.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

inside the PEC transport envelope, the whole, unmodified original message is included in a format compliant with [EMAIL] (except for what was said about the message identifier), plus an XML part with the certification data already written in text, and info on the type of message and PEC notification requested (section 4.4) 🧾 parsing MUST be done on the XML part ONLY. additional parts MAY be included by the provider for provider-specific services. the message MUST follow the format described in section 4.3 🌈

note that the routing data of the PEC transport envelope (forward and reverse paths) stays unaltered 🦋

3.1.6. Timeout Delivery Error PEC Notification ⏰

okay so if the sending provider waits 12 hours and gets no server-server acceptance or delivery PEC notification from the receiving provider, it lets the user know the recipient's provider might not be able to deliver the message 😬. if there's still no delivery PEC notification 24 hours after dispatch, it sends another non-delivery notification to the user at the 24-hour timeout, but never before 22 hours have passed ⏳.

these are non-delivery PEC notifications due to timeout, and the header looks like this 💌:

X-Ricevuta: preavviso-errore-consegna
Date: [date of notification emission]
Subject: AVVISO DI MANCATA CONSEGNA PER SUP.  TEMPO MASSIMO:
         [original subject]
From: posta-certificata@[mail domain]
To: [original recipient]
X-Riferimento-Message-ID: [msgid]

the body of the first one (the 12-hour timeout) has a text part that's the readable version, and it says:

Non-delivery PEC notification
On [date] at [time] ([time zone]), the message
"[subject]" originating from "[original sender]"
and addressed to "[recipient]"
has not been delivered within the first 12 hours following
its dispatch.  Not excluding that the message might eventually
be delivered, it is deemed useful to consider that dispatch
might not have a positive outcome.  The system will see to
sending another non-delivery PEC notification if in the
following twelve hours no confirmation is received from the
recipient.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the 24-hour timeout ones have the same header, but the body is different 🫶:

Non-delivery PEC notification
On [date] at [time] ([time zone]), the message
"[subject]" originating from "[original sender]"
and addressed to "[recipient]"
has not been delivered within 24 hours of its dispatch.

The transaction is deemed to be considered terminated with a
negative outcome.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the same certification data also goes into an XML file that gets attached to both notification types, so machines can run automatic checks (section 4.4) 🤖.

Parsing MUST be done on the XML part only. Additional parts MAY be added for services supplied by the PEC provider. Regardless, the original message MUST NOT be included. The message MUST follow the format described in section 4.3. not the original message showing up uninvited, iconic behaviour 💅

a timeout PEC notification gets generated if one of these scenarios happens:

the sending provider gets a server-server acceptance PEC notification during the first 12 hours after dispatch, but never gets a delivery PEC notification at all. In this case, it's a 24-hour timeout PEC notification.
the sending provider doesn't get a server-server acceptance PEC notification, but does get a delivery PEC notification after 12 hours and before the 24-hour timeout. In this case, it's a 12-hour timeout PEC notification.
the sending provider doesn't get either a server-server acceptance or a delivery PEC notification. In this case, two timeout PEC notifications are generated: a 12-hour and a 24-hour timeout PEC notification 💀.

3.2. Incoming Point 📥

3.2.1. Server-Server Acceptance PEC Notification 🎀

when correct PEC transport envelopes (as defined in section 2.2.2.) are exchanged between PEC providers, the receiver MUST send a server-server acceptance PEC notification to the sender ✨. one single notification covers all the recipients who belong to the same provider and were addressed in the incoming message, as shown in the routing data (forward and reverse paths) of the SMTP transaction. Inside the certification data of one server-server acceptance PEC notification, every recipient of the referenced message is listed. Generally speaking, when a PEC transport envelope comes in, each provider MUST emit one or more server-server acceptance PEC notifications to cover all the recipients in its jurisdiction, assuming there are no SMTP transport errors 🍓.

the header of a server-server acceptance PEC notification has these fields:

X-Ricevuta: presa-in-carico
Date: [date of server-server acceptance]
Subject: PRESA IN CARICO: [original subject]
From: posta-certificata@[mail domain]
To: [sender provider service mailbox]
X-Riferimento-Message-ID: [msgid]

the provider's service email address comes from the PEC providers directory, which gets queried during the signature verification stage 🔍.

the body has a text part that follows this model:

Server-server acceptance PEC notification
On [date] at [time] ([time zone]), the message "[subject]"
originating from "[original sender]" and addressed to:
[recipient_1]
[recipient_2]
[recipient_n]
was accepted by the system.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the same certification data goes into an XML file that's attached to the notification so automatic checks can happen (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be added by the provider for provider-specific services. The message MUST follow the format described in section 4.3 🫶.

3.2.2. PEC Anomaly Envelope 🧁

if the tests on an incoming message catch an error, or the message is identified as ordinary mail and the provider is set to forward it to the recipient, the system MUST insert that message into a PEC anomaly envelope 🚨. before delivery, the entire message received at the Incoming Point gets put in a format compliant with [EMAIL] as a [MIME1] part, inside a new message. That new message MUST inherit the unmodified values for these header fields from the received message:

Received:
To:
Cc:
Return-Path:
Message-ID:

Whereas, the following header fields MUST be modified or inserted:

X-Trasplorto: errore
Date: [mlessage arrival date]
Subject: ANOMALIA MESSAGGIO: [original subject]
From: "On behalf of: [original sender]"
                       <posta-certificata@[mail_domain]>
Reply-To: [original sender (inserted only if not already
          present)]

the body has a user-readable text part that follows a model relating this info:

Message anomaly
On [date] at [time] ([time zone]), the message "[subject]"
originating from "[original sender]" and addressed to:
[recipient_1]
[recipient_2]
[recipient_n]
was received.
The data has not been certified due to the following error:
[concise description of error]
The original message is attached.

because the origin and/or conformity of the received message is uncertain, the PEC anomaly envelope MUST NOT contain [MIME1] parts other than the entire message that arrived at the Incoming Point 🙈.

the routing data (forward and reverse paths) of this envelope stays unaltered. Doing that guarantees two things: the message still gets forwarded to the recipients, and the sender still receives any SMTP error notifications, if they happen (as specified in [SMTP] and [SMTP-DSN]) 💜.

3.2.3. Virus Detection PEC Notification 🦠

if the Incoming Point gets virus-infected PEC messages, it MUST NOT forward them 🚫. Instead, it MUST inform the sending provider, which will then tell the sending user that the transmission failed. A separate PEC notification of virus detection MUST be sent on behalf of every recipient within the provider's domain 🌸.

when a virus is detected during reception of a message whose origin was asserted through sender signature verification, the system generates a virus-detected PEC notification that says what error was found, and sends it to the sending provider's service mailbox 🔥.

the header of this PEC notification has these fields:

X-Ricevuta: rilevazione-virus
X-Mittente: [original sender]
Date: [date of notification emission]
Subject: PROBLEMA DI SICUREZZA: [original subject]
From: posta-certificata@[mail domain]
To: [sender provider notifications]
X-Riferimento-Message-ID: [msgid]

the body has a readable text part following this model:

Virus detection PEC notification
On [date] at [time] ([time zone]), in the message "[subject]"
originating from "[original sender]" and addressed to
"[recipient]"
a security problem was detected [ID of content type detected].
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the same certification data goes into an XML file that gets added to the notification so automatic checks can happen (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the provider for provider-specific services. Regardless, the original message MUST NOT be included. The message MUST follow the format described in section 4.3.

The message body MUST contain the reason the transmission could not be completed 📝.

3.2.4. Virus-Induced Delivery Error PEC notification 🦋

when the sender provider gets a virus detection PEC notification from the receiving provider, it emits a non-delivery PEC notification to the sending user 💌.

the header for this notification has these fields:

X-Ricevuta: errore-consegna
X-VerificaSicurezza: errore
Date: [date of notification emission]
Subject: AVVISO DI MANCATA CONSEGNA PER VIRUS: [original
         subject]
From: posta-certificata@[mail domain]
To: [original sender]
X-Riferimento-Message-ID: [msgid]

the body has a readable text part that follows this model:

Delivery error PEC notification due to virus
On [date] at [time] ([time zone]), in the message "[subject]"
addressed to "[recipient]"
a security problem was detected [ID of content type detected
by the anti-virus].
The message was not delivered.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

all the info needed to build this PEC notification can be pulled from the correlated virus-detected PEC notification 🧚.

the same certification data goes into an XML file that gets added to the notification so automatic checks can happen (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the provider for provider-specific services. The reason the transaction was not completed MUST be specified in the message, and the message MUST follow the format described in section 4.3 💖.

3.3. Delivery Point 📬

3.3.1. Checks on Incoming Messages 👑

when a message arrives at the Delivery Point, the system verifies:

message type
whether or not a PEC notification has to be returned

3.3.2. Delivery PEC Notification ✨

okay so a delivery PEC notification only gets issued after a correct PEC transport envelope (sections 2.2.2 and 3.1.5) has been dropped into the recipient's mailbox 📬

in every other case (like PEC anomaly envelopes or PEC notifications) no delivery PEC notification is sent 🙅‍♀️ but either way, the message that arrives at the Delivery Point MUST be delivered to the recipient's mailbox unchanged 💌 no edits, bestie!

this notification basically tells the user "hey, your message got to the person you sent it to" 💖 it has readable text that certifies the date and time of delivery, the sender and receiver info, and the subject. it also has an XML certification data file and some optional extras the provider can add 🎀

the header gets these fields 👇

X-Ricevuta: avvenuta-consegna
Date: [delivery date]
Subject: CONSEGNA: [original subject]
From: posta-certificata@[mail domain]
To: [original sender]
X-Riferimento-Message-ID: [msgid]

the value of the X-TipoRicevuta: header field in the PEC transport envelope is derived from the original message 🧠 so the sender can see what kind of delivery PEC notification the primary recipients asked for ✨ the notification MUST follow the format in section 4.3 🫶

3.3.2.1. Delivery PEC Notification: Complete

this one is the default 💅 if there's no X-TipoRicevuta: value, or it says completa (complete), the system wants a complete delivery PEC notification from the people in To:, and a concise one (section 3.3.2.3) from the people in Cc:. the system works out who's a primary recipient and who's carbon copy by checking the To: and Cc: fields. for notifications going to primary recipients, a full copy of the original message and its attachments gets tucked in 📎 if the delivery system can't tell the recipient type because the To: and Cc: fields are ambiguous, delivery MUST be treated as if the person were a primary recipient, and they get the complete copy 🧐

the notification body has a readable text part that follows this model:

Delivery PEC notification
On [date] at [time] ([time zone]), the message "[subject]"
originating from "[original sender]" and addressed to
"[recipient]"
was placed in the destination's mailbox.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the same certification data goes into an XML file that gets added to the notification (section 4.4), along with any other parts the provider MAY insert for its own services ✨ parsing MUST be done on the XML part only 👀 the delivery PEC notification MUST be issued on behalf of every recipient of the message, and MUST follow the format in section 4.3 🌸

3.3.2.2. Delivery PEC Notification: Brief

to cut down on how much data is flowing around, the sender can ask for the "brief" format 🍓 a brief notification contains the original message plus a ciphered hash value for each of its parts. the hash value SHOULD be calculated on base64 encoded parts. as specified in section 5.3, PEC messages MUST transit only on machines that belong to the PEC network, and those machines MUST NOT alter the encoding of the message during its transition or processing 🔒

NOTE: even though PEC uses these relaxed specifications, interoperability tests between over 20 service providers have never revealed any problems 🙈 this is probably because mail servers lean toward leaving the messages they receive intact without applying changes. but issues might pop up if a server decides to modify encoded parts, for example by changing the base64 line length. the hash value calculated at the receiver's end would then differ from the one on the sender's side 😬

to be able to verify the transmitted contents, the sender needs to keep the unaltered original copy of the part(s) the hash values refer to 🗂️

if the PEC transport envelope contains this header:

X-TipoRicevuta: breve

the Delivery Point emits a brief delivery PEC notification for the primary recipients, and a concise one (section 3.3.2.3) for the carbon copy recipients 🎀 the value of the header field in the PEC transport envelope is derived from the original message.

the notification body has a readable text part that follows a model relating these certification details:

Brief delivery PEC notification
On [date] at [time] ([time zone]), the message "[subject]"
originating from "[original sender]" and addressed to
"[recipient]"
was placed in the destination's mailbox.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the same certification data goes into an XML file added to the notification (section 4.4), along with other parts that MAY be included for provider-supplied services ✨ parsing MUST be done on the XML part only. the delivery PEC notification is issued on behalf of every recipient of the message, and MUST follow the format in section 4.3 💖

the MIME structure of the original message stays unaltered as it's added to the notification 🧩 but each MIME part with a "name" parameter in the Content-Type: header field, or a "filename" parameter in the Content-Disposition: header field, MUST be substituted by a text file containing that MIME part's hash value 🪄

when the original message is in S/MIME format, it's essential not to alter the integrity of the message structure 🔐 verification of the S/MIME part in the original message happens when the MIME type of the top-level entity (which is the message itself) is checked. an S/MIME message MAY have the following MIME types (as per [SMIMEV3]):

multipart/signed this is an original message signed by the sender using the structure described in [MIME-SECURE]. it's made of two MIME parts: the first is the message itself before the sender's signature was applied, and the second holds the signature data. the second part (generally of type application/pkcs7-signature or application/x-pkcs-signature) has data added during the signing phase and MUST be left unchanged so the overall message structure doesn't get compromised 🙏
"application/pkcs7-mime" or "application/x-pkcs7-mime" the message is a sole CMS object inside the MIME part. since attachments can't be separated from the CMS object, the MIME part is left intact (it's not replaced by the hash value), so the brief PEC notification is the same as the complete PEC notification 🎁

if the original message has parts whose Content-Type: is message/rfc822, meaning there's an email message attached inside it, the entire attached message gets swapped out for its hash value 📨

so when emitting a brief delivery PEC notification, the provider MUST:

identify and extract all the parts from the first MIME part of the multipart/signed S/MIME message;
calculate the hash values of all the files the sender attached to the original message;
substitute the originals with their hash values.

in general, for original messages in S/MIME format, the copy inserted into the brief delivery PEC notification has these characteristics:

if the original message is signed, the S/MIME structure and signature-related data stay unchanged. the message will throw an error in a future signature integrity verification phase, because the attachments were swapped for their hash values 💀
if the original message has the application/pkcs7-mime or application/x-pkcs7-mime MIME type, its attachments won't be replaced by their hash values, since they can't be identified inside a CMS structure. the content of the brief delivery PEC notification will match a normal delivery PEC notification 🌈

the hash algorithm used is [SHA1], calculated over the entire content of the part 🔢 to tell hash files apart from the files they refer to, the suffix .hash is added to the original filename. the hash value is written in the file as a hexadecimal representation, one sequence of 40 characters. the MIME type of these attachments is set to text/plain so their textual nature is obvious 📝

3.3.2.3. Delivery PEC Notification: Concise

if the PEC transport envelope contains this header:

X-TipoRicevuta: sintetica

the Delivery Point emits a concise delivery PEC notification to both the primary and carbon copy recipients, and it does NOT contain the original message 🦋

the message body of the notification has a readable text part that follows this model:

Concise delivery PEC notification
On [date] at [time] ([time zone]), the message "[subject]"
originating from "[original sender]" and addressed to
"[recipient]"
was placed in the destination's mailbox.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

the same certification data goes into an XML file within the notification (section 4.4), along with additional parts that MAY be included for provider-specific services ✨ parsing MUST be done on the XML part only. the notification is sent to each recipient the message gets delivered to, and MUST follow the format in section 4.3 🫶

the concise delivery PEC notification follows the same emission rules as the delivery PEC notification. the only addition is the XML file with the certification data, not the original message 🧁

3.3.3. Non-Delivery PEC Notification 💌

Okay so if something goes wrong while a correct PEC transport message is being delivered 😬, the system sends a non-delivery PEC notification back to the sender to explain the error. Total "your package didn't arrive" moment, but make it certified 💅.

The header will contain the following fields:

X-Ricevuta: errore-consegna
Date: [date of notification emission]
Subject: AVVISO DI MANCATA CONSEGNA: [original subject]
From: posta-certificata@[mail domain]
To: [original sender]
X-Riferimento-Message-ID: [msgid]

The notification body has a readable text part, and it follows a template that ties together these bits of info 📝:

Non-delivery PEC notification
On [date] at [time] ([time zone]), in the message "[subject]"
originating from "[original sender]" and addressed to
"[recipient]"
an error was detected [brief error description].
The message was refused by the system.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]

The same certification data also goes inside an XML file that gets attached to the notification 🧚, so that automatic checks can happen (section 4.4). Parsing MUST be done on the XML part only. The PEC provider MAY include additional parts for provider-specific services. The notification MUST follow the format described in section 4.3. 🫶

3.4. Sender and Receiver Belonging to the Same Domain 🏠

PEC messages MUST be processed even if the sender and the receiver(s) are on the same PEC domain. No "we're in the same group chat so skip the process" energy here 😤✨.

3.5. Example: Complete Transaction between Two PEC Domains 🦋

Let's walk through a totally correct transaction between two PEC domains, step by step 🎀:

The sending user emails their provider's Access Point 📤.
The Access Point runs all the checks and sends a server-user acceptance PEC notification to the user ✅.
The Access Point builds a PEC transport envelope and forwards it to the Incoming Point of the receiving provider 🚀.
The receiver's Incoming Point checks the PEC transport envelope and creates a server-server acceptance PEC notification to send back to the sending provider 🔁.
The sender's Incoming Point checks that the server-server acceptance PEC notification is valid and forwards it to the Delivery Point 🔍.
The sender's Delivery Point saves the server-server acceptance PEC notification in the provider's service mailbox 📥.
The receiver's Incoming Point forwards the PEC transport envelope to the receiver's Delivery Point 📦.
The receiver's Delivery Point checks what's inside the PEC transport envelope and saves it in the recipient's mailbox 💾.
The receiver's Delivery Point creates a delivery PEC notification and sends it to the sender's Incoming Point 💌.
The sender's Incoming Point checks that the delivery PEC notification is valid and forwards it to the sender's Delivery Point 🧐.
The sender's Delivery Point saves the delivery PEC notification in the sending user's mailbox 🗂️.
The receiving user has the message at their disposal 🥳👑.

NOTE: Some of these steps might happen in parallel, so the whole thing could wrap up in a different order. Not a bug, just vibes 🌈.

4. Formats 🎀

4.1. Temporal Reference ⏰

Every operation during message, notification, and log processing at the Access, Incoming, and Delivery Points needs an accurate timestamp to work with 🕰️. All events (creating PEC notifications, transport envelopes, logs, and so on) that make up the message processing transaction at the Access, Incoming, and Delivery Points MUST use one single temporal value that comes from inside that same transaction.

Doing this makes the exact moment a message was processed unambiguous across the PEC logs, notifications, messages, etc. that the server generates ✨.

4.2. User Date/Time 📅

Any time info the service gives in readable form (the text in PEC notifications, transport envelopes, and so on) is written with reference to the legal time at the moment of the operation ⚖️. The format is described below, using the syntax description notation defined in [ABNF].

date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules

time-offset     = "(" ("+" / "-") time-hour ":" time-minute ")"

partial-time    = time-hour ":" time-minute ":" time-second

full-date       = date-mday "/" date-month "/" date-fullyear
full-time       = partial-time time-offset

NOTE: For the number of days in a month, leap years, and leap second restrictions, see section 5.7 of [TIMESTAMP]. 🧠

4.3. Format of a PEC Message Body 📨

This section is all about what the different pieces of PEC messages and notifications look like when a PEC system generates them 💖. If any part of a message has characters outside the range 0-127 (7-bit ASCII), that part has to be encoded properly so it still travels safely through 7-bit transport (for example with quoted-printable or base64, as per [MIME1]) 🔐.

Before the signature gets applied, the message body has Content-Type: multipart/mixed. The first part is the user-readable text the PEC system makes, and the second and third parts can come in either order. They hold the original message and the XML file with the certification data 🎁. Each part is described in the sections below.

4.3.1. User Readable Text 📝

Character set: ISO-8859-1 (Latin-1)
MIME type: text/plain or multipart/alternative

The multipart/alternative MIME type MAY be used to add an HTML version of the body of system-generated messages 🌸. When that happens, two sub-parts MUST be present: one of type text/plain, and the other of type text/html. For the HTML part:

it MUST contain the same information as the text part;
it MUST NOT contain references to elements (e.g., images, sounds, font, style sheets), neither internal to the message (added MIME parts) nor external (e.g., hosted on the provider's server);
it MUST NOT have active content (e.g., JavaScript, VBscript, Plug-in, ActiveX). Absolutely no sneaky scripts in the HTML, bestie 🚫💀.

4.3.2. Original Message 💬

MIME type: message/rfc822
Attachment name: postacert.eml

4.3.3. Certification Data 🔏

Character set: UTF-8
MIME type: application/xml
Attachment name: certdata.xml

4.4. Certification Data Scheme 🧾

This is the DTD for the [XML] file that holds the certification data attached to PEC notifications 🧚. Here it is, in all its glory:

<!--Use the element "postacert" as root-->
<!--"tipo" indicates the typology of the PEC message-->
<!--The attribute "errore" can have the following values-->
<!--"nessuno" = no error-->
<!--"no-dest" (with type="errore-consegna") = -->
<!--                                        wrong recipient-->
<!--"no-dominio" (with type="errore-consegna") = -->
<!--                                           wrong domain-->
<!--"virus" (with type="errore-consegna") = virus-->
<!--"virus" (with type="non-accettazione") = virus-->
<!--"altro" = generic error-->
<!ELEMENT postacert (intestazione, dati)>
<!ATTLIST postacert

      tipo (accettazione |
            non-accettazione |
            presa-in-carico |
            avvenuta-consegna |
            posta-certificata |
            errore-consegna |
            preavviso-errore-consegna |
            rilevazione-virus) #REQUIRED
      errore (nessuno |
              no-dest |
              no-dominio |
              virus |
              altro) "nessuno">

<!--Header of the original message-->
<!ELEMENT intestazione (mittente,
                        destinatari+,
                        risposte,
                        oggetto?)>

<!--Sender ("From:" field) of the original message-->
<!ELEMENT mittente (#PCDATA)>

<!--Complete list of recipients ("To:" and "Cc:" fields)-->
<!--of the original message-->
<!--"tipo" indicates the typology of the recipient-->
<!ELEMENT destinatari (#PCDATA)>
<!ATTLIST destinatari
      tipo (certificato | esterno) "certificato">

<!--Value of the "Reply-To:" field of the original message-->
<!ELEMENT risposte (#PCDATA)>
<!--Value of the "Subject:" field of the original message-->
<!ELEMENT oggetto (#PCDATA)>

<!--PEC message data-->
<!ELEMENT dati (gestore-emittente,
                data,
                identificativo,
                msgid?,
                ricevuta?,
                consegna?,
                ricezione*,
                errore-esteso?)>

<!--Descriptive string of the provider that certifies -->
<!--the data-->
<!ELEMENT gestore-emittente (#PCDATA)>
<!--Date/time of message elaboration-->
<!--"zona" is the difference between local time and UTC in -->
<!--"[+|-]hhmm" format-->
<!ELEMENT data (giorno, ora)>
<!ATTLIST data
      zona CDATA #REQUIRED>

<!--Day in "dd/mm/yyyy" format-->
<!ELEMENT giorno (#PCDATA)>
<!--Local hour in "hh:mm:ss" format-->
<!ELEMENT ora (#PCDATA)>

<!--PEC msgid-->
<!ELEMENT identificativo (#PCDATA)>

<!--msgid of the original message before modifications-->
<!ELEMENT msgid (#PCDATA)>

<!--For PEC transport envelopes and delivery notifications-->
<!--indicate the type of PEC notification requested by the-->
<!--sender-->
<!ELEMENT ricevuta EMPTY>
<!ATTLIST ricevuta
      tipo (completa |
            breve   |
            sintetica ) #REQUIRED>

<!--For delivery, non-delivery, virus-induced non-delivery, -->
<!-- virus detection, and timeout PEC notifications-->
<!--Recipient address to which delivery has been carried -->
<!--out/tried-->
<!ELEMENT consegna (#PCDATA)>
<!--For server-server acceptance PEC notifications-->
<!--recipients for whom it is the relative PEC notification-->
<!ELEMENT ricezione (#PCDATA)>

<!--In case of error-->
<!--brief description of the error-->
<!ELEMENT errore-esteso (#PCDATA)>

4.5. PEC Providers Directory Scheme 🗂️✨

okay so the PEC providers directory is basically a big central phonebook 📒 It lives on one centralized LDAP server, and it stores every provider's info along with the PEC mail domains they look after. bestie, this is the thing every server checks when it needs to know who's who 💅

Here are the directory scheme's attributes:

providerCertificateHash: hash of provider's certificate
providerCertificate: provider certificate
providerName: provider name
mailReceipt: provider reception email address
managedDomains: managed domains
LDIFLocationURL: provider LDIF record URL
providerUnit: secondary operating environment name

The directory's base root is o=postacert, and the DistinguishedName of a single record looks like <providerName=<name>,o=postacert> 🌸 Searches are mostly case-sensitive, and they use providerCertificateHash during envelope signature verification or managedDomains during message acceptance 🔍 A single provider's record can hold multiple providerCertificate attributes, each with its own providerCertificateHash. That's how certificate renewals work without anything breaking 🦋 The provider MUST update its record well before the certificate expiration date by adding a new certificate whose validity overlaps the previous one. Overlap is the whole point, no gaps allowed 💖

All the PEC provider data lives in an [LDIF] file. It's served as an [HTTPS] object, and you can find it at the URL that the LDIFLocationURL attribute in the dn: o=postacert record points to (see section 4.5.6) 🧚 For authenticity, the provider MUST sign that file for its PEC services, using the method described for single providers. The file, the signature, and the X.509v3 certificate MUST be put inside a PKCS#7 structure in binary ASN.1 DER format, saved as a file with a .p7m extension 🎀 The central [LDAP] system grabs that file every day and, after checking the signature, applies it to the provider's record 🔥

Through that [LDIF] file, single providers MUST keep a local copy of the directory, updated daily 🫶 Why? Performance! It stops every message from pinging the central system during processing 🚀

If secondary environments exist, the [LDIF] file in the main environment's record MUST relate the contents of every provider-relevant record 🌈

NOTE: This specification uses an unregistered LDAP DN name space that may lead to conflict with other registered or unregistered names.

4.5.1. providerCertificateHash Attribute 🔐

The providerCertificateHash attribute is a hexadecimal representation of the SHA1 hash of the X.509v3 certificate that the provider uses for PEC notifications and envelope signatures 💜

( 1.3.6.1.4.1.16572.2.2.1  NAME 'providerCertificateHash'
  DESC 'Hash SHA1 of X.509 certificate in hexadecimal format'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in [LDAP-SYNTAXES] 📚

4.5.2. providerCertificate Attribute 📜

The providerCertificate attribute holds a set of certificate(s) that the provider uses to sign PEC notifications and transport envelopes ✨

( 1.3.6.1.4.1.16572.2.2.2  NAME 'providerCertificate'
  DESC 'X.509 certificate in ASN.1 DER binary format'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

The Certificate syntax ( 1.3.6.1.4.1.1466.115.121.1.8 ) is defined in [RFC4523] 🎀

Because of this attribute type's syntax, values are requested and transferred using the attribute description providerCertificate;binary [RFC4522] 🤓

4.5.3. providerName Attribute 🏷️

The providerName attribute contains the name of the PEC provider. All records MUST contain their provider's name in this attribute 💅

( 1.3.6.1.4.1.16572.2.2.3  NAME 'providerName'
  DESC 'PEC provider name'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE )

The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is defined in [LDAP-SYNTAXES] 📖

4.5.4. mailReceipt Attribute 📬

The mailReceipt attribute contains the provider's email address inside the provider, which is where server-server acceptance and virus detection PEC notifications get sent 💌 This is a limited version of the addr-spec construct from [EMAIL] (without angle brackets). It only allows the dot-atom-text form on both sides of the "@", and it has no internal CFWS. Very strict, very iconic 🫠

( 1.3.6.1.4.1.16572.2.2.4 NAME 'mailReceipt'
  DESC 'E-mail address of the service mailbox'
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
  SINGLE-VALUE )

The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in [LDAP-SYNTAXES] 🪄

4.5.5. managedDomains Attribute 🌐

The managedDomains attribute holds a set of domains [SMTP] that a PEC provider handles. Domains are limited to dot-atom form ([RFC1034], [EMAIL]) 🗺️

( 1.3.6.1.4.1.16572.2.2.5 NAME 'managedDomains'
  DESC 'Domains handled by the PEC provider'
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

The IA5String ( 1.3.6.1.4.1.1466.115.121.26 ) syntax is defined in [LDAP-SYNTAXES] 🧃

The managedDomains attribute holds a set of domains [SMTP] that a PEC provider handles. Domains are limited to dot-atom form ([RFC1034], [EMAIL]) 🔁 (yes, this bit appears twice in the original, and I'm keeping it that way so nothing gets lost 🙈)

4.5.6. LDIFLocationURL Attribute 🔗

The LDIFLocationURL attribute contains an [HTTPS] URL that points to the location of the [LDIF] file defining the provider's record. When the attribute is present in the record dn: o=postacert, it contains the definition of the entire directory in [LDIF] format 🌟 The LDIF file has a MIME type of application/pkcs7-mime, with the parameter smime-type/signed-data [SMIMEV3]. It's encoded in the UTF-8 character set 🌏

Secondary environment records MUST NOT contain the LDIFLocationURL attribute. That value is taken from the main environment's attributes for all records connected to the provider 🙅‍♀️

( 1.3.6.1.4.1.16572.2.2.6 NAME 'LDIFLocationURL'
  DESC 'URL of the LDIF file that defines the entry'
  EQUALITY caseExactMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE )

The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is defined in [LDAP-SYNTAXES] 📘

4.5.7. providerUnit Attribute 🏢

The providerUnit attribute contains the name of a secondary operating environment. It's not present for the main environment 🫧 A provider can define several distinct records, each one for a different secondary operating environment. Each of those can declare its own attributes, which can be different from the main and other environments if needed 💫

The DistinguishedName of records for secondary operating environments looks like <providerUnits=<environment>,providerName=<name>,o=postacert> 🎀 Every provider MUST have a record for its own main environment. You can spot it because it has no providerUnit attribute and no providerUnits in its DistinguishedName 🫶

( 1.3.6.1.4.1.16572.2.2.7 NAME 'providerUnit'
  DESC 'Name of the secondary operative environment'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE )

The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is defined in [LDAP-SYNTAXES] 🧩

4.5.8. LDIFLocationURLObject Object Class 🧸

Here's the schema definition for the LDIFLocationURLObject object class 👑

( 1.3.6.1.4.1.16572.2.1.1 NAME 'LDIFLocationURLObject'
  SUP top AUXILIARY
  MAY ( LDIFLocationURL ) )

4.5.9. Provider Object Class 🦄

And here's the schema definition for the provider object class 💖

( 1.3.6.1.4.1.16572.2.1.2 NAME 'provider'
  SUP top STRUCTURAL
  MUST ( providerCertificateHash
         providerCertificate
         providerName
         mailReceipt
         managedDomains )

  MAY ( description
        LDIFLocationURL
        providerUnit )

4.5.10. LDIF File Example 🎀

okay so bestie, this is the moment where we actually see the providers' directory come to life 🧚 the first example is a providers' directory with a base root and two fictitious providers. The certificates are two self-signed ones, and they're just for example purposes, so nobody panic 💅

       dn: o=postacert
       objectclass: top
       objectclass: organization
       objectClass: LDIFLocationURLObject
       o: postacert
       LDIFLocationURL: https://igpec.rupa.example.com/igpec.ldif.p7m
       description: Base root for the PEC providers directory
       dn: providerName=Anonymous Certified Mail S.p.A.,o=postacert
       objectclass: top
       objectclass: provider
       providerName: Anonymous Certified Mail S.p.A.
       providerCertificateHash:
        7E7AEF1059AE0F454F2643A95F69EC3556009239
       providerCertificate;binary::

        MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw
        JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu
        QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX
        J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG
        A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG
        EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh
        bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK
        KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC
        2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf
        alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB
        wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw
        SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT
        AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC
        5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl
        cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B
        Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA
        XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
        5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
       mailReceipt: ssacceptance@postalser.example.com
       LDIFLocationURL: https://anpocert.example.com/anpocert.ldif.p7m
       managedDomains: mail.anpocert.example.com
       managedDomains: cert.company.example.com
       managedDomains: costmec.example.com
       description: Certified mail services for companies

       dn: providerName=Postal Services S.p.A,o=postacert
       objectclass: top
       objectclass: provider
       providerName: Postal Services S.p.A
       providerCertificateHash:
        e00fdd9d88be0e2cc766b893315caf93d5701a6a
       providerCertificate;binary::
        MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEw
        JJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA0GA1UE
        CxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YU
        BzZXJwb3N0YWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjA5MTczMjE2
        WjBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIF
        Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0
        YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQ
        ADgY0AMIGJAoGBAKoc7n6zA+sO8NATMcfJ+U2aoDEsrj/cObG3QAN6Sr+l
        ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIEaYZhYRGjhbcuJ9H/ZdtWdX
        xcwEWN4mwFzlsASogsh5JeqS8db3A1JWkvhO9EUfaCYk8YMAkXYdCtLD9s
        9tCYZeTE2ut9AgMBAAGjgcswgcgwHQYDVR0OBBYEFHPw7VJIoIM3VYhuHa
        eAwpPF5leMMIGYBgNVHSMEgZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leM
        oXKkcDBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YW
        xpIFMuci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5w
        b3N0YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXSCAQAwDAYDVR0TBAUwAw
        EB/zANBgkqhkiG9w0BAQQFAAOBgQApqeXvmOyEjwhMrXezPAXELMZwv4qq
        r5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFwNQMNxYFVJqdWoLh8qExsTLXn
        sKycSnHbCfuphrKvXjQvR2da75U4zGSkroiyvJ2s9TtiCcT3lQtIjmvrFb
        aSBiyzj+za7foFUCQmxCLtDaA==
       mailReceipt: takecharge@postalser.example.com
       LDIFLocationURL: https://postalser.example.com/ldif.txt.p7m
       managedDomains: postal-services.example.com
       managedDomains: receivedmail.example.com
       description: Certified mail services for the public

next up is the second example, and this one is the spicy version 🌶️ same base root, but the first provider now handles a secondary environment too 🦋 the certificates are again two self-signed ones, just for example use, so no real trust drama here 🫶

       dn: o=postacert
       objectclass: top
       objectclass: organization
       objectClass: LDIFLocationURLObject
       o: postacert
       LDIFLocationURL: https://igpec.rupa.example.com/igpec.ldif.p7m
       description: Base root for the PEC providers directory

       dn: providerName=Anonymous Certified Mail S.p.A.,o=postacert
       objectclass: top
       objectclass: provider
       providerName: Anonymous Certified Mail S.p.A.

       providerCertificateHash:
        7E7AEF1059AE0F454F2643A95F69EC3556009239
       providerCertificate;binary::
        MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw
        JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu
        QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX
        J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG
        A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG
        EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh
        bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK
        KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC
        2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf
        alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB
        wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw
        SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT
        AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC
        5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl
        cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B
        Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA
        XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
        5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
       mailReceipt: notifications@anpocert.it.example
       LDIFLocationURL: http://anpocert.example.com/anpocert.ldif.p7m
       managedDomains: mail.anpocert.example.com
       managedDomains: cert.company.example.com
       managedDomains: costmec.example.com
       description: Certified mail services for companies
       dn: providerUnit=Secondary Environment, providerName=Anonymous
        Certified Mail S.p.A.,o=postacert
       objectclass: top
       objectclass: provider
       providerName: Certified Mail S.p.A.
       providerUnit: Secondary Environment
       providerCertificateHash:
        7E7AEF1059AE0F454F2643A95F69EC3556009239
       providerCertificate;binary::
        MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw
        JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu
        QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX
        J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG
        A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG
        EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh
        bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK
        KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC
        2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf
        alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB
        wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw
        SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT
        AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC
        5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl
        cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B
        Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA
        XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
        5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
       mailReceipt: notifications@secondary.anpocert.example.com
       managedDomains: management.anpocert.example.com
       managedDomains: personnel.anpocert.example.com
       description: Corporate internal services
       dn: providerName=Postal Services S.r.l.,o=postacert
       objectclass: top
       objectclass: provider
       providerName: Postal Services S.r.l.
       providerCertificateHash:
        e00fdd9d88be0e2cc766b893315caf93d5701a6a
       providerCertificate;binary::
        MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEw
        JJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA0GA1UE
        CxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YU
        BzZXJwb3N0YWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjA5MTczMjE2
        WjBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIF
        Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0
        YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQ
        ADgY0AMIGJAoGBAKoc7n6zA+sO8NATMcfJ+U2aoDEsrj/cObG3QAN6Sr+l
        ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIEaYZhYRGjhbcuJ9H/ZdtWdX
        xcwEWN4mwFzlsASogsh5JeqS8db3A1JWkvhO9EUfaCYk8YMAkXYdCtLD9s
        9tCYZeTE2ut9AgMBAAGjgcswgcgwHQYDVR0OBBYEFHPw7VJIoIM3VYhuHa
        eAwpPF5leMMIGYBgNVHSMEgZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leM
        oXKkcDBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YW
        xpIFMuci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5w
        b3N0YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXSCAQAwDAYDVR0TBAUwAw
        EB/zANBgkqhkiG9w0BAQQFAAOBgQApqeXvmOyEjwhMrXezPAXELMZwv4qq
        r5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFwNQMNxYFVJqdWoLh8qExsTLXn
        sKycPSnHbCfuphrKvXjQvR2da75U4zGSkroiyvJ2s9TtiCcT3lQtIjmvrF
        baSBiyzj+za7foFUCQmxCLtDaA==
       mailReceipt: ssacceptance@postalser.example.com
       LDIFLocationURL: http://postalser.example.com/ldif.txt.p7m
       managedDomains: postal-services.example.com
       managedDomains: receivedmail.example.com
       description: Certified mail services for the public

5.1. Digital Signature

okay security time, and this part is honestly really important 🔐 it's recommended that a dedicated hardware module handles the private key and the signature operations. the specs for that hardware are outside the scope of this doc, so it's not our problem here 🙈 but the PEC providers are the ones on the hook for meeting the security requirements the service is expected to have 💅

5.2. Authentication

⚠️ this one is a MUST, bestie: user access to PEC services through the Access Point MUST be allowed only upon successful user authentication on the system. no login, no entry, periodt 🚪

for example, authentication could use a user-ID and password. or, if it's available and makes sense for the kind of service being offered, an electronic ID card or the national services card 🪪 the choice of method is left to the better judgment of the service provider 🧠 authentication is what helps make sure a message really comes from a PEC user whose identity matches the sender they claim, so nobody can fake the sender 🫣

5.3. Secure Interaction

okay bestie, the whole point here is making sure the original message doesn't get messed with on its way through the PEC system 💌 Outgoing messages get enveloped and signed at the Access Point, and incoming messages get verified at the Incoming Point 🔐

Every communication inside the PEC network MUST use secure channels, no exceptions 🔒 The connection between the PEC provider and the user MUST be guaranteed for integrity and confidentiality using secure protocols. Think protocols based on [TLS], or ones that build a secure transport channel that non-secure protocols can ride on (IPsec is the example they give) 🛡️

The chat between providers MUST happen over SMTP on [TLS], as per [SMTP-TLS] 💅 The Incoming Point MUST provide and announce support for the STARTTLS extension, and it also has to accept both unencrypted connections (for ordinary mail) and protected ones. For complete traceability, PEC messages MUST NOT transit on systems outside the PEC network 🕵️‍♀️ When messages go between different providers, every transaction MUST happen between machines that belong to the PEC network or are directly managed by the provider.

A "MX" type record MAY be associated with each PEC domain in the system for name resolution. If one is set up, any secondary reception systems listed in that record MUST be under the provider's direct control. All of this is in conformance with [SMTP] ✨

5.4. Virus

Another big security thing for the PEC system is the architecture itself, which MUST block viruses from putting the handled messages at risk 🦠🚫 It is therefore REQUIRED to have anti-virus systems installed and kept continuously updated, so infections are stopped as much as possible. The rule is that they can't touch the content of the certified mail, which keeps everything in line with what we've covered so far 🧼

5.5. S/MIME Certificate

This document defines the S/MIME certificate profile for certifying PEC messages done by the providers 📜 The profile is based on the IETF standards [SMIMECERT] and [CRL], which in turn are based on the standard ISO/IEC 9594-8:2001 🌸

The info about the PEC provider who holds the certificate MUST go in the Subject field (Subject DN) 🎀 To be precise, the Subject DN MUST contain the PEC provider's name exactly as it appears in the "providerName" attribute in the PEC providers directory (section 4.5). The Subject DN does not have to match the Provider entry DN in the LDIF, though. The providerName MUST be present in the CommonName or OrganizationName attributes of the "Subject:" field in the certificate.

Certificates MUST contain an Internet mail address, which MUST have a value in the subjectAltName extension. It SHOULD NOT be present in the Subject Distinguished Name 🙈

Valid subjectDNs are:

C=IT, O=AcmePEC S.p.A, CN=Posta Certificata

C=IT, O=ServiziPEC S.p.A, CN=Posta Certificata

If other attributes are valorized in the Subject DN, that MUST be done in compliance with [CRL] 💜

5.5.2. Certificate Extensions

These extensions MUST be present in the S/MIME certificate, no skipping 👑

Key Usage
Authority Key Identifier
Subject Key Identifier
Subject Alternative Name

The Basic Constraints extension (Object ID:2.5.29.19) MUST NOT be present 🚫

Here's how the listed extensions are valorized for this profile ✨

The Key Usage extension (Object ID: 2.5.29.15) MUST have the digitalSignature bit (bit 0) activated, and it MUST be marked as critical. It MAY contain other active bits for different Key Usages, as long as that doesn't contrast with the indications in [CRL] 🔥

The Authority Key Identifier (Object ID: 2.5.29.35) MUST contain at least the keyIdentifier field, and it MUST NOT be marked as critical.

The Subject Key Identifier extension (Object ID: 2.5.29.14) MUST contain at least the keyIdentifier field, and it MUST NOT be marked as critical.

The Subject Alternative Name (Object ID: 2.5.29.17) MUST contain at least the rfc822Name field, and it MUST NOT be marked as critical.

Adding other extensions that aren't described in this document is OPTIONAL, as long as it stays compliant with [CRL]. Those added extensions MUST NOT be marked as critical 🦋

5.5.3. Example

Here's an S/MIME certificate that meets the minimal requirements of this profile 🧚 All the values come from fictitious providers made up purely for example purposes, so nobody panic 😭

5.5.3.1. General-Use Certificate in Annotated Version

An asterisk next to an extension's label means that extension has been marked as critical ⭐

    VERSION: 3
    SERIAL: 11226 (0x2bda)
    INNER SIGNATURE:
      ALG. ID: id-sha1-with-rsa-encryption
      PARAMETER: 0
    ISSUER:
      Country Name: IT
      Organization Name: Certifier 1
      Organizational Unit Name: Certification Service Provider
      Common Name: Certifier S.p.A.
    VALIDITY:
      Not Before: Oct 5, 04 09:04:23 GMT
      Not After: Oct 5, 05 09:04:23 GMT
    SUBJECT:
      Country Name: IT
      Organization Name: AcmePEC S.p.A.
      Common Name: Certified Mail
    PUBLIC KEY: (key size is 1024 bits)
    ALGORITHM:
      ALG. ID: id-rsa-encryption
      PARAMETER: 0
    MODULUS: 0x00afbeb4 5563198a aa9bac3f 1b29b5be
             7f691945 89d01569 ca0d555b 5c33d7e9
             ...
             d15ff128 6792def5 b3f884e6 54b326db
             cf
    EXPONENT: 0x010001
    EXTENSIONS:
      Subject Alt Name:
      RFC Name: posta-certificata@acmepec.it
      Key Usage*: Digital Signature
      Authority Key Identifier: 0x12345678 aaaaaaaa bbbbbbbb
                                cccccccc dddddddd
      Subject Key Identifier: 0x3afae080 6453527a 3e5709d8 49a941a8
                              a3a70ae1
    SIGNATURE:
      ALG. ID: id-sha1-with-rsa-encryption
      PARAMETER: 0
      VALUE: 0x874b4d25 70a46180 c9770a85 fe7923ce
             b22d2955 2f3af207 142b2aba 643aaa61
             ...
             d8fd10b4 c9e00ebc c089f7a3 549a1907
             ff885220 ce796328 b0f8ecac 86ffb1cc

5.5.3.2. General-Use Certificate in Dump ASN.1

This is the same certificate as a raw ASN.1 dump, for the nerds who want the bytes 🤓💖

 0 30  794: SEQUENCE {
 4 30  514:  SEQUENCE {
 8 A0   3:   [0] {
10 02  1:    INTEGER 2
   :      }
13 02  2:   INTEGER 11226
17 30   13:  SEQUENCE {
19 06  9:    OBJECT IDENTIFIER
   :      sha1withRSAEncryption (1 2 840 113549 1 1 5)
30 05  0:    NULL
   :    }
32 30  101:  SEQUENCE {
34 31   11:   SET {
36 30   9:     SEQUENCE {
38 06   3:      OBJECT IDENTIFIER countryName (2 5 4 6)
43 13   2:      PrintableString 'IT'
   :      }
   :    }
47 31   28:   SET {
49 30   26:    SEQUENCE {
51 06   3:      OBJECT IDENTIFIER organizationName (2 5 4 10)
56 13   19:     PrintableString 'Certificatore 1'
   :      }
   :    }
77 31   22:   SET {
79 30   20:    SEQUENCE {
81 06   3:   OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
86 13   13:    PrintableString 'Certification Service Provider'
   :      }
   :    }
101 31  32:   SET {
103 30  30:    SEQUENCE {
105 06  3:      OBJECT IDENTIFIER commonName (2 5 4 3)
110 13  23:     PrintableString 'Certificatore S.p.A.'
   :      }
   :    }
   :  }
135 30  30:  SEQUENCE {
137 17  13:   UTCTime '041005090423Z'
152 17  13:   UTCTime '051005090423Z'
   :     }
167 30  66:  SEQUENCE {
169 31  11:   SET {
171 30  9:     SEQUENCE {
173 06  3:      OBJECT IDENTIFIER countryName (2 5 4 6)
178 13  2:      PrintableString 'IT'
   :      }
   :    }
182 31  23:  SET {
184 30  21:   SEQUENCE {
186 06  3:     OBJECT IDENTIFIER organizationName (2 5 4 10)
191 13  14:    PrintableString 'AcmePEC S.p.A.'
   :      }
   :    }
207 31  26:  SET {
209 30  24:   SEQUENCE {
211 06  3:     OBJECT IDENTIFIER commonName (2 5 4 3)
216 13  17:    PrintableString 'Posta Certificata'
   :      }
   :    }
   :  }
235 30  159: SEQUENCE {
238 30  13:   SEQUENCE {
240 06  9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549
              1 1 1)
251 05  0:     NULL
   :      }
253 03  141:  BIT STRING 0 unused bits
   :     30 81 89 02 81 81 00 AF BE B4 55 63 19 8A AA 9B
   :     AC 3F 1B 29 B5 BE 7F 69 19 45 89 D0 15 69 CA 0D
   :     55 5B 5C 33 D7 E9 C8 6E FC 14 46 C3 C3 09 47 DD
   :     CD 10 74 1D 76 4E 71 14 E7 69 42 BE 1C 47 61 85
   :     4D 74 76 DD 0B B5 78 4F 1E 84 DD B4 86 7F 96 DF
   :     5E 7B AF 0E CE EA 12 57 0B DF 9B 63 67 4D F9 37
   :     B7 48 35 27 C2 89 F3 C3 54 66 F7 DA 6C BE 4F 5D
   :     85 55 07 A4 97 8C D1 5F F1 28 67 92 DE F5 B3 F8
   :         [ Another 12 bytes skipped ]
   :    }
397 A3  123: [3] {
399 30  121:  SEQUENCE {
401 30  39:    SEQUENCE {
403 06  3:      OBJECT IDENTIFIER subjectAltName (2 5 29 17)
408 04  32:     OCTET STRING
   :      30 1E 81 1C 70 6F 73 74 61 2D 63 65 72 74 69 66
   :      69 63 61 74 61 40 61 63 6D 65 70 65 63 2E 69 74
   :     }
442 30  14:   SEQUENCE {
444 06  3:     OBJECT IDENTIFIER keyUsage (2 5 29 15)
449 01  1:     BOOLEAN TRUE
452 04  4:     OCTET STRING
   :      03 02 07 80
   :      }
458 30  31:   SEQUENCE {
460 06  3:  OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
465 04  24:    OCTET STRING
   :     30 16 11 11 11 11 AA AA AA AA AA BB BB BB BB CC CC
   :     CC CC DD DD DD DD
   :      }
491 30  29:   SEQUENCE {
493 06  3:    OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
498 04  22:    OCTET STRING
   :      04 14 3A FA E0 80 64 53 52 7A 3E 57 09 D8 49 A9
   :      41 A8 A3 A7 0A E1
   :      }
   :     }
   :    }
   :   }
522 30  13: SEQUENCE {
524 06  9:   OBJECT IDENTIFIER
   :      sha1withRSAEncryption (1 2 840 113549 1 1 5)
535 05  0:   NULL
   :    }
537 03  257: BIT STRING 0 unused bits
   :     87 4B 4D 25 70 A4 61 80 C9 77 0A 85 FE 79 23 CE
   :     B2 2D 29 55 2F 3A F2 07 14 2B 2A BA 64 3A AA 61
   :     1F F0 E7 3F C4 E6 13 E2 09 3D F0 E1 83 A0 C0 F2
   :     C6 71 7F 3A 1C 80 7F 15 B3 D6 1E 22 79 B8 AC 91
   :     51 83 F2 3A 84 86 B6 07 2B 22 E8 01 52 2D A4 50
   :     9F C6 42 D4 7C 38 B1 DD 88 CD FC E8 C3 12 C3 62
   :     64 0F 16 BF 70 15 BC 01 16 78 30 2A DA FA F3 70
   :     E2 D3 0F 00 B0 FD 92 11 6C 55 45 48 F5 64 ED 98
   :         [ Another 128 bytes skipped ]
   : }

5.6. PEC Providers Directory

The contents of the PEC providers directory MUST be queried via [HTTP] on a Secure Socket Layer (SSL), as described in [TLS] 🔐✨ Only licensed providers that have the necessary user certificates get access, because this setup guarantees authenticity, integrity, and confidentiality of the data 💅 Each provider downloads the LDIF file through an [HTTPS] session, and that session is authenticated by checking the X.509 certificate issued by a certification authority 🌈

6. PEC System Client Technical and Functional Prerequisites ✨

okay so this section is the checklist for what a client has to cover so the user gets the basic PEC features 💅 the client must handle these things:

handling of Access and Delivery Points through secure channels 🔐
handling of user authentication in message dispatch and reception which make use of standard protocols, such as [IMAP], [POP3], and [HTTP] 🗝️
support for MIME format according to [MIME1] and [MIME5] 🎀
support for "ISO-8859-1 (Latin-1)" character set 🌸
support for S/MIME v3 standard, as in [SMIMEV3], for verification of signatures applied to PEC envelopes and notifications ✉️

7. Security Considerations 🔥

ngl this part is giving serious dramatic energy, so read it carefully bestie 🙈

all security considerations from [CMS] and [SMIMEV3] apply to any application that uses the procedures in this document. no escaping them 💀

the centralized LDAP server is the critical point for the whole PEC system 👑 if someone attacks it, they could compromise the entire PEC system, and that's a whole disaster. PEC providers that periodically download the LDIF file SHOULD use the best security technology to protect it from local attacks 🛡️ a PEC provider could also get compromised if an attacker changed a certificate or edited the list of domains tied to it in the LDIF file that was copied over to the PEC provider system. literally the worst plot twist 😭

when verifying the validity of a message signature, the recipient system SHOULD verify that the certificate included in the [CMS] message is present in the LDIF file (section 4.5), and that the domain pulled from the [EMAIL] "From:" header is listed in the managedDomains attribute associated with that certificate 🔍 double-checking is the whole vibe 💖

8. IANA Considerations 🦋

8.1. Registration of PEC Message Header Fields

this document defines new header fields used in the messages that transit the PEC network 💌 as specified and required by [HEADERS-IANA], this document registers the new header fields as Provisional Message Header Fields, as follows:

8.1.1. Header Field: X-Riferimento-Message-ID:

Applicable protocol: mail [EMAIL]

Status: provisional

Author/Change controller:

   Claudio Petrucci
   DigitPA
   Viale Carlo Marx 31/49
   00137 Roma
   Italy
   EMail: PETRUCCI@digitpa.gov.it

Specification document: this document, section 2.2.1, Appendix A.

8.1.2. Header Field: X-Ricevuta:

Applicable protocol: mail [EMAIL]

Status: provisional

Author/Change controller:

   Claudio Petrucci
   DigitPA
   Viale Carlo Marx 31/49
   00137 Roma
   Italy
   EMail: PETRUCCI@digitpa.gov.it

Specification document: this document, sections 2.1.1.1.1, 3.1.2,
                        3.1.3, 3.1.4, 3.1.6, 3.2.1, 3.2.3, 3.2.4,
                        3.3.2, 3.3.3, Appendix A.

8.1.3. Header Field: X-VerificaSicurezza:

Applicable protocol: mail [EMAIL]

Status: provisional

Author/Change controller:

   Claudio Petrucci
   DigitPA
   Viale Carlo Marx 31/49
   00137 Roma
   Italy
   EMail: PETRUCCI@digitpa.gov.it

Specification document: this document, sections 2.1.1.1.3, 3.1.3,
                        3.2.4, Appendix A.

8.1.4. Header Field: X-Trasporto:

Applicable protocol: mail [EMAIL]

Status: provisional

Author/Change controller:

   Claudio Petrucci
   DigitPA
   Viale Carlo Marx 31/49
   00137 Roma
   Italy
   EMail: PETRUCCI@digitpa.gov.it

Specification document: this document, sections 3.1.5, 3.2.2,
                        Appendix A.

8.1.5. Header Field: X-TipoRicevuta:

Applicable protocol: mail [EMAIL]

Status: provisional

Author/Change controller:

   Claudio Petrucci
   DigitPA
   Viale Carlo Marx 31/49
   00137 Roma
   Italy
   EMail: PETRUCCI@digitpa.gov.it

Specification document: this document, sections 3.1.5, 3.3.2,
                        3.3.2.1, 3.3.2.2, 3.3.2.3, Appendix A.

8.1.6. Header Field: X-Mittente:

Applicable protocol: mail [EMAIL]

Status: provisional

Author/Change controller:

   Claudio Petrucci
   DigitPA
   Viale Carlo Marx 31/49
   00137 Roma
   Italy
   EMail: PETRUCCI@digitpa.gov.it

Specification document: this document, sections 3.2.3, Appendix A.

8.2. Registration of LDAP Object Identifier Descriptors

this document defines new LDAP attributes and object classes for object identifier descriptors 🧩 as specified and required by [LDAP-IANA], this document registers new descriptors as follows, per the Expert Review.

8.2.1. Registration of Object Classes and Attribute Types

Subject: Request for LDAP Descriptor Registration

Descriptor (short name): See comments

Object Identifier: See comments

Person & email address to contact for further information:
   See "Author/Change Controller"

Usage: See comments
Specification: (I-D)

Author/Change Controller:

   Claudio Petrucci
   DigitPA
   Viale Carlo Marx 31/49
   00137 Roma
   Italy
   EMail: PETRUCCI@digitpa.gov.it

Comments:

   The following object identifiers and associated object classes/
   attribute types are requested to be registered.

OID                         Descriptor              Usage
------------------------    ---------------------   ------
1.3.6.1.4.1.16572.2.1.1     LDIFLocationURLObject      O
1.3.6.1.4.1.16572.2.1.2     provider                   O
1.3.6.1.4.1.16572.2.2.1     providerCertificateHash    A
1.3.6.1.4.1.16572.2.2.2     providerCertificate        A
1.3.6.1.4.1.16572.2.2.3     providerName               A
1.3.6.1.4.1.16572.2.2.4     mailReceipt                A
1.3.6.1.4.1.16572.2.2.5     managedDomains             A
1.3.6.1.4.1.16572.2.2.6     LDIFLocationURL            A
1.3.6.1.4.1.16572.2.2.7     providerUnit               A

Legend
-------------------
O => Object Class
A => Attribute Type

9. References 📚

9.1. Normative References

[ABNF]          Crocker, D., Ed., and P. Overell, "Augmented BNF for
                Syntax Specifications: ABNF", STD 68, RFC 5234,
                January 2008.

[CMS]           Housley, R., "Cryptographic Message Syntax (CMS)",
                STD 70, RFC 5652, September 2009.

[CRL]           Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation
                List (CRL) Profile", RFC 5280, May 2008.

[EMAIL]         Resnick, P., Ed., "Internet Message Format", RFC
                5322, October 2008.

[HEADERS-IANA]  Klyne, G., Nottingham, M., and J. Mogul,
                "Registration Procedures for Message Header Fields",
                BCP 90, RFC 3864, September 2004.

[HTTP]          Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                Masinter, L., Leach, P., and T. Berners-Lee,
                "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
                June 1999.

[HTTPS]         Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[IMAP]          Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
                VERSION 4rev1", RFC 3501, March 2003.

[LDAP]          Zeilenga, K., Ed., "Lightweight Directory Access
                Protocol (LDAP): Technical Specification Road Map",
                RFC 4510, June 2006.

[LDAP-IANA]     Zeilenga, K., "Internet Assigned Numbers Authority
                (IANA) Considerations for the Lightweight Directory
                Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

[LDAP-SYNTAXES] Legg, S., Ed., "Lightweight Directory Access Protocol
                (LDAP): Syntaxes and Matching Rules", RFC 4517, June
                2006.

[LDIF]          Good, G., "The LDAP Data Interchange Format (LDIF) -
                Technical Specification", RFC 2849, June 2000.

[MIME1]         Freed, N. and N. Borenstein, "Multipurpose Internet
                Mail Extensions (MIME) Part One: Format of Internet
                Message Bodies", RFC 2045, November 1996.

[MIME5]         Freed, N. and N. Borenstein, "Multipurpose Internet
                Mail Extensions (MIME) Part Five: Conformance
                Criteria and Examples", RFC 2049, November 1996.

[SUBMISSION]    Gellens, R. and J. Klensin, "Message Submission for
                Mail", RFC 4409, April 2006.

[POP3]          Myers, J. and M. Rose, "Post Office Protocol -
                Version 3", STD 53, RFC 1939, May 1996.

[REQ]           Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[SHA1]          Eastlake 3rd, D. and P. Jones, "US Secure Hash
                Algorithm 1 (SHA1)", RFC 3174, September 2001.

[MIME-SECURE]   Galvin, J., Murphy, S., Crocker, S., and N. Freed,
                "Security Multiparts for MIME: Multipart/Signed and
                Multipart/Encrypted", RFC 1847, October 1995.

[SMIMEV3]       Ramsdell, B. and S. Turner, "Secure/Multipurpose
                Internet Mail Extensions (S/MIME) Version 3.2 Message
                Specification", RFC 5751, January 2010.

[SMIMECERT]     Ramsdell, B. and S. Turner, "Secure/Multipurpose
                Internet Mail Extensions (S/MIME) Version 3.2
                Certificate Handling", RFC 5750, January 2010.

[SMTP]          Klensin, J., "Simple Mail Transfer Protocol", RFC
                5321, October 2008.

[SMTP-DSN]      Moore, K., "Simple Mail Transfer Protocol (SMTP)
                Service Extension for Delivery Status Notifications
                (DSNs)", RFC 3461, January 2003.

[SMTP-TLS]      Hoffman, P., "SMTP Service Extension for Secure SMTP
                over Transport Layer Security", RFC 3207, February
                2002.

[TIMESTAMP]     Klyne, G. and C. Newman, "Date and Time on the
                Internet: Timestamps", RFC 3339, July 2002.

[TLS]           Dierks, T. and E. Rescorla, "The Transport Layer
                Security (TLS) Protocol Version 1.2", RFC 5246,
                August 2008.

[XML]           W3C, "Extensible Markup Language (XML) 1.0 (Fifth
                Edition)", W3C Recommendation, November 2008,
                <http://www.w3.org/TR/2006/REC-xml-20060816/>.

9.2. Informative References

[RFC1034]       Mockapetris, P., "Domain names - concepts and
                facilities", STD 13, RFC 1034, November 1987.

[RFC4522]       Legg, S., "Lightweight Directory Access Protocol
                (LDAP): The Binary Encoding Option", RFC 4522, June
                2006.

[RFC4523]       Zeilenga, K., "Lightweight Directory Access Protocol
                (LDAP) Schema Definitions for X.509 Certificates",
                RFC 4523, June 2006.

10. Acknowledgments 🫶

the Italian document this one is based on was a team effort from lots of people 🇮🇹 it was supervised by the National Center for Informatics in the Public Administration of Italy (DigitPA). big thank-you energy all around 🌈

Appendix A. Italian Fields and Values in English ✨

Okay bestie, this appendix is a little translation cheat sheet 🌸 The right-hand column is only there so you can read the Italian stuff more easily. The header fields you actually MUST use are the ones on the left, so don't get it twisted 💅

X-Riferimento-Message-ID        Reference Message Identifier
X-Ricevuta                      Notification
  non-accettazione                non acceptance
  accettazione                    server-user acceptance
  preavviso-errore-consegna       delivery error advance notice
  presa-in-carico                 server-server acceptance
  rilevazione-virus               virus detection
  errore-consegna                 delivery error
  avvenuta-consegna               message delivered
X-Mittente                      Sender
X-VerificaSicurezza             Security Verification
  errore                          error
X-Trasporto                     Transport
  posta-certificata               certified mail
  errore                          error
X-TipoRicevuta                  Notification Type
  completa                        complete
  breve                           brief
  sintetica                       concise

certificatore                   certificator

Here are the Subject values, which are the ones that show up in the subject line. The Italian is on the left and the English is on the right, so it's giving bilingual vibes 🦋

  Accettazione                   SERVER-USER ACCEPTANCE
  Posta certificata              CERTIFIED MAIL
  Presa in carico                SERVER-SERVER ACCEPTANCE
  Consegna                       DELIVERY
  Anomalia messaggio             MESSAGE ANOMALY
  Problema di sicurezza          SECURITY PROBLEM
  Avviso di non accettazione     NON ACCEPTANCE PEC NOTIFICATION
  Avviso di non accettazione     VIRUS DETECTION INDUCED NON
  per virus                      ACCEPTANCE PEC NOTIFICATION
  Avviso di mancata consegna     NON DELIVERY PEC NOTIFICATION
  Avviso di mancata consegna     NON DELIVERY DUE TO VIRUS PEC
  per virus                      NOTIFICATION
  Avviso di mancata consegna     NON DELIVERY DUE TO TIMEOUT PEC
  per sup. tempo massimo         NOTIFICATION

And last but not least, these are the Italian terms in the DTD for the certification XML file. Honestly the naming is iconic 🎀

  accettazione                   server-user acceptance
  altro                          other
  avvenuta-consegna              delivered
  certificato                    certificate
  consegna                       delivery
  data                           date
  dati                           data
  destinatari                    recipients
  esterno                        external
  errore                         error
  errore-consegna                delivery error
  errore-esteso                  extensive error
  gestore-emittente              transmitting provider
  giorno                         day
  identificativo                 identifier
  intestazione                   header
  mittente                       sender
  no-dest(inatario)              no recipient
  no-dominio                     no domain
  non-accettazione               non acceptance
  nessuno                        none
  oggetto                        subject
  ora                            hour
  posta-certificata              certified mail
  preavviso-errore-consegna      delivery error advance notice
  presa-in-carico                server-server acceptance
  ricevuta                       notification
  ricezione                      receipt (the act of receiving)
  rilevazione-virus              virus detection
  risposte                       replies
  tipo                           type

Authors' Addresses 💖

Meet the girlies who wrote this one 🧚 Here are their addresses, so you can reach out if you have questions 💌

Claudio Petrucci
DigitPA
Viale Marx 31/49
00137 Roma
Italy

EMail: petrucci@digitpa.gov.it


Francesco Gennai
ISTI-CNR
Via Moruzzi, 1
56126 Pisa
Italy

EMail: francesco.gennai@isti.cnr.it


Alba Shahin
ISTI-CNR
Via Moruzzi, 1
56126 Pisa
Italy

EMail: alba.shahin@isti.cnr.it


Alessandro Vinciarelli
Via delle Vigne di Morena 113
00118 Roma
Italy

EMail: alessandro.vinciarelli@gmail.com

That's the whole thing, bestie 🌈👑 You made it through the entire RFC, and honestly you're a whole protocol genius now 🫶

📦 where this page comes from

ietf: rfc6109 2011-04
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 6109

RFC 6109: La Posta Elettronica Certificata 💌

Abstract

Status of This Memo

Copyright Notice

Table of Contents 📑

1. Introduction ✨

1.1. Scope

1.2. Notational Conventions

1.2.1. Requirement Conventions

1.2.2. Acronyms

1.2.3. Terminology and Definitions

2. PEC Model ✨

2.1. System-Generated Messages

2.1.1. Message Types

2.1.1.1. PEC Notifications

2.1.1.1.1. Success PEC Notifications

2.1.1.1.2. Delay PEC Notifications

2.1.1.1.3. Failure PEC Notifications ❌

2.1.1.2. PEC Envelopes 📮

2.2. Basic Structure 🧱

2.2.1. Access Point 👀

2.2.2. Incoming Point 🚪

2.2.3. Delivery Point ✨

2.2.4. Storage 🗄️

2.2.5. Provider Service Mailbox 📮

2.2.6. Provider Service Email Address ✉️

2.3. Log 📝

3. Message Processing 💫

3.1. Access Point 🚪

3.1.1. Formal Checks on Messages 📋

3.1.2. Non-Acceptance PEC Notification Due to Formal Exceptions 🚫

3.1.3. Non-Acceptance PEC Notification Due to Virus Detection 🦠

3.1.4. Server-User Acceptance PEC Notification 🎉

3.1.5. PEC Transport Envelope 💜

3.1.6. Timeout Delivery Error PEC Notification ⏰

3.2. Incoming Point 📥

3.2.1. Server-Server Acceptance PEC Notification 🎀

3.2.2. PEC Anomaly Envelope 🧁

3.2.3. Virus Detection PEC Notification 🦠

3.2.4. Virus-Induced Delivery Error PEC notification 🦋

3.3. Delivery Point 📬

3.3.1. Checks on Incoming Messages 👑

3.3.2. Delivery PEC Notification ✨

3.3.2.1. Delivery PEC Notification: Complete

3.3.2.2. Delivery PEC Notification: Brief

3.3.2.3. Delivery PEC Notification: Concise

3.3.3. Non-Delivery PEC Notification 💌

3.4. Sender and Receiver Belonging to the Same Domain 🏠

3.5. Example: Complete Transaction between Two PEC Domains 🦋

4. Formats 🎀

4.1. Temporal Reference ⏰

4.2. User Date/Time 📅

4.3. Format of a PEC Message Body 📨

4.3.1. User Readable Text 📝

4.3.2. Original Message 💬

4.3.3. Certification Data 🔏

4.4. Certification Data Scheme 🧾

4.5. PEC Providers Directory Scheme 🗂️✨

4.5.1. providerCertificateHash Attribute 🔐

4.5.2. providerCertificate Attribute 📜

4.5.3. providerName Attribute 🏷️

4.5.4. mailReceipt Attribute 📬

4.5.5. managedDomains Attribute 🌐

4.5.6. LDIFLocationURL Attribute 🔗

4.5.7. providerUnit Attribute 🏢

4.5.8. LDIFLocationURLObject Object Class 🧸

4.5.9. Provider Object Class 🦄

4.5.10. LDIF File Example 🎀

5. Security-Related Aspects 🔒

5.1. Digital Signature

5.2. Authentication

5.3. Secure Interaction

5.4. Virus

5.5. S/MIME Certificate

5.5.1. Provider-Related Information (Subject)

5.5.2. Certificate Extensions

5.5.3. Example

5.5.3.1. General-Use Certificate in Annotated Version

5.5.3.2. General-Use Certificate in Dump ASN.1