Subject: Comment on draft-gennai-smime-cnipa-pec-00.txt

From: Bernardi Giorgio <[email-masked]>
Date: Thu, 16 Oct 2008 23:15:18 +0200

Being a developer of "PEC recommendation" compliant software, I just 
like to point out a clarification that would be nice on the point
2.2.2 of the draft, in order to promote the "best practice" that have 
surfaced in the recent years.
Lately has been discovered that many PEC messages are handled by 
automatic systems in banking and security organizations, for which to 
decode and understand SMTP error message is adding a level of complexity 
to the software app that generate PEC messages, so most of them prefer 
wait and process the "Non-delivery notification" that is now used as the 
preferred method to convey errors.

Now the point 2.2.2 is states as:

------------------------------------------------------------------

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
    circuit 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 can be handled using the
    standard error notification mechanisms, as provided by SMTP in
    [SMTP] and [SMTP-DSN].

------------------------------------------------------------------

A better way to state it could be:

------------------------------------------------------------------

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
    circuit 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 can be handled using the
    standard error notification mechanisms, as provided by SMTP in
    [SMTP] and [SMTP-DSN], however if the message is coming from
    another PEC provider for the notification of the error the PEC
    message for "Non-delivery notification" should be used in place of
    the SMTP error.

------------------------------------------------------------------

Regards.

-- 
    ____________________________________________________________
    Giorgio Bernardi                   INRETE
    Email [email-masked]                 Via Postiglione, 29
                                       10024 Moncalieri (TO)
                                       Tel 011 6811590
                                       Fax 011 6811603
                                       Email [email-masked]
                                       Web http://www.inrete.it

---

From: Shahin Alba <[email-masked]>
Date: Mon, 27 Oct 2008 12:17:08 +0100

>    message for "Non-delivery notification" should be used in place of

When SMTP communication errors occur, the error notification is 
generated by the sending PEC server itself, not the intended receiving 
one -since the communication error would occur before the message 
reached the destination. That notification is sent to the server's 
service mailbox (not the user's mailbox), and after a certain amount of 
time the Timeout Delivery Error Notification is generated by the sending 
server.

The only case we can think of in which the receiving server could send 
an SMTP error, would be if the MTA at the receiver's side got hold of 
the message and ran its standard checks on it -therefore rejecting it- 
rather than having PEC checks run on the message. This though must not 
happen, since all messages have to be accepted by the PEC server.

A minor adjustment though will be the following:

"If SMTP communication errors occur, they MAY be handled using the
standard error notification mechanisms, as provided by SMTP in
 [SMTP] and [SMTP-DSN]."

--Alba