tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6109

 
 
 

La Posta Elettronica Certificata - Italian Certified Electronic Mail

Part 2 of 3, p. 18 to 48
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
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.

Top      Up      ToC       Page 19 
   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.

Top      Up      ToC       Page 20 
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.

Top      Up      ToC       Page 21 
   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)

Top      Up      ToC       Page 22 
   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.

Top      Up      ToC       Page 23 
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:

Top      Up      ToC       Page 24 
      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

Top      Up      ToC       Page 25 
   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

Top      Up      ToC       Page 26 
   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]).

Top      Up      ToC       Page 27 
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.

Top      Up      ToC       Page 28 
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.

Top      Up      ToC       Page 29 
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

Top      Up      ToC       Page 30 
   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

Top      Up      ToC       Page 31 
   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]):

Top      Up      ToC       Page 32 
   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

Top      Up      ToC       Page 33 
      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.

Top      Up      ToC       Page 34 
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;

Top      Up      ToC       Page 35 
   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.

Top      Up      ToC       Page 36 
   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.

Top      Up      ToC       Page 37 
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.eml

4.3.3.  Certification Data

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

4.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

Top      Up      ToC       Page 38 
         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)>

Top      Up      ToC       Page 39 
   <!--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.

Top      Up      ToC       Page 40 
   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.

Top      Up      ToC       Page 41 
   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.

Top      Up      ToC       Page 42 
   ( 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]).

Top      Up      ToC       Page 43 
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 )

Top      Up      ToC       Page 44 
   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::

Top      Up      ToC       Page 45 
        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

Top      Up      ToC       Page 46 
        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

Top      Up      ToC       Page 47 
        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

Top      Up      ToC       Page 48 
        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)

Next RFC Part