RFC 6109
La Posta Elettronica Certificata - Italian Certified Electronic Mail
Internet Engineering Task Force (IETF) C. Petrucci Request for Comments: 6109 DigitPA Category: Informational F. Gennai ISSN: 2070-1721 A. Shahin ISTI-CNR A. Vinciarelli April 2011 La Posta Elettronica Certificata - Italian Certified Electronic MailAbstract
Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing. The design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National Research Council (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6109.
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian Posta Elettronica Certificata, from now on "PEC") were defined, giving the system legal standing. This document represents the English version of the Italian specifications (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. IETF review did not result in community consensus. Since this specification describes existing deployment and implementation, the issues identified by the IETF community have not been addressed in this document. However, these issues would need to be addressed before a successor to this document could be published. At a minimum, the successor document 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
To ensure secure transactions over the Internet, cryptography can be associated with electronic messages in order to provide some guarantee on sender identity, message integrity, confidentiality, and non-repudiation of origin. Many end-to-end techniques exist to accomplish such goals, and some offer a high level of security. The downside of end-to-end cryptography is the need for an extensive penetration of technology in society, because it is essential for every user to have asymmetric keys and certificates signed by a Certification Authority. Along with that, users would need to have an adequate amount of knowledge regarding the use of such technology.
PEC, on the other hand, uses applications running on servers to digitally sign messages, thus avoiding the complexity end-to-end systems bring about. By doing so, the user need only have an ordinary mail client with which to interact. The downside is that the level of security drops, since the protection does not cover the entire transaction. Nonetheless, application is simpler and does not require specific user skills, making it easily more widespread among users. This document describes PEC's technical aspects and features. It presents the details of the protocol and the messages that are sent between service providers, introducing the system adopted by the Italian government for the exchange of certified emails.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].1.2.2. Acronyms
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
Certification data: A set of data certified by the sender's PEC provider that describes the original message. It includes the date and time of dispatch, sender email address, recipient(s) email address(es), subject, and message identifier. Certified electronic mail: A service based on electronic mail, as defined by the [EMAIL] and [SMTP] standards and extensions, which permits the transmission of documents produced with informatics tools. DigitPA: Ex-CNIPA. Holder: The person or organization to whom a PEC mailbox is assigned. Message sent: A PEC message is considered sent when the sender's PEC provider, after several checks, accepts the email and returns a server-user acceptance PEC notification to the sender. Message received: A PEC message is considered received when it is stored in the receiver's mailbox, after which the receiver PEC provider returns a delivery PEC notification to the sender. Msgid: Is the message identifier generated by the email client, as defined in [EMAIL], before the message is submitted to the PEC system. Ordinary mail: Non-PEC email messages. Original message: Is the user-generated message before its arrival to the sender Access Point. The original message is delivered to the recipient inside a PEC transport envelope. PEC domain: Corresponds to a DNS domain dedicated to the holders' mailboxes. PEC mailbox: An electronic mailbox for which delivery PEC notifications are issued upon reception of PEC messages. Such a mailbox can be defined exclusively within a PEC domain. PEC msgid: Is a unique identifier generated by the PEC system, which will substitute the msgid.
PEC provider: The entity that handles one or more PEC domains with their relative points of Access, Reception, and Delivery. It is the holder of the key that is used for signing PEC notifications and envelopes, and it interacts with other PEC providers for interoperability with other holders. PEC provider's key: Is a key released by DigitPA to every PEC provider. It is used to sign PEC notifications and envelopes and to authorize access to the PEC providers directory. PEC providers directory: Is an LDAP server positioned in an area reachable by all PEC service providers. It constitutes the technical structure related to the public list of PEC service providers and contains the list of PEC domains and service providers with relevant certificates. Service mailbox: A mailbox for the sole use of the provider, dedicated for the reception of server-server acceptance and virus detection PEC notifications. Time stamp: Digital evidence with which a temporal reference, that can't be repudiated, is attributed to one or more documents.2. PEC Model
2.1. System-Generated Messages
The PEC system generates messages in MIME format composed of a descriptive textual part and other [MIME1] parts, the number and content of which varies according to the type of message generated. A system-generated message falls into one of the following categories: o Notifications; o Envelopes. The message is inserted in an S/MIME v3 structure in CMS format and signed with the PEC provider's private key. The X.509v3 certificate associated with the key MUST be included in the aforementioned 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 guarantee the verifiability of signatures 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.
In order for the receiving mail client to verify the signature, the
sender address MUST coincide with the one indicated within the
X.509v3 certificate. For this mechanism, PEC transport envelopes
MUST indicate in the "From:" field a single author's address which is
different from the one contained in the original message. To allow
for better message usability by the receiving user, the author's mail
address in the original message is inserted as a "display name". For
example, a "From:" field such as:
From: "John Smith" <john.smith@domain.example.com>
would result in the following "From:" value in the respective 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. In
order for replies to be correctly sent back to the proper
destination, the "Reply-To:" field in the PEC transport envelope MUST
contain the same unaltered value of the original message's
"Reply-To:" field. When it is not explicitly specified in the
original message, the system that generates the PEC transport
envelope creates it by extracting the information from the "From:"
field in the original message.
When PEC notifications are sent, the system MUST use the original
message sender's address as the destination address, as is specified
in the reverse path data of the SMTP protocol. PEC notifications
MUST be sent to the sender's PEC mailbox without taking into account
the "Reply-To:" field, which might be present in the original
message's header.
All system-generated PEC messages are identifiable for having a
specific header defined in PEC according to the type of message
generated.
To determine the certification data, the elements used for the actual
routing of the message are employed. In SMTP dialog phases, the
reverse path and forward path data ("MAIL FROM" and "RCPT TO"
commands) are thus considered certification data of both the sender
and the recipients, respectively. Addressing data present in the
message body ("To:" and "Cc:" fields) are used solely in order to
discriminate between primary and carbon copy recipients when
necessary; addressing data present 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, with extra fields added according to the type of message generated.2.1.1.1. PEC Notifications
They have the purpose of informing the sending user and interacting providers of the progress the message is making within the PEC network.2.1.1.1.1. Success PEC Notifications
These notifications indicate an acknowledgment on the provider's side for the reception or handling of a PEC message. More specifically, it can indicate one of three situations: server-user acceptance, server-server acceptance, or delivery. Added header fields are: o X-Ricevuta: o X-Riferimento-Message-ID: The field "X-Ricevuta:" indicates the type of PEC notification contained in the message, whereas "X-Riferimento-Message-ID:" contains the message identifier generated by the mail client (msgid). Body contents differ according to notification type. This is described more thoroughly in section 3. o A server-user acceptance PEC notification informs the user that his provider has accepted the message and will be taking care of passing it on to the provider(s) of the addressee(s). o A server-server acceptance PEC notification is an inter-provider communication only, it MUST NOT be sent to the users. With this notification, the receiving provider simply informs the sending one that it has received a PEC message, and will take the responsibility of forwarding it to the addressee(s). From then on, the sender provider is no longer held responsible as to the whereabouts of the message, but is limited to notifying its user of the success or failure of delivery. o Delivery PEC notifications take place as the final communication of a transaction, indicating overall success in handing the message over to the addressee(s).
2.1.1.1.2. Delay PEC Notifications
Delay PEC notifications are sent out 12 hours after a message has been dispatched from the sending provider, and no server-server acceptance or delivery PEC notification has been received. These have the sole purpose of notifying the user of the delay. If another 12 hours go by without any sign of a server-server acceptance or delivery PEC notification (amounting to a 24-hour delay), another delay PEC notification is dispatched to the user informing him of the possible delivery failure. The provider will not keep track of the delay any further.2.1.1.1.3. Failure PEC Notifications
They are sent when there is some error in transmission or reception. More specifically, a failure PEC notification can indicate either a formal-exception error or a virus detection. Added header fields are: o X-Ricevuta: o X-Riferimento-Message-ID: o X-VerificaSicurezza: [optional] "X-Ricevuta:" and "X-Riferimento-Message-ID:" have the same role as indicated 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 differ according to notification type. This is described more thoroughly in section 3.2.1.1.2. PEC Envelopes
Messages entering the PEC network are inserted within specific PEC messages, called envelopes, before they are allowed to circulate further within the network. These envelopes MUST inherit the following header fields, along with their unmodified values, from the message itself: o Received: o To: o Cc:
o Return-Path: o Reply-To: (if present) Depending on the type of message requesting admission into the PEC network, it will be inserted in either a PEC transport envelope or a PEC anomaly envelope. Distinction will be possible 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 Point2.2.1. Access Point
This is what the user client at the sender side interacts with, giving the user access to PEC services set up by the provider. Such access MUST be preceded by user authentication on the system (see section 5.2). The Access Point receives the original messages its user wishes to send, runs some formal checks, and acts according to the outcome: o 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; o 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);
o 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.
Generation of the server-user acceptance notification indicates to
the user that the message was accepted by the system, certifying also
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 offered by the provider.
Using the data available in the PEC providers directory (see section
4.5), the Access Point runs checks on every recipient in the "To:"
and "Cc:" fields present in the original message to verify whether
they belong to the PEC infrastructure or to non-PEC domains. Such
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.
Therefore, the server-user acceptance PEC notification (and relevant
certification data) relates to, for each address, 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 in order to consent
correct tracking of messages and relative PEC notifications. The
format of such an identifier is:
[alphanumeric string]@[provider mail domain]
or:
[alphanumeric string]@[FQDN mail server]
Therefore, both the original message and the corresponding PEC
transport envelope MUST contain the following header field:
Message-ID: <[unique identifier]>
When an email client that is 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. In order to
allow the sender to link the message sent with the relative PEC
notifications, the msgid MUST be inserted in the original message as
well as 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 is also the point through which ordinary mail messages can be inserted within 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, as 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: o verifies correctness and type of the incoming message; o 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). o if the incoming message is a correct and undamaged PEC notification, forwards the notification to the Delivery Point. o 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.
o 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 in its transition from one
provider to another, and is therefore 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:
o Signature existence - the system verifies the presence of an
S/MIME signature structure within the incoming message;
o 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 is 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 allows one to easily identify the
sender provider for subsequent and necessary matching checks
between the extracted certificate and the one present in the
provider's record;
o 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;
o 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 is 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.
Thus, the Incoming Point will refrain from forwarding the message
to the recipient, instead sending the appropriate PEC notification
of non-delivery and storing the virus-infected message in the
provider's special storage.
In case ordinary mail messages are received, the PEC provider
SHALL perform virus checks in order to prevent the infiltration of
potentially dangerous mail messages within the PEC system. If a
virus is detected in an ordinary mail message, the latter 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
is handled in a manner that is 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:
o check what virus typologies were not detected by its own antivirus
to verify the possibility of interventions
o send a virus-induced non-delivery PEC notification to the sender's
mailbox.
2.2.3. Delivery Point
This point is the point that receives messages from the Incoming
Point and forwards them to the final recipient.
It MUST run a series of tests on received messages before forwarding
them to the user (see section 3.3.1). It first verifies the typology
of the message and decides whether or not a PEC notification should
be issued to the sender. The delivery PEC notification (section
3.3.2) is emitted after the message was delivered to the recipient's
PEC mailbox and only at reception of a valid PEC transport envelope
(sections 2.2.2 and 3.1.5).
In all other cases, such as PEC anomaly envelopes and PEC
notifications, the delivery PEC notification is not emitted.
Regardless, the message received from the Delivery Point MUST be
delivered unmodified to the recipient's mailbox.
The delivery PEC notification indicates to the sender that the message sent was in fact conveyed to the specified recipient's mailbox and certifies the date and time of delivery through use of user-readable text and an XML part containing certification data, along with other possible attachments added for extra features offered by the provider. If a PEC transport envelope received at the Delivery Point can't be delivered to the destination mailbox, the Delivery Point emits a non- delivery PEC notification (section 3.3.3). If, on the other hand, the delivery error concerns a message that arrives from Internet (i.e., a non-PEC message), no such notification is emitted.2.2.4. Storage
Each provider MUST dedicate a special storage for the deposition of any virus-infected messages encountered. Whether the virus be detected by the sender's Access Point or the receiver's Incoming Point, the provider that detects it MUST store the mail message in its own storage, and keep it for 30 months.2.2.5. Provider Service Mailbox
For exclusive use of the provider, dedicated to the reception of PEC notifications in two cases only: o server-server acceptance notification; and o virus detection notification.2.2.6. Provider Service Email Address
Each provider MUST register a special purpose email address for use when sending PEC transport envelopes and notifications, as delineated in section 3. This address MAY coincide with that of the service mailbox described in section 2.2.5.2.3. Log
The server administrator MUST keep track of any and all operations carried out in a specific message log file. The information kept in the log for each operation is the following: o message identifier (msgid) o date and time of event o sender of original message
o recipient(s) of original message o subject of original message o event type (reception, delivery, PEC notification emission, etc.) o message identifiers of related generated messages o sending provider The service provider MUST store this data and preserve it unmodified. Italian laws have specified that the service provider retain the data for 30 months.
(page 18 continued on part 2)
