RFC 6109
La Posta Elettronica Certificata - Italian Certified Electronic Mail
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 receives a message the user wishes to send, it MUST guarantee said message's formal conformity as defined in [EMAIL], and verify that the: o [EMAIL] header section contains a "From:" header field holding an [EMAIL] compliant email address; o [EMAIL] header section contains a "To:" header field holding one or more [EMAIL] compliant email addresses; o sender's address, specified in the SMTP reverse path, coincides with the one in the message's "From:" header field; o recipients' addresses specified in the SMTP forward path coincide with the ones present in the "To:" or "Cc:" header fields of the message; o "Bcc:" header field does not contain any value; o total message size falls within the limits accepted by the provider. Such limits apply depending on the number of recipients as well; by multiplying it to the message size, the outcome MUST fall within the limits accepted by the provider. Italian laws have specified this limit as being 30 MB.
If the message does not pass the tests, the Access Point MUST NOT accept the message within the PEC system, thus emitting the relative PEC notification of non-acceptance.3.1.2. Non-Acceptance PEC Notification Due to Formal Exceptions
When the Access Point cannot forward the message received due to failure in passing formal checks, the sender is notified of such an outcome. If the error is caused by the message failing size checks, a non-acceptance PEC notification is sent as long as the size remains bound by a certain limit. If the size exceeds said limit, error handling is left to SMTP. The notification header will contain the following 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 will contain a text part that constitutes the actual notification in readable format according to a model that relates the following information: 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 information is inserted in an XML file to be added to the notification body, thus allowing automatic checks on the message (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.
3.1.3. Non-Acceptance PEC Notification Due to Virus Detection
The Access Point MUST run some tests on the content of messages it receives from its users and reject them if a virus is detected. In which case, a virus-detection-induced non-acceptance PEC notification MUST be emitted to clearly inform the user of the reason the message was refused. The notification header contains the following 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 contains a readable text part according to the following 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 is inserted in an XML file added to the notification to allow for automatic checks (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.3.1.4. Server-User Acceptance PEC Notification
The server-user acceptance PEC notification is a message sent to the sender by his server, containing date and time of message acceptance into the system, sender and recipient data, and subject.
The header contains the following 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 message body contains a text part that constitutes the
notification in readable format, according to a model that relates
the following information:
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 is inserted in an XML file added to the
notification message, allowing automatic checks 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 generated by the Access Point
that contains the original message as well as certification data.
As mentioned in section 2.1.1.2, the PEC transport envelope inherits
from the original message the values of the following header fields,
which MUST be related unmodified:
o Received:
o To:
o Cc:
o Return-Path:
o 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 indicates the type of delivery PEC
notification the sender wishes to receive -- complete, brief, or
concise.
The body of the PEC transport envelope contains a text part that
constitutes the readable format of the message according to a model
that relates the following certification data:
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]
Within the PEC transport envelope, the entire, non-modified original
message is inserted in a format compliant with [EMAIL] (except for
what has been said regarding the message identifier), as well as an
XML part, which contains the certification data that was already
related in text format, and information 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) remain unaltered.
3.1.6. Timeout Delivery Error PEC Notification
If the sending provider doesn't receive a server-server acceptance or delivery PEC notification from the receiving provider within 12 hours of the message dispatch, it informs the user that the recipient's provider might not be able to deliver the message. In case the sending provider doesn't receive a delivery PEC notification within 24 hours after message dispatch, it emits another non-delivery PEC notification to the user by the 24-hour timeout, but not before 22 hours have passed. Such a communication takes place through a PEC notification of non- delivery due to timeout, the header of which contains the following fields: 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 non-delivery PEC notification (12-hour timeout) contains a text part that represents the readable format of the notification which will relate the following data: 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] On the other hand, 24-hour-timeout induced PEC notifications, which have the same header as described above, will have the following text in their body:
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 is inserted in an XML file added to both
PEC notification types to allow 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.
A timeout PEC notification is generated if one of the following
scenarios occurs:
o the sending provider receives a server-server acceptance PEC
notification during the first 12 hours following message dispatch,
but does not receive a delivery PEC notification at all. In this
case, it would be a 24-hour timeout PEC notification.
o the sending provider does not receive a server-server acceptance
PEC notification, but receives a delivery PEC notification after
12 hours and before the 24-hour timeout. In this case it would be
a 12-hour timeout PEC notification.
o the sending provider doesn't receive 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. The single
dispatched notification concerns all recipients who belong to the
same provider, and to whom the incoming message was addressed, as
stated in the routing data (forward and reverse paths) of the SMTP
transaction. Within the certification data of a single server-server
acceptance PEC notification, all recipients of the message to which
it refers are listed. In general, when receiving a PEC transport
envelope, each provider MUST emit one or more server-server
acceptance PEC notifications to cover, in absence of SMTP transport
errors, all the recipients in its jurisdiction.
The header of a server-server acceptance PEC notification contains
the following 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 is obtained from the PEC
providers directory during the necessary queries made in the
signature verification stage.
The body contains a text part that follows the underlying 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 is inserted in an XML file which is added
to the notification message to allow for automatic checks (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 detect an error, or the message
is identified as being ordinary mail and the provider is set to
forward it to the recipient, the system MUST insert such a message in
a PEC anomaly envelope. Before delivery, the entire message received
at the Incoming Point is inserted in a format compliant with [EMAIL] as a [MIME1] part inside a new message that MUST inherit the unmodified values for the following header fields from the received message: o Received: o To: o Cc: o Return-Path: o 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 contains a user-readable text part according to a model that relates the following data: 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. Due to uncertainty regarding origin and/or conformity of the message received, the PEC anomaly envelope MUST NOT contain [MIME1] parts other than the entire message that arrived at the Incoming Point. Note that the routing data of such an envelope (forward and reverse paths) remain unaltered. Doing so guarantees both message forwarding to the recipients, and reception of SMTP error notifications, if any occur, by the sender (as specified in [SMTP] and [SMTP-DSN]).
3.2.3. Virus Detection PEC Notification
If the Incoming Point receives virus-infected PEC messages, it MUST NOT forward them. Rather it MUST inform the sending provider, which will in turn inform the sending user, of the failed transmission. A separate PEC notification of virus detection MUST be sent on behalf of every recipient within the provider's domain. In case a virus is detected during the reception phase of a message whose origin was asserted through sender signature verification, the system generates a virus-detected PEC notification indicating the error found, and sends it to the sending provider's service mailbox. The header of this PEC notification contains the following 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 contains a readable text part according to a model that relates the following data: 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 is inserted in an XML file and added to the notification to allow for automatic checks (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 for which the transmission could not be completed.
3.2.4. Virus-Induced Delivery Error PEC notification
At the reception of a virus detection PEC notification from the receiving provider, the sender provider emits a non-delivery PEC notification to the sending user. The header for this notification contains the following 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 contains a readable text part according to a model that relates the following data: 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 information necessary for the construction of such a PEC notification can be obtained from the correlated virus-detected PEC notification. The same certification data is inserted in an XML file and added to the notification message to allow for automatic checks (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, which 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: o message type o whether or not a PEC notification has to be returned.3.3.2. Delivery PEC Notification
A delivery PEC notification is issued only after a correct PEC transport envelope (sections 2.2.2 and 3.1.5) has been delivered to the recipient's mailbox. In all other cases (e.g., PEC anomaly envelopes, PEC notifications), the delivery PEC notification is not issued. Regardless, the message received at the Delivery Point MUST be delivered to the recipient's mailbox unchanged. This notification tells the user that his/her message has been successfully delivered to the specified recipient. It includes readable text that certifies the date and time of delivery, sender and receiver data, and the subject. It also contains an XML certification data file and other optional parts for functionalities offered by the provider. The following fields are inserted in the header: 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, thus allowing the sender to determine the type of delivery PEC notification requested from the primary recipients of the original message. The notification MUST follow the format described in section 4.3.3.3.2.1. Delivery PEC Notification: Complete
This is the default value for delivery PEC notifications. When no value for "X-TipoRicevuta:" is specified, or when it contains the value "completa" (complete), the system will require a complete
delivery PEC notification from addressees in the "To:" field, while a concise PEC notification (section 3.3.2.3) will be required from those in the "Cc:" field. The distinction between primary recipients and those in carbon copy is done through an analysis of the "To:" and "Cc:" fields. For PEC notifications sent on behalf of primary recipients, a complete copy of the original message along with any attachments is inserted in the notification. In case the system in charge of delivery is not able to determine the recipient type due to ambiguity problems in the "To:" and "Cc:" fields, delivery MUST be considered as if addressed to a primary recipient and include the complete copy of the original message. The notification body contains a readable text part that relates certification data according to the following 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 is inserted in an XML file and added to the notification (section 4.4), along with any other parts that MAY be inserted by the provider for provider-specific 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 described in section 4.3.3.3.2.2. Delivery PEC Notification: Brief
In order to decrease the amount of data flowing, it is possible for the sender to ask for a delivery PEC notification in "brief" format. The brief delivery PEC notification contains the original message and 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 that MUST NOT alter the encoding of the message during its transition/processing. NOTE: Even though PEC uses these relaxed specifications, PEC interoperability tests between over 20 service providers have never revealed any problems. This is probably due to mail servers leaning more towards leaving the messages they receive intact without
applying any changes. But issues might arise if a server decides to
modify encoded parts; for example, change the base64 line length,
whose hash value calculated at the receiver's end would then differ
from that at the sender's side.
To be able to verify the transmitted contents it is necessary for the
sender to keep the unaltered original copy of the part(s) to which
the hash values refer.
If the PEC transport envelope contains the header:
X-TipoRicevuta: breve
the Delivery Point emits a brief delivery PEC notification on behalf
of the primary recipients, and a concise one (section 3.3.2.3) on
behalf of carbon copy recipients. The value of the header field in
the PEC transport envelope is derived from the original message.
The notification body contains a readable text part according to a
model that relates the following certification data:
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 is inserted in an XML file and added to
the notification (section 4.4), along with other parts that MAY be
included for specific 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 described in section 4.3.
The MIME structure of the original message is unaltered as it is
added to the notification, but each MIME part with a "name" parameter
in the header field "Content-Type:" or a "filename" parameter in the
header field "Content-Disposition:" MUST be substituted by a text
file containing that MIME part's hash value.
When the original message has an S/MIME format, it is necessary not
to alter the integrity of the message structure. Verification of the
S/MIME part in the original message takes place when the MIME type of
the top-level entity (which coincides with the message itself) is
checked. An S/MIME message MAY have the following MIME types (as per
[SMIMEV3]):
o multipart/signed
Represents an original message signed by the sender using the
structure described in [MIME-SECURE]. The message is made up of
two MIME parts: the first is the message itself before the
application of the sender's signature, whereas the second contains
signature data. The second part (generally of type
"application/pkcs7-signature" or "application/x-pkcs-signature")
contains data added during the signing phase and MUST be left
unchanged to avoid compromising the overall message structure;
o "application/pkcs7-mime" or "application/x-pkcs7-mime"
The message is composed of a sole CMS object within the MIME part.
Given that attachments cannot be separated from the CMS object,
the MIME part is left intact (i.e., it is not replaced by the hash
value); therefore, the brief PEC notification is the same as the
complete PEC notification.
If the original message contains parts whose "Content-Type:" is
"message/rfc822", i.e., contains an email message as attachment, the
entire attached message is substituted with its corresponding hash
value.
Therefore, when emitting a brief delivery PEC notification, the
provider MUST:
1. identify and extract all the parts from the first MIME part of the
multipart/signed S/MIME message;
2. calculate the hash values of all the files attached by the sender
to the original message;
3. substitute originals with their hash values.
In general, in the case of original messages in S/MIME format, the
copy of the message inserted within the brief delivery PEC
notification will have the following characteristics:
o if the original message is signed, the S/MIME structure and
signature-relative data will remain unchanged. The message will
generate an error in a future signature integrity verification
phase following the substitution of attachments with the
corresponding hash values.
o if the original message contains the "application/pkcs7-mime" or
"application/x-pkcs7-mime" MIME type, attachments present in the
message will not be substituted by their hash values, due to
impossibility of identification within a CMS structure. The
content of the brief delivery PEC notification will coincide with
that of a normal delivery PEC notification.
The algorithm used for hash calculation is the [SHA1], calculated on
the entire content of the part. To allow distinction between hash
files and the files to which they refer, the suffix ".hash" is added
to the original filename. The hash value is written in the file
using a hexadecimal representation as a single sequence of 40
characters. The MIME type of these attachments is set to
"text/plain" to highlight their textual nature.
3.3.2.3. Delivery PEC Notification: Concise
If the PEC transport envelope contains the header:
X-TipoRicevuta: sintetica
the Delivery Point emits, both to primary and carbon copy recipients,
a concise delivery PEC notification that does not contain the
original message.
The message body of the notification contains a readable text part
according to a model that relates the following certification data:
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 is inserted within an XML file and added
to 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 one of the
recipients to whom the message is delivered, and MUST follow the
format described in section 4.3.
The concise delivery PEC notification follows the same emission rules
as the delivery PEC notification; added to it is only the XML file
containing the certification data, not the original message.
3.3.3. Non-Delivery PEC Notification
If an error occurs during the delivery of a correct PEC transport message, the system returns to the sender a non-delivery PEC notification that indicates the error condition. 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 contains a readable text part according to a model that relates the following data: 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 is inserted within an XML file and added to the notification in order to allow for automatic checks (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the PEC provider 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 both sender and receiver(s) belong to the same PEC domain.3.5. Example: Complete Transaction between Two PEC Domains
A correct transaction between two PEC domains goes through the following steps: o The sending user sends an email to his provider's Access Point; o The Access Point runs all checks and emits a server-user acceptance PEC notification to the user;
o The Access Point creates a PEC transport envelope and forwards it
to the Incoming Point of the receiving provider;
o The receiver's Incoming Point verifies the PEC transport envelope
and creates a server-server acceptance PEC notification to be sent
to the sending provider;
o The sender's Incoming Point verifies the validity of the server-
server acceptance PEC notification and forwards it to the Delivery
Point;
o The sender's Delivery Point saves the server-server acceptance PEC
notification in the provider's service mailbox;
o The receiver's Incoming Point forwards the PEC transport envelope
to the receiver's Delivery Point;
o The receiver's Delivery Point verifies the contents of the PEC
transport envelope and saves it in the recipient's mailbox;
o The receiver's Delivery Point creates a delivery PEC notification
and sends it to the sender's Incoming Point;
o The sender's Incoming Point verifies the validity of the delivery
PEC notification and forwards it to the sender's Delivery Point;
o The sender's Delivery Point saves the delivery PEC notification in
the sending user's mailbox;
o The receiving user has the message at his disposition.
NOTE: Some of these steps might occur in parallel, thus the
interaction might complete in a different order.
4. Formats
4.1. Temporal Reference
For all operations carried out during message, notification, and log
elaboration processes by the Access, Incoming, and Delivery Points,
it is necessary to have an accurate temporal reference available.
All events (generation of PEC notifications, transport envelopes,
logs, etc.) that constitute the transaction of message elaboration at
the Access, Incoming, and Delivery Points MUST employ a sole temporal
value obtained from within the transaction itself.
Doing this renders the instant of message elaboration unambiguous within PEC logs, notifications, messages, etc., generated by the server.4.2. User Date/Time
Temporal indications supplied by the service in readable format (text in PEC notifications, transport envelopes, etc.) are provided with reference to the legal time at the moment of the operation. Following is the specification 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 number of days in a month, leap year, and leap second restrictions see section 5.7 of [TIMESTAMP].4.3. Format of a PEC Message Body
This section describes the characteristics of the various components of PEC messages and notifications generated by a PEC system. If one of the message parts contains characters with values outside of the range 0-127 (7-bit ASCII), that part will have to be adequately encoded so that 7-bit transportation compatibility is guaranteed (e.g., quoted-printable, base64 as per [MIME1]). Before applying the signature, the message body has Content-Type: multipart/mixed. Each part is described in the sections below. The first part is the user readable text generated by the PEC system, while the second and third parts are interchangeable in order and contain the original message and the XML file for the certification data.
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. In this case, two sub-parts MUST be present: one of type text/plain, the other text/html. For the HTML part: o it MUST contain the same information as related in the text part; o 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); o it MUST NOT have active content (e.g., JavaScript, VBscript, Plug- in, ActiveX).4.3.2. Original Message
MIME type: message/rfc822 Attachment name: postacert.eml4.3.3. Certification Data
Character set: UTF-8 MIME type: application/xml Attachment name: certdata.xml4.4. Certification Data Scheme
Following is the DTD relative to the [XML] file that contains certification data attached to PEC notifications. <!--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
The PEC providers directory is created through a centralized LDAP
server that contains the providers' data and their corresponding PEC
mail domains.
The following 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 single records is of the type "<providerName=<name>,o=postacert>". Search within the directory is carried out mainly in case-sensitive mode using the "providerCertificateHash" attribute (during envelope signature verification phase) or the "managedDomains" attribute (during message acceptance phase). It is possible for the record of a single provider to contain multiple "providerCertificate" attributes with the related "providerCertificateHash" attributes in order to allow the handling of the renewal of expiring certificates. The provider MUST make sure to update its record with sufficient advance before the certificate expiration date, by adding a new certificate whose validity overlaps that of the previous one. The data of all PEC providers is encompassed in a [LDIF] file, which is available as an [HTTPS] object and can be found at the URL to which the 'LDIFLocationURL' attribute in the "dn: o=postacert" record points (see section 4.5.6). To guarantee authenticity, that file MUST be signed by the provider for the operations regarding its PEC services using the method described for single providers. The file, the signature, and the X.509v3 certificate MUST be inserted in a PKCS#7 structure in binary ASN.1 DER format as a file with ".p7m" extension. The centralized [LDAP] system downloads that file on a daily basis and, after suitable verifications of the signature, applies it to the provider's record. Through the [LDIF] file, single providers MUST keep a copy of the directory locally, updated on a daily basis, in order to improve system performance by avoiding continuous request dispatches to the central system for every message elaboration phase.
If secondary environments are present, the [LDIF] file indicated in the main environment's record MUST relate the contents of all the provider-relevant records. 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 hash in SHA1 format of the X.509v3 certificate used by the provider 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) used by the provider 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]. As required by this attribute type's syntax, values of this attribute 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
within the provider to which server-server acceptance and virus
detection PEC notifications are sent. This address is a limited
version of the addr-spec construct described in [EMAIL] (without
angle brackets); it only permits the dot-atom-text form on both the
left- and right-hand sides of the "@", and does not have internal
CFWS.
( 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 are
handled by a PEC provider. 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 are
handled by a PEC provider. Domains are limited to dot-atom form
([RFC1034], [EMAIL]).
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", then it contains the definition of the entire directory in [LDIF] format. The LDIF file will have a MIME type of application/pkcs7-mime, with the parameter smime-type/signed-data. [SMIMEV3] The LDIF file is encoded using the UTF-8 character set. Secondary environment records MUST NOT contain the 'LDIFLocationURL' attribute which is obtained 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 secondary operating environments -- an attribute not present for the main environment. It is possible for the provider to define several distinct records, each indicating a single, different, secondary operating environment, for which it is possible to declare specific attributes that are, if need be, distinct from those relative to the main and other environments. The "DistinguishedName" of the records relative to the secondary operating environments are of the type "<providerUnits=<environment>,providerName=<name>,o=postacert>". Every provider MUST have a record associated to its own main environment, distinguishable for the absence of the "providerUnit" attribute within the record and the 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
The schema definition of 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
The schema definition of 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
The following LDIF file represents an example of a providers' directory, containing a base root and two fictitious providers. The inserted certificates are two self-signed certificates used for example purposes only: 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
The following LDIF file represents an example of a PEC providers'
directory, containing a base root and two fictitious providers, the
first of which handles a secondary environment as well. The
certificates inserted are two self-signed certificates used for
example purposes only:
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
(page 48 continued on part 3)
