Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6109

La Posta Elettronica Certificata - Italian Certified Electronic Mail

Pages: 65
Informational
Errata
Part 1 of 3 – Pages 1 to 18
None   None   Next

Top   ToC   RFC6109 - Page 1
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 Mail

Abstract

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.
Top   ToC   RFC6109 - Page 2
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.
Top   ToC   RFC6109 - Page 3

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
Top   ToC   RFC6109 - Page 4
      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
Top   ToC   RFC6109 - Page 5

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.
Top   ToC   RFC6109 - Page 6
   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
Top   ToC   RFC6109 - Page 7

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.
Top   ToC   RFC6109 - Page 8
   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.
Top   ToC   RFC6109 - Page 9
   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.
Top   ToC   RFC6109 - Page 10

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).
Top   ToC   RFC6109 - Page 11
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:
Top   ToC   RFC6109 - Page 12
   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 Point

2.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);
Top   ToC   RFC6109 - Page 13
   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]>
Top   ToC   RFC6109 - Page 14
   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);
Top   ToC   RFC6109 - Page 15
      -  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).
Top   ToC   RFC6109 - Page 16
      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.
Top   ToC   RFC6109 - Page 17
   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
Top   ToC   RFC6109 - Page 18
   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)

Next Section