La Posta Elettronica Certificata - Italian Certified Electronic Mail
draft-gennai-smime-cnipa-pec-08

There were some concerns raised during IETF LC suggesting that this document should not be published even as Informational, should be published as Historic, or should be published as Information with a big note discouraging new implementations of this spec. I would like to discuss what should be done with this document.



2.1. System-generated messages

  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>

This is really hackish. Display names are not intended to be used like this.



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

One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.


2.2.3. Delivery point

  If the message 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). The latter is generated only when
  a PEC transport envelopoe encounters a delivery error.
  If the delivery error concerns a normal email from the Internet
  (non-PEC message), no such notification is emitted.


PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?

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

SMTP SIZE extension on message submission would have been much better here.

3.1.5. PEC Transport envelope

  As was 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 Return-Path

[...]

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

       X-Trasporto: posta-certificata
       Date: [actual date of 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 message ID generated as explained in 2.2.1]

This is a new message, yet it contains a copy of the original Received headers?

       X-Riferimento-Message-ID: [message ID of original message]
       X-TipoRicevuta: [completa/breve/sintetica]


3.3.2. Delivery PEC notification

  A delivery PEC notification is issued only after a correct PEC
  transport envelope has been delivered to the recipient's mailbox.
  The PEC transport envelope can be easily determined from the
  presence of the following header field:

       X-Trasporto: posta-certificata

How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.


3.3.2.2. Delivery PEC notification: brief

  The MIME structure of the original message is unaltered as it is
  attached to the notification, but its attachment(s) are substituted
  with as many text files as the attachments are, each containing the
  hash value of the file it substitutes. The attachments are
  identified through the presence of the "name" parameter in the
  header "content-type", or "filename" in the header "content-
  disposition" of the MIME part.

This doesn't seem to be a very reliable way of identifying attachments.


4.3. Attachments

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

Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-Transfer-Encoding.



4.3.1. Message body

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

Nitpicking: ISO-8859-1 is only relevant for text/plain.

In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.



4.3.3. Certification data

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

It would have been better if this would have been a new MIME type
(application/...+xml).


4.5. PEC providers directory scheme

  Through the LDIF file, single providers MUST keep a local copy of
  the directory, 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.

This recommendation is ignoring the fact that LDAP Directories support replication and caching, so each provider can use own Directory
which is a shadow copy of the master Directory.

5.3. Secure interaction

  An "MX" type record MAY be associated to each PEC domain,
  defined within the system for name resolution.

It would be helpful to point out that that this is in conformance with
RFC 5321.



6. PEC system client technical and functional prerequisites

  o support for "ISO-8859-1 (Latin-1)" character set;

What about UTF-8 (as used in application/xml)?

5.6. PEC providers directory

   Each provider downloads the LDIF file through ah [HTTPS] session,
   which is authenticated using an X.509 certificate released by a
   certification authority.

I think it would be more correct to say:
   which is authenticated by checking the X.509 certificate issued by a
   certification authority.

But I think a reference to RFC 5280 or better RFC 2818 is needed here as well.

   Through the [LDIF] file, single providers HAVE TO keep a copy of the

If you meant to use an RFC 2119 keyword, then you should use "MUST" instead of "HAVE TO" here.

   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.


The following used to be a DISCUSS:
Section 4.3

There are multiple ways to represent described data structure in email.
In order to insure interoperability you need to describe which choices
are acceptable. For example, if you mean that the message is a multipart/mixed (or multipart/alternative) with the first part being the textual part and the second part being the XML data, you should say so.

5)
3.3.2.2. Delivery PEC notification: brief

   The brief delivery PEC notification contains the original
   message and a ciphered hash value of each part, which
   SHOULD be calculated on base64 encoded parts.

Also, if  particular Content-Transfer-Encoding, are CRLFs included in the hash calculation?