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
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
La Posta Elettronica Certifica-意大利认证电子邮件
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.
自1997年以来，意大利法律承认电子交付系统在法律上可用。2005年，经过两年的技术测试，官方电子传递服务认证电子邮件（意大利语“Posta Elettronica Certifica”）的特征得到了定义，使该系统具有法律地位。
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.
整个系统的设计由意大利公共管理局国家信息学中心（DigitPA）进行，随后致力于服务的实施和测试。DigitPA已赋予意大利国家研究委员会（CNR），特别是意大利国家研究委员会（ISTI）的信息科学与技术研究所（Institute of Information Science and Technologies）对服务提供商进行测试的任务，以确保服务的正确实施和互操作性。本文件描述了意大利采用的认证电子邮件系统。它代表了在编写时的系统，遵循根据意大利法律DPR编写的技术法规。2005年11月2日。
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.
本文件是互联网工程任务组（IETF）的产品。互联网工程指导小组（IESG）已批准将其出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6109.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
1. Introduction ....................................................5
1.1. Scope ......................................................5
1.2. Notational Conventions .....................................6
1.2.1. Requirement Conventions .............................6
1.2.2. Acronyms ............................................6
1.2.3. Terminology and Definitions .........................7
2. PEC Model .......................................................8
2.1. System-Generated Messages ..................................8
2.1.1. Message Types ......................................10
2.2. Basic Structure ...........................................12
2.2.1. Access Point .......................................12
2.2.2. Incoming Point .....................................14
2.2.3. Delivery Point .....................................16
2.2.4. Storage ............................................17
2.2.5. Provider Service Mailbox ...........................17
2.2.6. Provider Service Email Address .....................17
2.3. Log .......................................................17
3. Message Processing .............................................18
3.1. Access Point ..............................................18
3.1.1. Formal Checks on Messages ..........................18
3.1.2. Non-Acceptance PEC Notification Due to
Formal Exceptions ..................................19
3.1.3. Non-Acceptance PEC Notification Due to
Virus Detection ....................................20
3.1.4. Server-User Acceptance PEC Notification ............20
3.1.5. PEC Transport Envelope .............................21
3.1.6. Timeout Delivery Error PEC Notification ............23
3.2. Incoming Point ............................................24
3.2.1. Server-Server Acceptance PEC Notification ..........24
3.2.2. PEC Anomaly Envelope ...............................25
3.2.3. Virus Detection PEC Notification ...................27
3.2.4. Virus-Induced Delivery Error PEC notification ......28
3.3. Delivery Point ............................................29
3.3.1. Checks on Incoming Messages ........................29
3.3.2. Delivery PEC Notification ..........................29
3.3.3. Non-Delivery PEC Notification ......................34
3.4. Sender and Receiver Belonging to the Same Domain ..........34
3.5. Example: Complete Transaction between Two PEC Domains .....34
4. Formats ........................................................35
4.1. Temporal Reference ........................................35
4.2. User Date/Time ............................................36
4.3. Format of a PEC Message Body ..............................36
4.3.1. User Readable Text .................................37
4.3.2. Original Message ...................................37
4.3.3. Certification Data .................................37
4.4. Certification Data Scheme .................................37
4.5. PEC Providers Directory Scheme ............................39
4.5.1. providerCertificateHash Attribute ..................41
4.5.2. providerCertificate Attribute ......................41
4.5.3. providerName Attribute .............................41
4.5.4. mailReceipt Attribute ..............................42
4.5.5. managedDomains Attribute ...........................42
4.5.6. LDIFLocationURL Attribute ..........................43
4.5.7. providerUnit Attribute .............................43
4.5.8. LDIFLocationURLObject Object Class .................44
4.5.9. Provider Object Class ..............................44
4.5.10. LDIF File Example .................................44
5. Security-Related Aspects .......................................48
5.1. Digital Signature .........................................48
5.2. Authentication ............................................48
5.3. Secure Interaction ........................................49
5.4. Virus .....................................................49
5.5. S/MIME Certificate ........................................49
5.5.1. Provider-Related Information (Subject) .............50
5.5.2. Certificate Extensions .............................50
5.5.3. Example ............................................51
5.6. PEC Providers Directory ...................................55
6. PEC System Client Technical and Functional Prerequisites .......55
7. Security Considerations ........................................55
8. IANA Considerations ............................................56
8.1. Registration of PEC Message Header Fields .................56
8.1.1. Header Field: X-Riferimento-Message-ID: ............56
8.1.2. Header Field: X-Ricevuta: ..........................56
8.1.3. Header Field: X-VerificaSicurezza: .................57
8.1.4. Header Field: X-Trasporto: .........................57
8.1.5. Header Field: X-TipoRicevuta: ......................57
8.1.6. Header Field: X-Mittente: ..........................58
8.2. Registration of LDAP Object Identifier Descriptors ........58
8.2.1. Registration of Object Classes and
Attribute Types ....................................58
9. References .....................................................59
9.1. Normative References ......................................59
9.2. Informative References ....................................61
10. Acknowledgments ...............................................62
Appendix A. Italian Fields and Values in English ..................63
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
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.
自1997年以来，意大利法律承认电子交付系统在法律上可用。2005年，经过两年的技术测试，官方电子传递服务认证电子邮件（意大利语Posta Elettronica Certifica，从现在起称为“PEC”）的特征得到了定义，赋予了该系统法律地位。
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.
本文件代表意大利规范的英文版本(http://www.digitpa.gov.it/sites/default/files/normativa/ Pec_regole_techniche_DM_2-nov-2005.pdf）；意大利语版本为PEC标准参考。
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:
IETF审查未达成社区共识。由于本规范描述了现有的部署和实施，因此IETF社区确定的问题未在本文档中解决。然而，在公布本文件的后续文件之前，需要解决这些问题。后续文件至少需要包括：
* 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
* 与IETF电子邮件和安全性的传统术语保持一致
* 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.
* 将本规范中使用的未注册LDAP DN名称空间替换为注册名称空间，这可能会导致与其他已注册或未注册的名称冲突。
To ensure secure transactions over the Internet, cryptography can be associated with electronic messages in order to provide some guarantee on sender identity, message integrity, confidentiality, and non-repudiation of origin. Many end-to-end techniques exist to accomplish such goals, and some offer a high level of security. The downside of end-to-end cryptography is the need for an extensive penetration of technology in society, because it is essential for every user to have asymmetric keys and certificates signed by a Certification Authority. Along with that, users would need to have an adequate amount of knowledge regarding the use of such technology.
为了确保互联网上的交易安全，可以将加密技术与电子消息相关联，以便在发送者身份、消息完整性、机密性和来源不可否认性方面提供一些保证。存在许多端到端技术来实现这些目标，有些技术提供了高级别的安全性。端到端加密的缺点是需要技术在社会中广泛渗透，因为每个用户都必须拥有由认证机构签名的不对称密钥和证书。除此之外，用户还需要对此类技术的使用有足够的了解。
PEC, on the other hand, uses applications running on servers to digitally sign messages, thus avoiding the complexity end-to-end systems bring about. By doing so, the user need only have an ordinary mail client with which to interact. The downside is that the level of security drops, since the protection does not cover the entire transaction. Nonetheless, application is simpler and does not require specific user skills, making it easily more widespread among users.
另一方面，PEC使用服务器上运行的应用程序对消息进行数字签名，从而避免端到端系统带来的复杂性。这样，用户只需要有一个普通的邮件客户端就可以与之交互。缺点是安全级别下降，因为保护不覆盖整个事务。尽管如此，该应用程序更简单，并且不需要特定的用户技能，因此更容易在用户中普及。
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.
本文件描述了PEC的技术方面和特点。它介绍了协议的细节以及服务提供商之间发送的消息，并介绍了意大利政府用于交换认证电子邮件的系统。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[REQ]中的说明进行解释。
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
CMS:Cryptographic Message Syntax CNIPA：意大利国家数字管理局（意大利国家信息中心）CNR：意大利国家研究委员会（意大利国家研究委员会）CRL:证书吊销列表CRL DP:证书吊销列表分发点DNS:域名服务DTD:文档类型定义FQDN:完全限定的域名ISTI:CNR信息科学与技术研究所LDAP:轻型目录访问协议LDIF:LDAP数据交换格式MIME:多用途Internet邮件扩展PEC:认证电子邮件（Posta Elettronica Certifica）S/MIME:安全/MIME SMTP:简单邮件传输协议TLS:传输层安全XML:可扩展标记语言
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.
认证数据：由发送方的PEC提供商认证的一组数据，用于描述原始消息。它包括发送日期和时间、发件人电子邮件地址、收件人电子邮件地址、主题和邮件标识符。
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.
认证电子邮件：根据[电子邮件]和[SMTP]标准和扩展的定义，基于电子邮件的服务，允许传输使用信息学工具生成的文件。
DigitPA: Ex-CNIPA.
DigitPA:Ex CNIPA。
Holder: The person or organization to whom a PEC mailbox is assigned.
持有者：向其分配PEC邮箱的个人或组织。
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 sent（已发送消息）：当发件人的PEC提供程序在多次检查后接受电子邮件并向发件人返回服务器用户接受PEC通知时，PEC消息被视为已发送。
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.
Message received（已接收消息）：当PEC消息存储在接收方邮箱中时，即被视为已接收，之后接收方PEC提供程序将传递PEC通知返回给发送方。
Msgid: Is the message identifier generated by the email client, as defined in [EMAIL], before the message is submitted to the PEC system.
Msgid：邮件提交到PEC系统之前，由电子邮件客户端生成的邮件标识符，如[电子邮件]中所定义。
Ordinary mail: Non-PEC email messages.
普通邮件：非PEC电子邮件。
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传输信封内传递给收件人。
PEC domain: Corresponds to a DNS domain dedicated to the holders' mailboxes.
PEC域：对应于持有人邮箱专用的DNS域。
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邮箱：一种电子邮箱，在收到PEC消息时，会发出PEC通知。这样的邮箱可以在PEC域中专门定义。
PEC msgid: Is a unique identifier generated by the PEC system, which will substitute the msgid.
PEC msgid：是PEC系统生成的唯一标识符，它将替代msgid。
PEC provider: The entity that handles one or more PEC domains with their relative points of Access, Reception, and Delivery. It is the holder of the key that is used for signing PEC notifications and envelopes, and it interacts with other PEC providers for interoperability with other holders.
PEC提供者：处理一个或多个PEC域及其相对访问、接收和交付点的实体。它是用于签署PEC通知和信封的密钥的持有者，并与其他PEC提供商交互，以实现与其他持有者的互操作性。
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提供商密钥：是DigitPA向每个PEC提供商发布的密钥。它用于签署PEC通知和信封，并授权访问PEC提供者目录。
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.
PEC提供者目录：是一个LDAP服务器，位于所有PEC服务提供者都可以访问的区域。它构成与PEC服务提供商公共列表相关的技术结构，并包含PEC域和具有相关证书的服务提供商列表。
Service mailbox: A mailbox for the sole use of the provider, dedicated for the reception of server-server acceptance and virus detection PEC notifications.
服务邮箱：仅供提供商使用的邮箱，专用于接收服务器接受和病毒检测PEC通知。
Time stamp: Digital evidence with which a temporal reference, that can't be repudiated, is attributed to one or more documents.
时间戳：一个不可否认的时间引用归属于一个或多个文档的数字证据。
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.
PEC系统以MIME格式生成消息，该格式由描述性文本部分和其他[MIME1]部分组成，其数量和内容根据生成的消息类型而不同。
A system-generated message falls into one of the following categories:
系统生成的消息可分为以下类别之一：
o Notifications;
o 通知；
o Envelopes.
o 信封。
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].
消息以CMS格式插入到S/MIME v3结构中，并使用PEC提供程序的私钥进行签名。与密钥关联的X.509v3证书必须包含在上述结构中。用于对系统生成的消息进行签名的S/MIME格式是“多部分/签名”格式（.p7s），如[SMIMEV3]第3.4.3节所述。
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.
为了保证尽可能多的邮件客户端上签名的可验证性，认证电子邮件系统使用的X.509v3证书必须遵守第6.5节中的配置文件。
In order for the receiving mail client to verify the signature, the sender address MUST coincide with the one indicated within the X.509v3 certificate. For this mechanism, PEC transport envelopes MUST indicate in the "From:" field a single author's address which is different from the one contained in the original message. To allow for better message usability by the receiving user, the author's mail address in the original message is inserted as a "display name". For example, a "From:" field such as:
为了让接收邮件的客户端验证签名，发件人地址必须与X.509v3证书中指示的地址一致。对于这种机制，PEC传输信封必须在“发件人：”字段中指明单个作者的地址，该地址与原始邮件中包含的地址不同。为了让接收用户更好地使用消息，原始消息中的作者的邮件地址被插入为“显示名”。例如，“发件人：”字段，例如：
From: "John Smith" <john.smith@domain.example.com>
From: "John Smith" <john.smith@domain.example.com>
would result in the following "From:" value in the respective PEC transport envelope:
将在相应的PEC运输包线中产生以下“起始：”值：
From: "On behalf of: john.smith@domain.example.com"
<certified-mail@provider.example.com>
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.
“发件人：”和“发件人：”字段必须包含相同的值。为了将回复正确发送回正确的目的地，PEC传输信封中的“回复至：”字段必须包含与原始邮件的“回复至：”字段相同的未更改值。当原始消息中未明确指定PEC传输信封时，生成PEC传输信封的系统通过从原始消息中的“发件人：”字段提取信息来创建该信封。
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.
发送PEC通知时，系统必须使用原始邮件发件人的地址作为目标地址，这在SMTP协议的反向路径数据中有指定。PEC通知必须发送到发件人的PEC邮箱，而不考虑原始邮件标题中可能存在的“回复：”字段。
All system-generated PEC messages are identifiable for having a specific header defined in PEC according to the type of message generated.
所有系统生成的PEC消息都可以识别，以便根据生成的消息类型在PEC中定义特定的报头。
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.
为了确定认证数据，使用了用于消息实际路由的元素。在SMTP对话阶段，反向路径和正向路径数据（“邮件发件人”和“RCPT收件人”命令）因此分别被视为发件人和收件人的认证数据。邮件正文中的寻址数据（“收件人：”和“抄送：”字段）仅用于在必要时区分主要收件人和副本收件人；“Bcc:”字段中的寻址数据必须被系统视为无效。
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.
所有系统生成的消息都从原始消息继承其标题字段和值，并根据生成的消息类型添加额外字段。
They have the purpose of informing the sending user and interacting providers of the progress the message is making within the PEC network.
它们的目的是通知发送用户和交互提供者消息在PEC网络中的进展。
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.
这些通知表示提供者对接收或处理PEC消息的确认。更具体地说，它可以表示三种情况之一：服务器用户接受、服务器服务器接受或交付。
Added header fields are:
添加的标题字段包括：
o X-Ricevuta:
o X-Ricevuta：
o X-Riferimento-Message-ID:
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).
字段“X-Ricevuta:”表示消息中包含的PEC通知类型，而“X-Riferimento-message-ID:”包含邮件客户端（msgid）生成的消息标识符。
Body contents differ according to notification type. This is described more thoroughly in section 3.
正文内容因通知类型而异。第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 服务器用户接受PEC通知通知用户其提供商已接受消息，并将负责将消息传递给收件人的提供商。
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 服务器接受PEC通知仅为提供商间通信，不得发送给用户。通过此通知，接收提供者只需通知发送提供者它已收到PEC消息，并将负责将其转发给收件人。从那时起，发送方提供者不再对消息的去向负责，而仅限于通知其用户消息传递的成功或失败。
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).
o 投递PEC通知作为交易的最终通信进行，表明将消息移交给收件人的总体成功。
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.
延迟PEC通知在发送提供程序发送消息12小时后发出，并且未收到服务器接受或传递PEC通知。其唯一目的是通知用户延迟。
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.
如果再过12小时，没有任何迹象表明服务器接受或交付PEC通知（相当于24小时延迟），则会向用户发送另一个延迟PEC通知，通知其可能的交付失败。提供商将不再跟踪延迟情况。
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.
它们在传输或接收中出现错误时发送。更具体地说，失败PEC通知可能表示正式异常错误或病毒检测。
Added header fields are:
添加的标题字段包括：
o X-Ricevuta:
o X-Ricevuta：
o X-Riferimento-Message-ID:
o X-Riferimento-Message-ID：
o X-VerificaSicurezza: [optional]
o X-VerificationCasicurezza:[可选]
"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.
“X-Ricevuta:”和“X-Riferimento-Message-ID:”的作用与第2.1.1.1节（成功通知）中所述的相同。“X-VerificationCasicurezza:”（安全验证）是可选的头字段，用于与病毒相关的PEC通知。
Body contents differ according to notification type. This is described more thoroughly in section 3.
正文内容因通知类型而异。第3节对此进行了更详细的描述。
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:
进入PEC网络的消息被插入特定的PEC消息（称为信封）中，然后才允许它们在网络中进一步传播。这些信封必须从邮件本身继承以下标题字段及其未修改的值：
o Received:
o 收到：
o To:
o 致：
o Cc:
o 复写的副本：
o Return-Path:
o 返回路径：
o Reply-To: (if present)
o 答复：（如有）
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.
根据请求进入PEC网络的消息类型，它将被插入PEC传输信封或PEC异常信封中。可通过添加“X-Trasporto:”标题字段进行区分。
+-------------+ +------------+
| +--+ | | |
| |AP| | PEC | |
+----+ | +--+ | messages & | +---+ +--+ | +----+
|user|<-->| |<------------->| |InP| |DP| |<-->|user|
+----+ | +--+ +---+ | notifications | +---+ +--+ | +----+
| |DP| |InP| | | |
| +--+ +---+ | | |
+-------------+ +------------+
PEC PEC
sender receiver
provider provider
+-------------+ +------------+
| +--+ | | |
| |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
AP=接入点DP=交付点InP=接入点
This is what the user client at the sender side interacts with, giving the user access to PEC services set up by the provider.
这是发送方的用户客户端与之交互的内容，允许用户访问由提供者设置的PEC服务。
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:
此类访问之前必须在系统上进行用户身份验证（见第5.2节）。接入点接收其用户希望发送的原始消息，运行一些正式检查，并根据结果采取行动：
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 如果消息通过所有检查，则接入点生成服务器用户接受PEC通知，并将原始消息插入PEC传输信封内；
o if a formal exception is detected, the Access Point refuses the message and emits the relevant non-acceptance PEC notification (see section 3.1.1);
o 如果检测到正式异常，接入点拒绝该消息并发出相关的不接受PEC通知（见第3.1.1节）；
o if a virus is detected, the Access Point generates a non-acceptance PEC notification and inserts the original message as is in the provider's special store.
o 如果检测到病毒，接入点将生成一个不接受PEC通知，并将原始消息按原样插入提供商的特殊存储中。
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.
服务器用户接受通知的生成向用户指示消息已被系统接受，并证明事件的日期和时间。通知必须包含用户可读的文本和包含认证数据的XML部分。通知还可能包含提供商提供的其他附加功能的附件。
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.
使用PEC providers目录中的可用数据（参见第4.5节），接入点对原始消息中“收件人：”和“抄送：”字段中的每个收件人进行检查，以验证他们是否属于PEC基础设施或非PEC域。通过在PEC providers目录中找到的“managedDomains”属性中进行不区分大小写的搜索，验证收件人的域是否存在，从而完成此类检查。因此，对于每个地址，服务器用户接受PEC通知（和相关认证数据）与其域的类型相关；PEC或非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:
PEC基础设施内接受的原始消息的消息标识符（PEC msgid）必须明确，以便正确跟踪消息和相关PEC通知。此类标识符的格式为：
[alphanumeric string]@[provider mail domain]
[字母数字字符串]@[提供商邮件域]
or:
或：
[alphanumeric string]@[FQDN mail server]
[字母数字字符串]@[FQDN邮件服务器]
Therefore, both the original message and the corresponding PEC transport envelope MUST contain the following header field:
因此，原始消息和相应的PEC传输信封必须包含以下标头字段：
Message-ID: <[unique identifier]>
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:
当与接入点交互的电子邮件客户端已在原始消息中插入消息标识符（msgid）时，该msgid应替换为PEC msgid。为了允许发件人将发送的邮件与相关PEC通知链接起来，必须在原始邮件以及相关PEC通知和传输信封中插入msgid。如果存在，则通过添加以下标头字段，原始邮件的标头中需要msgid：
X-Riferimento-Message-ID: <[msgid]>
X-Riferimento-Message-ID: <[msgid]>
which will also be inserted in the PEC transport envelope and notifications, and related in the certification data (see section 4.4).
也将插入PEC运输信封和通知中，并与认证数据相关（见第4.4节）。
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.
这一点允许PEC提供者之间交换PEC消息和通知。它也是普通邮件信息可以插入到认证邮件系统中的点。
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.
提供程序之间的消息交换通过[SMTP]中定义的基于SMTP的事务进行。如果发生SMTP通信错误，可以使用[SMTP]和[SMTP-DSN]中SMTP提供的标准错误通知机制来处理这些错误。在SMTP传输阶段，也采用相同的机制来处理导致长时间空闲的暂时性错误。为了保证将错误返回给用户，如第3.3.3节所定义，处理PEC流量的系统必须采用等于24小时的消息空闲时间限制。
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 验证传入消息的正确性和类型；
o if the incoming message is a correct and undamaged PEC transport envelope:
o 如果传入消息是正确且未损坏的PEC传输信封：
- emits a server-server acceptance PEC notification towards the sender provider (section 3.2.1);
- 向发送方提供商发出服务器接受PEC通知（第3.2.1节）；
- forwards the PEC transport envelope to the Delivery Point (section 3.3).
- 将PEC运输信封转发至交付点（第3.3节）。
o if the incoming message is a correct and undamaged PEC notification, forwards the notification to the Delivery Point.
o 如果传入消息是正确且未损坏的PEC通知，则将通知转发到传递点。
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.
o 如果传入消息不符合正确且未损坏的PEC传输信封或通知的先决条件，但来自PEC提供商，即通过了有关签名存在、来源和有效性的验证，则必须将消息传播给收件人。
Therefore, the Incoming Point:
因此，输入点：
- inserts the incoming message in a PEC anomaly envelope (section 3.2.2);
- 将传入消息插入PEC异常信封（第3.2.2节）；
- forwards the PEC anomaly envelope to the Delivery Point.
- 将PEC异常信封转发到交付点。
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:
o 如果传入消息不是来自PEC系统，即未能验证签名的存在性、来源和有效性，则该消息将被视为普通电子邮件，如果传播给收件人：
- is inserted in a PEC anomaly envelope (section 3.2.2);
- 插入PEC异常包络（第3.2.2节）；
- the PEC anomaly envelope is forwarded to the Delivery Point.
- PEC异常信封被转发到交付点。
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.
服务器接受PEC通知由接收提供程序生成并发送给发送提供程序。它的目的是跟踪消息从一个提供者到另一个提供者的转换，因此严格来说是提供者内部通信；最终用户对此一无所知。
To check the correctness and integrity of a PEC transport envelope or notification, the Incoming Point runs the following tests:
为了检查PEC传输信封或通知的正确性和完整性，传入点运行以下测试：
o Signature existence - the system verifies the presence of an S/MIME signature structure within the incoming message;
o 签名存在-系统验证传入消息中是否存在S/MIME签名结构；
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 签名来源-系统通过提取用于签名的证书并验证其是否存在于PEC providers目录中，来验证签名是否属于PEC provider。为了简化检查，可以计算证书的[SHA1]哈希值，并在PEC providers目录中找到的“providerCertificateHash”属性中对其十六进制表示形式执行不区分大小写的搜索。此操作允许用户轻松识别发送方提供者，以便在提取的证书与提供者记录中的证书之间进行后续必要的匹配检查；
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 签名有效性-通过重新计算签名值、检查整个证书路径以及验证证书的[CRL]和时间有效性来验证S/MIME签名的正确性。如果对CRL内容使用了某种缓存机制，则必须采用更新间隔，以保证最新的数据，从而最大限度地减少证书颁发机构撤销发布和提供商确认变更之间可能出现的延迟；
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).
o 形式正确性-提供商执行充分和必要的检查，以确保传入消息符合本文档中指定的格式（PEC传输信封和通知）。
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.
如果一个感染病毒的PEC运输信封通过了刚才提到的检查，它仍然被认为是正确的，没有损坏。将在第二阶段检测病毒的存在，在此期间验证PEC传输信封的内容。因此，传入点将避免将消息转发给收件人，而是发送未传递的适当PEC通知，并将感染病毒的消息存储在提供商的专用存储器中。
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.
如果收到普通邮件消息，PEC提供商应进行病毒检查，以防止潜在危险邮件消息渗透到PEC系统中。如果在普通邮件中检测到病毒，则可以在病毒进入PEC系统之前在传入点丢弃病毒。换言之，不对错误进行特殊处理；它的处理方式与通过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:
当接收提供商在接收阶段检测到PEC传输信封内的病毒时，它向发送提供商发出病毒检测PEC通知，然后发送提供商意识到其检查未能检测到该病毒。发生这种情况时，发送提供程序必须：
o check what virus typologies were not detected by its own antivirus to verify the possibility of interventions
o 检查其自身的防病毒软件未检测到的病毒类型，以验证干预的可能性
o send a virus-induced non-delivery PEC notification to the sender's mailbox.
o 向发件人的邮箱发送由病毒引起的未送达PEC通知。
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).
在将接收到的消息转发给用户之前，必须对其运行一系列测试（见第3.3.1节）。它首先验证消息的类型，并决定是否应向发送方发出PEC通知。递送PEC通知（第3.3.2节）在邮件送达收件人的PEC邮箱后发出，并且仅在收到有效的PEC传输信封时发出（第2.2.2节和第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.
在所有其他情况下，例如PEC异常信封和PEC通知，不会发出传递PEC通知。无论如何，从传递点接收的邮件必须未经修改地传递到收件人的邮箱。
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.
delivery PEC通知向发件人表明，发送的邮件实际上已传送到指定收件人的邮箱，并通过使用用户可读文本和包含认证数据的XML部分，以及为提供商提供的额外功能添加的其他可能附件，来认证发送日期和时间。
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.
如果在传递点收到的PEC传输信封无法传递到目标邮箱，则传递点将发出未传递PEC通知（第3.3.3节）。另一方面，如果传递错误涉及来自互联网的消息（即，非PEC消息），则不会发出此类通知。
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.
每个提供商都必须专用于存储遇到的任何受病毒感染的邮件。无论是发送方的接入点还是接收方的接入点检测到病毒，检测到病毒的提供商必须将邮件信息存储在自己的存储器中，并保存30个月。
For exclusive use of the provider, dedicated to the reception of PEC notifications in two cases only:
仅供提供商专用，仅在两种情况下用于接收PEC通知：
o server-server acceptance notification; and
o 服务器接受通知；和
o virus detection notification.
o 病毒检测通知。
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.
如第3节所述，各提供商必须注册一个专用电子邮件地址，以便在发送PEC运输信封和通知时使用。该地址可能与第2.2.5节所述的服务邮箱地址一致。
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 消息标识符（msgid）
o date and time of event
o 活动日期和时间
o sender of original message
o 原始邮件的发件人
o recipient(s) of original message
o 原始邮件的收件人
o subject of original message
o 原始信息的主题
o event type (reception, delivery, PEC notification emission, etc.)
o 事件类型（接收、交付、PEC通知发出等）
o message identifiers of related generated messages
o 相关生成消息的消息标识符
o sending provider
o 发送提供程序
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.
服务提供商必须存储此数据，并将其保留为未经修改的数据。意大利法律规定，服务提供商将数据保留30个月。
The Access Point acts as a submission service as defined in [SUBMISSION].
接入点充当[提交]中定义的提交服务。
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 [电子邮件]标题部分包含“发件人：”标题字段，其中包含符合[电子邮件]要求的电子邮件地址；
o [EMAIL] header section contains a "To:" header field holding one or more [EMAIL] compliant email addresses;
o [电子邮件]标题部分包含一个“收件人：”标题字段，其中包含一个或多个符合[电子邮件]要求的电子邮件地址；
o sender's address, specified in the SMTP reverse path, coincides with the one in the message's "From:" header field;
o SMTP反向路径中指定的发件人地址与邮件“发件人：”标题字段中的地址一致；
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 SMTP转发路径中指定的收件人地址与邮件“收件人：”或“抄送：”标题字段中的地址一致；
o "Bcc:" header field does not contain any value;
o “密件抄送：”标题字段不包含任何值；
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.
o 消息总大小在提供程序接受的限制范围内。这些限制也取决于接收者的数量；通过将其乘以消息大小，结果必须在提供者接受的限制范围内。意大利法律规定这一限制为30 MB。
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.
如果消息未通过测试，则接入点不得在PEC系统内接受消息，从而发出不接受的相对PEC通知。
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.
当接入点由于未能通过正式检查而无法转发接收到的消息时，发送方将收到此类结果的通知。如果错误是由于消息未通过大小检查造成的，则只要大小仍受某个限制，就会发送不接受PEC通知。如果大小超过上述限制，则错误处理将留给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]
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]
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.
将相同的认证信息插入要添加到通知正文的XML文件中，从而允许对消息进行自动检查（第4.4节）。必须仅对XML部分进行解析。对于供应商特定的服务，供应商可能会包括其他部分。无论如何，不得包含原始邮件。消息必须遵循第4.3节中描述的格式。
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.
接入点必须对从其用户收到的消息内容运行一些测试，如果检测到病毒，则拒绝这些测试。在这种情况下，必须发出由病毒检测引发的不接受PEC通知，以清楚地告知用户消息被拒绝的原因。
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]
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]
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.
相同的认证数据插入到添加到通知的XML文件中，以允许自动检查（第4.4节）。必须仅对XML部分进行解析。对于供应商特定的服务，供应商可能会包括其他部分。无论如何，不得包含原始邮件。消息必须遵循第4.3节中描述的格式。
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.
服务器用户接受PEC通知是由其服务器发送给发件人的消息，包含系统接受消息的日期和时间、发件人和收件人数据以及主题。
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]
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]
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.
相同的认证数据插入到添加到通知消息的XML文件中，允许对其进行自动检查（第4.4节）。必须仅对XML部分进行解析。对于供应商特定的服务，供应商可能会包括其他部分。消息必须遵循第4.3节中描述的格式。
A PEC transport envelope is a message generated by the Access Point that contains the original message as well as certification data.
PEC传输信封是由接入点生成的包含原始消息和认证数据的消息。
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:
如第2.1.1.2节所述，PEC传输信封从原始消息中继承了以下标题字段的值，这些字段必须是未经修改的相关字段：
o Received:
o 收到：
o To:
o 致：
o Cc:
o 复写的副本：
o Return-Path:
o 返回路径：
o Reply-To: (if present)
o 答复：（如有）
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]
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.
“X-TipoRicevuta:”字段表示发件人希望接收的传递PEC通知的类型—完整、简短或简明。
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:
PEC传输信封的主体包含文本部分，该文本部分根据与以下认证数据相关的模型构成消息的可读格式：
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]
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.
在PEC传输信封内，以符合[电子邮件]的格式插入整个未修改的原始邮件（关于邮件标识符的说明除外），以及XML部分，其中包含已以文本格式相关的认证数据，以及有关所请求的消息类型和PEC通知的信息（第4.4节）。必须仅对XML部分进行解析。对于供应商特定的服务，供应商可能会包括其他部分。消息必须遵循第4.3节中描述的格式。
Note that the routing data of the PEC transport envelope (forward and reverse paths) remain unaltered.
请注意，PEC传输包线（正向和反向路径）的路由数据保持不变。
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.
如果发送提供程序在邮件发送后12小时内未收到来自接收提供程序的服务器接受或传递PEC通知，则会通知用户收件人的提供程序可能无法传递邮件。如果发送提供程序在消息发送后24小时内没有收到传递PEC通知，则在24小时超时之前，但在22小时过去之前，它会向用户发出另一个未传递PEC通知。
Such a communication takes place through a PEC notification of non-delivery due to timeout, the header of which contains the following fields:
此类通信通过因超时而未交付的PEC通知进行，其标头包含以下字段：
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]
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:
第一个未送达PEC通知（12小时超时）的正文包含一个文本部分，表示通知的可读格式，该格式将与以下数据相关：
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]
[日期]在[时间]（[时区]）发出的未送达PEC通知，从“[原始发件人]”发出并发送至“[收件人]”的邮件“[主题]”在发送后的前12小时内未送达。不排除消息最终会被传递，被认为是有用的，认为派遣可能没有积极的结果。如果在接下来的12小时内未收到收件人的确认，系统将发送另一个未送达PEC通知。消息标识符：[对应PEC传输信封的PEC msgid]
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:
另一方面，具有如上所述相同标题的24小时超时诱导PEC通知的正文中将包含以下文本：
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.
[日期]在[时间]（[时区]）发出的未送达PEC通知，从“[原始发件人]”发送至“[收件人]”的邮件“[主题]”在发出后24小时内未送达。
The transaction is deemed to be considered terminated with a negative outcome. Message identifier: [PEC msgid of corresponding PEC transport envelope]
交易被视为因负面结果而终止。消息标识符：[对应PEC传输信封的PEC msgid]
The same certification data is inserted in an XML file added to both PEC notification types to allow automatic checks (section 4.4).
在两种PEC通知类型中添加的XML文件中插入相同的认证数据，以允许自动检查（第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.
必须仅对XML部分进行解析。可为PEC供应商提供的服务添加其他部件。无论如何，不得包含原始邮件。消息必须遵循第4.3节中描述的格式。
A timeout PEC notification is generated if one of the following scenarios occurs:
如果出现以下情况之一，将生成超时PEC通知：
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 发送提供程序在消息分派后的前12小时内收到服务器接受PEC通知，但根本没有收到传递PEC通知。在这种情况下，它将是一个24小时的超时PEC通知。
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 发送提供程序不会收到服务器接受PEC通知，但会在12小时后和24小时超时之前收到传递PEC通知。在这种情况下，它将是一个12小时的超时PEC通知。
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.
o 发送提供程序未收到服务器接受或传递PEC通知。在这种情况下，生成两个超时PEC通知；12小时和24小时超时PEC通知。
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
在PEC提供商之间交换正确的PEC传输信封（如第2.2.2节所定义）时，接收方必须向发送方发送服务器接受PEC通知。如SMTP事务的路由数据（正向和反向路径）中所述，单个已发送通知涉及属于同一提供商的所有收件人，以及传入邮件的地址。在单个服务器的认证数据中
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.
接受PEC通知，将列出它所引用的邮件的所有收件人。通常，在接收PEC传输信封时，每个提供程序必须发出一个或多个服务器接受PEC通知，以在没有SMTP传输错误的情况下覆盖其管辖范围内的所有收件人。
The header of a server-server acceptance PEC notification contains the following fields:
服务器接受PEC通知的标头包含以下字段：
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]
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.
在签名验证阶段进行必要的查询期间，提供商的服务电子邮件地址从PEC提供商目录中获取。
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]
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.
相同的认证数据插入到XML文件中，该文件添加到通知消息中，以允许自动检查（第4.4节）。必须仅对XML部分进行解析。供应商可为特定于供应商的服务添加其他部件。消息必须遵循第4.3节中描述的格式。
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
如果对传入邮件的测试检测到错误，或者该邮件被标识为普通邮件，并且提供程序被设置为将其转发给收件人，则系统必须将此类邮件插入PEC异常信封中。在传递之前，会收到整个邮件
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:
在传入点以符合[EMAIL]的格式插入，作为新邮件中的[MIME1]部分，新邮件必须继承接收到的邮件中以下标题字段的未修改值：
o Received:
o 收到：
o To:
o 致：
o Cc:
o 复写的副本：
o Return-Path:
o 返回路径：
o Message-ID:
o 消息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)]
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.
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.
由于接收到的消息的来源和/或一致性不确定，PEC异常信封不得包含到达传入点的整个消息以外的[MIME1]部分。
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]).
请注意，这种封套的路由数据（正向和反向路径）保持不变。这样做既可以保证邮件转发给收件人，也可以保证发件人收到SMTP错误通知（如果有）（如[SMTP]和[SMTP-DSN]中所述）。
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.
如果传入点接收到受病毒感染的PEC消息，则不得转发这些消息。相反，它必须将失败的传输通知发送提供商，而发送提供商将反过来通知发送用户。必须代表提供商域内的每个收件人发送单独的PEC病毒检测通知。
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.
如果在邮件的接收阶段检测到病毒，而该邮件的来源是通过发件人签名验证确认的，则系统将生成一个病毒检测到的PEC通知，指示发现的错误，并将其发送到发送提供商的服务邮箱。
The header of this PEC notification contains the following fields:
此PEC通知的标题包含以下字段：
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]
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]
病毒检测PEC通知于[日期]在[时间]（[时区]）在源于“[原始发件人]”并发送至“[收件人]”的消息“[主题]”中检测到安全问题[检测到内容类型的ID]。消息标识符：[对应PEC传输信封的PEC msgid]
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.
将相同的认证数据插入XML文件并添加到通知中，以允许自动检查（第4.4节）。必须仅对XML部分进行解析。对于供应商特定的服务，供应商可能会包括其他部分。无论如何，不得包含原始邮件。消息必须遵循第4.3节中描述的格式。
The message body MUST contain the reason for which the transmission could not be completed.
消息正文必须包含无法完成传输的原因。
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.
在接收到来自接收提供商的病毒检测PEC通知时，发送方提供商向发送用户发出未送达PEC通知。
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]
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]
由于病毒在[日期]在[时间]（[时区]）向“[收件人]”发送的邮件“[主题]”中发送错误PEC通知，检测到安全问题[反病毒检测到的内容类型ID]。消息没有传递。消息标识符：[对应PEC传输信封的PEC msgid]
All the information necessary for the construction of such a PEC notification can be obtained from the correlated virus-detected PEC notification.
构建此类PEC通知所需的所有信息都可以从检测到的相关病毒PEC通知中获得。
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.
将相同的认证数据插入XML文件并添加到通知消息中，以允许自动检查（第4.4节）。必须仅对XML部分进行解析。对于供应商特定的服务，供应商可能会包括其他部分。交易未完成的原因必须在消息中指定，消息必须遵循第4.3节所述的格式。
When a message arrives at the Delivery Point, the system verifies:
当消息到达传递点时，系统将验证：
o message type
o 消息类型
o whether or not a PEC notification has to be returned.
o 是否必须返回PEC通知。
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.
只有在将正确的PEC传输信封（第2.2.2节和第3.1.5节）送达收件人邮箱后，才会发出递送PEC通知。
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.
在所有其他情况下（例如，PEC异常信封、PEC通知），不发布交付PEC通知。无论如何，在传递点接收的邮件必须原封不动地传递到收件人的邮箱。
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.
此通知告知用户其邮件已成功送达指定收件人。它包括证明交付日期和时间、发送方和接收方数据以及主题的可读文本。它还包含一个XML认证数据文件和其他可选部分，用于提供程序提供的功能。
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]
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.
PEC传输信封中“X-TipoRicevuta:”标头字段的值源自原始邮件，因此允许发件人确定从原始邮件的主要收件人请求的传递PEC通知的类型。通知必须遵循第4.3节所述的格式。
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
这是传递PEC通知的默认值。如果未指定“X-TipoRicevuta:”的值，或当其包含值“completa”（完成）时，系统将需要一个完整的
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.
收件人在“收件人：”字段中发送PEC通知，而“抄送：”字段中的收件人将需要简洁的PEC通知（第3.3.2.3节）。通过对“收件人：”和“抄送：”字段的分析来区分主要收件人和复印件中的收件人。对于代表主要收件人发送的PEC通知，将在通知中插入原始邮件的完整副本以及任何附件。如果负责传递的系统由于“收件人：”和“抄送：”字段中的歧义问题而无法确定收件人类型，则必须将传递视为发送给主要收件人，并包含原始邮件的完整副本。
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]
于[日期]在[时间]（[时区]）发送PEC通知时，源于“[原始发件人]”并发送至“[收件人]”的邮件“[主题]”已放置在目标邮箱中。消息标识符：[对应PEC传输信封的PEC msgid]
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.
将相同的认证数据插入XML文件并添加到通知中（第4.4节），以及提供商可能为特定于提供商的服务插入的任何其他部分。必须仅对XML部分进行解析。递送PEC通知必须代表邮件的每个收件人发出，并且必须遵循第4.3节所述的格式。
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.
为了减少数据流量，发送方可以要求以“简短”格式发送PEC通知。简短传递PEC通知包含原始消息及其每个部分的加密哈希值。哈希值应在base64编码部分上计算。如第5.3节所述，PEC消息只能在属于PEC网络的机器上传输，并且在传输/处理过程中不得改变消息的编码。
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
注意：尽管PEC使用这些宽松的规范，但20多家服务提供商之间的PEC互操作性测试从未发现任何问题。这可能是因为邮件服务器更倾向于将收到的邮件原封不动地保留下来
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.
应用任何更改。但如果服务器决定修改编码部分，则可能会出现问题；例如，更改base64行长度，其在接收方端计算的哈希值将与发送方端计算的哈希值不同。
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:
如果PEC运输信封包含标题：
X-TipoRicevuta: breve
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.
交付点代表主要接收人发出一份简短的交付PEC通知，并代表复印件接收人发出一份简明的交付PEC通知（第3.3.2.3节）。PEC传输信封中标头字段的值源自原始消息。
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]
在[日期]于[时间]（[时区]）发出的简短投递PEC通知中，源于“[原始发件人]”并寄往“[收件人]”的邮件“[主题]”已放置在目的地的邮箱中。消息标识符：[对应PEC传输信封的PEC msgid]
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.
将相同的认证数据插入XML文件并添加到通知中（第4.4节），以及可能包含在特定提供商提供的服务中的其他部分。必须仅对XML部分进行解析。递送PEC通知代表邮件的每个收件人发出，并且必须遵循第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.
原始消息的MIME结构在添加到通知时不变，但在标题字段“Content Type:”中具有“name”参数或在标题字段“Content Disposition:”中具有“filename”参数的每个MIME部分必须由包含该MIME部分的哈希值的文本文件替换。
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]):
当原始消息具有S/MIME格式时，不必改变消息结构的完整性。检查顶级实体（与消息本身一致）的MIME类型时，将验证原始消息中的S/MIME部分。S/MIME消息可能具有以下MIME类型（根据[SMIMEV3]）：
o multipart/signed
o 多部分/签名
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;
表示发件人使用[MIME-SECURE]中描述的结构签名的原始邮件。消息由两个MIME部分组成：第一部分是应用发送方签名之前的消息本身，而第二部分包含签名数据。第二部分（通常类型为“application/pkcs7 signature”或“application/x-pkcs-signature”）包含在签名阶段添加的数据，必须保持不变，以避免影响整个消息结构；
o "application/pkcs7-mime" or "application/x-pkcs7-mime"
o “应用程序/pkcs7 mime”或“应用程序/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.
消息由MIME部分中唯一的CMS对象组成。假设附件不能与CMS对象分离，MIME部分保持不变（即，它不会被哈希值替换）；因此，简短的PEC通知与完整的PEC通知相同。
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.
如果原始消息包含“内容类型：”为“message/rfc822”的部分，即包含作为附件的电子邮件消息，则用其相应的哈希值替换整个附件消息。
Therefore, when emitting a brief delivery PEC notification, the provider MUST:
因此，当发出简短的交付PEC通知时，提供商必须：
1. identify and extract all the parts from the first MIME part of the multipart/signed S/MIME message;
1. 识别并提取多部分/签名S/MIME消息的第一个MIME部分的所有部分；
2. calculate the hash values of all the files attached by the sender to the original message;
2. 计算发件人附加到原始邮件的所有文件的哈希值；
3. substitute originals with their hash values.
3. 用它们的散列值替换原始值。
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:
一般来说，对于S/MIME格式的原始邮件，在简短传递PEC通知中插入的邮件副本将具有以下特征：
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 如果原始消息已签名，则S/MIME结构和签名相关数据将保持不变。在用相应的哈希值替换附件之后，该消息将在未来的签名完整性验证阶段生成错误。
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
o 如果原始邮件包含“application/pkcs7 mime”或“application/x-pkcs7-mime”mime类型，则由于
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.
无法在CMS结构中识别。简要交付PEC通知的内容将与正常交付PEC通知的内容一致。
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.
用于散列计算的算法是[SHA1]，它是根据零件的整个内容计算的。为了区分散列文件和它们所引用的文件，将后缀“.hash”添加到原始文件名中。散列值使用十六进制表示法写入文件，表示为40个字符的单个序列。这些附件的MIME类型设置为“text/plain”，以突出显示其文本性质。
If the PEC transport envelope contains the header:
如果PEC运输信封包含标题：
X-TipoRicevuta: sintetica
X-TipoRicevuta:Sintica
the Delivery Point emits, both to primary and carbon copy recipients, a concise delivery PEC notification that does not contain the original message.
传递点向主要和副本接收者发出不包含原始消息的简明传递PEC通知。
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]
简明投递PEC通知于[日期]在[时间]（[时区]）时，源于“[原始发件人]”并寄往“[收件人]”的邮件“[主题]”已放置在目的地的邮箱中。消息标识符：[对应PEC传输信封的PEC msgid]
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.
相同的认证数据插入到XML文件中，并添加到通知中（第4.4节），以及供应商特定服务可能包含的其他部分。必须仅对XML部分进行解析。通知将发送给收到邮件的每个收件人，并且必须遵循第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.
简明交付PEC通知遵循与交付PEC通知相同的排放规则；只添加了包含认证数据的XML文件，而不是原始消息。
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.
如果在传递正确的PEC传输消息的过程中发生错误，系统将向发送方返回指示错误情况的未送达PEC通知。
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]
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]
在[时间]（[时区]）于[日期]发出的未送达PEC通知中，在源自“[原始发件人]”并发送至“[收件人]”的消息“[主题]”中检测到错误[简要错误说明]。该消息被系统拒绝。消息标识符：[对应PEC传输信封的PEC msgid]
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.
在XML文件中插入相同的认证数据，并将其添加到通知中，以便进行自动检查（第4.4节）。必须仅对XML部分进行解析。PEC供应商可能会为供应商特定的服务提供额外的部件。通知必须遵循第4.3节所述的格式。
PEC messages MUST be processed even if both sender and receiver(s) belong to the same PEC domain.
即使发送方和接收方都属于同一PEC域，也必须处理PEC消息。
A correct transaction between two PEC domains goes through the following steps:
两个PEC域之间的正确事务需要执行以下步骤：
o The sending user sends an email to his provider's Access Point;
o 发送用户向其提供商的接入点发送电子邮件；
o The Access Point runs all checks and emits a server-user acceptance PEC notification to the user;
o 接入点运行所有检查并向用户发出服务器用户接受PEC通知；
o The Access Point creates a PEC transport envelope and forwards it to the Incoming Point of the receiving provider;
o 接入点创建PEC传输信封并将其转发给接收提供商的接入点；
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 接收方的输入点验证PEC传输信封，并创建服务器接受PEC通知以发送给发送提供商；
o The sender's Incoming Point verifies the validity of the server-server acceptance PEC notification and forwards it to the Delivery Point;
o 发送方的传入点验证服务器接受PEC通知的有效性，并将其转发给传递点；
o The sender's Delivery Point saves the server-server acceptance PEC notification in the provider's service mailbox;
o 发送方的传递点将服务器接受PEC通知保存在提供商的服务邮箱中；
o The receiver's Incoming Point forwards the PEC transport envelope to the receiver's Delivery Point;
o 接收器的输入点将PEC传输信封转发到接收器的交付点；
o The receiver's Delivery Point verifies the contents of the PEC transport envelope and saves it in the recipient's mailbox;
o 接收方的交付点验证PEC传输信封的内容，并将其保存在接收方的邮箱中；
o The receiver's Delivery Point creates a delivery PEC notification and sends it to the sender's Incoming Point;
o 接收方的交付点创建一个交付PEC通知，并将其发送到发送方的传入点；
o The sender's Incoming Point verifies the validity of the delivery PEC notification and forwards it to the sender's Delivery Point;
o 发送方的传入点验证传递PEC通知的有效性，并将其转发给发送方的传递点；
o The sender's Delivery Point saves the delivery PEC notification in the sending user's mailbox;
o 发送方的传递点将传递PEC通知保存在发送用户的邮箱中；
o The receiving user has the message at his disposition.
o 接收用户可自行处理该消息。
NOTE: Some of these steps might occur in parallel, thus the interaction might complete in a different order.
注意：其中一些步骤可能并行进行，因此交互可能以不同的顺序完成。
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.
对于由访问点、传入点和传递点在消息、通知和日志细化过程中执行的所有操作，有必要提供准确的时间参考。所有事件（PEC通知的生成、传输信封、日志等）构成访问点、传入点和交付点的消息细化事务，必须使用从事务本身中获得的唯一时间值。
Doing this renders the instant of message elaboration unambiguous within PEC logs, notifications, messages, etc., generated by the server.
这样做会使服务器生成的PEC日志、通知、消息等中的即时消息细化变得清晰。
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].
服务以可读格式（PEC通知中的文本、传输信封等）提供的时间指示参考操作时的法定时间。以下是使用[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
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 ")"
time-offset = "(" ("+" / "-") time-hour ":" time-minute ")"
partial-time = time-hour ":" time-minute ":" time-second
partial-time = time-hour ":" time-minute ":" time-second
full-date = date-mday "/" date-month "/" date-fullyear
full-time = partial-time time-offset
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].
注：月天数、闰年和闰秒限制见[时间戳]第5.7节。
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]).
本节介绍PEC系统生成的PEC消息和通知的各个组件的特性。如果其中一个消息部分包含值超出范围0-127（7位ASCII）的字符，则必须对该部分进行充分编码，以保证7位传输兼容性（例如，根据[MIME1]引用的可打印、base64）。
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.
在应用签名之前，消息正文的内容类型为：multipart/mixed。各部分将在以下各节中介绍。第一部分是PEC系统生成的用户可读文本，而第二和第三部分在顺序上是可互换的，并且包含原始消息和认证数据的XML文件。
Character set: ISO-8859-1 (Latin-1)
MIME type: text/plain or multipart/alternative
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:
multipart/alternative MIME类型可用于添加系统生成消息体的HTML版本。在这种情况下，必须存在两个子部分：一个是text/plain，另一个是text/html。对于HTML部分：
o it MUST contain the same information as related in the text part;
o 它必须包含与文本部分相关的相同信息；
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 它不得包含对元素（例如图像、声音、字体、样式表）的引用，既不是消息内部的（添加的MIME部分），也不是外部的（例如，托管在提供商的服务器上）；
o it MUST NOT have active content (e.g., JavaScript, VBscript, Plug-in, ActiveX).
o 它不能有活动内容（例如JavaScript、VBscript、插件、ActiveX）。
MIME type: message/rfc822 Attachment name: postacert.eml
MIME类型：message/rfc822附件名称：postacert.eml
Character set: UTF-8 MIME type: application/xml Attachment name: certdata.xml
字符集：UTF-8 MIME类型：应用程序/xml附件名称：certdata.xml
Following is the DTD relative to the [XML] file that contains certification data attached to PEC notifications.
以下是与[XML]文件相关的DTD，该文件包含附加到PEC通知的认证数据。
<!--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
<!--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
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">
tipo（accettazione |非accettazione |加共体主席| avvenuta consegna |邮政认证| ERROR consegna | preavviso ERROR consegna | rilevazione病毒|要求的错误|无目的地|无dominio |病毒| altro | |阿尔特罗nessuno”>
<!--Header of the original message-->
<!ELEMENT intestazione (mittente,
destinatari+,
risposte,
oggetto?)>
<!--Header of the original message-->
<!ELEMENT intestazione (mittente,
destinatari+,
risposte,
oggetto?)>
<!--Sender ("From:" field) of the original message-->
<!ELEMENT mittente (#PCDATA)>
<!--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">
<!--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)>
<!--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?)>
<!--PEC消息数据--><！元素数据（gestore发射、数据、标识、msgid？、ricevuta？、consegna？、ricezione*、errore esteso？）>
<!--Descriptive string of the provider that certifies -->
<!--the data-->
<!ELEMENT gestore-emittente (#PCDATA)>
<!--Descriptive string of the provider that certifies -->
<!--the data-->
<!ELEMENT gestore-emittente (#PCDATA)>
<!--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>
<!--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)>
<!--Day in "dd/mm/yyyy" format-->
<!ELEMENT giorno (#PCDATA)>
<!--Local hour in "hh:mm:ss" format-->
<!ELEMENT ora (#PCDATA)>
<!--PEC msgid-->
<!ELEMENT identificativo (#PCDATA)>
<!--PEC msgid-->
<!ELEMENT identificativo (#PCDATA)>
<!--msgid of the original message before modifications-->
<!ELEMENT msgid (#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 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)>
<!--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)>
<!--In case of error-->
<!--brief description of the error-->
<!ELEMENT errore-esteso (#PCDATA)>
The PEC providers directory is created through a centralized LDAP server that contains the providers' data and their corresponding PEC mail domains.
PEC providers目录是通过一个集中的LDAP服务器创建的，该服务器包含提供者的数据及其相应的PEC邮件域。
The following are the directory scheme's attributes:
以下是目录方案的属性：
- providerCertificateHash: hash of provider's certificate
- providerCertificateHash：提供程序证书的哈希
- providerCertificate: provider certificate
- providerCertificate:提供程序证书
- providerName: provider name
- 提供者名称：提供者名称
- mailReceipt: provider reception email address
- MailReceive：提供商接收电子邮件地址
- managedDomains: managed domains
- managedDomains：托管域
- LDIFLocationURL: provider LDIF record URL
- LDIFLocationURL:提供程序LDIF记录URL
- providerUnit: secondary operating environment name
- providerUnit：辅助操作环境名称
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.
目录的基本根是“o=PostCert”，单个记录的“DiscrimitedName”类型为“<providerName=<name>，o=PostCert>”。目录内的搜索主要在区分大小写模式下使用“providerCertificateHash”属性（在信封签名验证阶段）或“managedDomains”属性（在邮件接受阶段）进行。单个提供者的记录可能包含多个具有相关“providerCertificateHash”属性的“providerCertificate”属性，以允许处理过期证书的续订。提供程序必须确保在证书到期日之前提前足够的时间更新其记录，方法是添加一个新的证书，该证书的有效期与前一个证书的有效期重叠。
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.
所有PEC提供者的数据都包含在[LDIF]文件中，该文件作为[HTTPS]对象提供，可在“dn:o=PostCert”记录中的“LDIFLocationURL”属性指向的URL处找到（见第4.5.6节）。为保证真实性，提供商必须使用针对单个提供商所述的方法对该文件进行签名，以执行有关其PEC服务的操作。文件、签名和X.509v3证书必须以二进制ASN.1 DER格式插入PKCS#7结构，作为扩展名为“.p7m”的文件。集中式[LDAP]系统每天下载该文件，并在对签名进行适当验证后，将其应用于提供商的记录。
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.
通过[LDIF]文件，单个提供者必须在本地保留一份目录副本，并每天更新，以避免在每个消息细化阶段向中央系统连续发送请求，从而提高系统性能。
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.
如果存在辅助环境，则主环境记录中指示的[LDIF]文件必须与所有提供商相关记录的内容相关。
NOTE: This specification uses an unregistered LDAP DN name space that may lead to conflict with other registered or unregistered names.
注意：此规范使用未注册的LDAP DN名称空间，这可能会导致与其他已注册或未注册的名称冲突。
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.
“providerCertificateHash”属性是提供程序用于PEC通知和信封签名的X.509v3证书的SHA1格式哈希的十六进制表示形式。
( 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 )
（1.3.6.1.4.1.16572.2.2.1十六进制格式的X.509证书的名称“providerCertificateHash”DESC“Hash SHA1”相等caseIgnoreIA5Match语法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].
IA5String（1.3.6.1.4.1.1466.115.121.1.26）语法在[LDAP-syntax]中定义。
The 'providerCertificate' attribute holds a set of certificate(s) used by the provider to sign PEC notifications and transport envelopes.
“providerCertificate”属性包含一组证书，供提供商用于签署PEC通知和传输信封。
( 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 )
（1.3.6.1.4.1.16572.2.2.2名称“providerCertificate”DESC“ASN.1 DER二进制格式的X.509证书”语法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].
[RFC4523]中定义了证书语法（1.3.6.1.4.1.1466.115.121.1.8）。
As required by this attribute type's syntax, values of this attribute are requested and transferred using the attribute description "providerCertificate;binary" [RFC4522].
根据该属性类型的语法要求，使用属性描述“providerCertificate；binary”[RFC4522]请求并传输该属性的值。
The 'providerName' attribute contains the name of the PEC provider. All records MUST contain their provider's name in this attribute.
“providerName”属性包含PEC提供程序的名称。所有记录必须在此属性中包含其提供程序的名称。
( 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 )
（1.3.6.1.4.1.16572.2.2.3名称“providerName”描述“PEC provider NAME”相等caseIgnoreMatch SUBSTR caseIgnoreMatch-SUBSTR caseIgnoreMatch语法1.3.6.1.4.1.1466.115.121.1.15单值）
The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is defined in [LDAP-SYNTAXES].
目录字符串（1.3.6.1.4.1.1466.115.121.1.15）语法在[LDAP-syntax]中定义。
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.
“MailReceive”属性包含提供程序内的提供程序电子邮件地址，服务器接受和病毒检测PEC通知将发送到该提供程序。此地址是[电子邮件]中描述的addr spec结构的有限版本（无尖括号）；它只允许在“@”的左右两侧使用点原子文本形式，并且没有内部CFW。
( 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 )
（1.3.6.1.4.1.16572.2.2.4服务邮箱的名称'mailReceipt'描述'E-mail address'EQUALITY caseIgnoreIA5Match SUBSTR caseignoreia5substrings匹配语法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].
IA5String（1.3.6.1.4.1.1466.115.121.1.26）语法在[LDAP-syntax]中定义。
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]).
“managedDomains”属性包含一组由PEC提供程序处理的域[SMTP]。域仅限于点原子形式（[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 )
（1.3.6.1.4.1.16572.2.2.5名称“managedDomains”描述由PEC提供程序处理的域“EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch语法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].
IA5String（1.3.6.1.4.1.1466.115.121.26）语法在[LDAP-syntax]中定义。
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]).
“managedDomains”属性包含一组由PEC提供程序处理的域[SMTP]。域仅限于点原子形式（[RFC1034]，[EMAIL]）。
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.
“LDIFLocationURL”属性包含一个[HTTPS]URL，该URL指向定义提供程序记录的[LDIF]文件的位置。当属性出现在记录“dn:o=postacert”中时，则它包含[LDIF]格式的整个目录的定义。LDIF文件的MIME类型为application/pkcs7 MIME，参数为smime type/signed data。[SMIMEV3]LDIF文件使用UTF-8字符集进行编码。
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.
辅助环境记录不得包含从连接到提供程序的所有记录的主环境属性中获取的“LDIFLocationURL”属性。
( 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 )
（1.3.6.1.4.1.16572.2.2.6定义条目“相等caseExactMatch语法1.3.6.1.4.1.1466.115.121.1.15单值”的LDIF文件的名称“LDIFLocationURL”DESC“URL”）
The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is defined in [LDAP-SYNTAXES].
目录字符串（1.3.6.1.4.1.1466.115.121.1.15）语法在[LDAP-syntax]中定义。
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.
“providerUnit”属性包含辅助操作环境的名称——主环境中不存在此属性。提供者可以定义几个不同的记录，每个记录都表示一个单独的、不同的辅助操作环境，如果需要，可以为其声明与主环境和其他环境相关的特定属性。
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.
与辅助操作环境相关的记录的“DifferentizedName”类型为“<providerUnits=<environment>，providerName=<name>，o=PostCert>”。每个提供程序都必须有一个与自己的主环境关联的记录，该记录和DiscrimitedName中没有“providerUnit”属性，因此可以区分。
( 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 )
（1.3.6.1.4.1.16572.2.2.7名称'providerUnit'DESC'二级运行环境名称'EQUALITY caseIgnoreMatch SubStrings匹配caseIgnoreMatch语法1.3.6.1.4.1.1466.115.121.1.15单值）
The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is defined in [LDAP-SYNTAXES].
目录字符串（1.3.6.1.4.1.1466.115.121.1.15）语法在[LDAP-syntax]中定义。
The schema definition of the 'LDIFLocationURLObject' object class:
“LDIFLocationURLObject”对象类的架构定义：
( 1.3.6.1.4.1.16572.2.1.1 NAME 'LDIFLocationURLObject' SUP top AUXILIARY MAY ( LDIFLocationURL ) )
（1.3.6.1.4.1.16572.2.1.1名称“LDIFLocationURLObject”SUP-top Assistant MAY（LDIFLocationURL））
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 )
（1.3.6.1.4.1.16572.2.1.2名称“提供商”支持顶部结构必须（提供商证书hash提供商证书提供商名称邮件接收管理器）
MAY ( description LDIFLocationURL providerUnit )
MAY（说明LDIFLocationURL提供单元）
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:
以下LDIF文件表示提供程序目录的示例，其中包含一个基本根目录和两个虚构的提供程序。插入的证书是两个自签名证书，仅用于示例目的：
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::
dn:o=PostCert对象类：顶级对象类：组织对象类：LDIFLocationURL对象o:PostCert LDIFLocationURL:https://igpec.rupa.example.com/igpec.ldif.p7m 描述：PEC提供程序目录dn:providerName=匿名认证邮件S.p.A.的基本根目录。，o=PostCert对象类：顶级对象类：提供商提供商提供商名称：匿名认证邮件S.p.A.提供商证书hash:7E7AEF1059AEE0F454F2643A95F69EC3556009239提供商证书；二元的：：
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
MIIDBjCCAm+Gawibagibadanbgkqhkig9w0BaqqfAdbmmqcqydvqgew Jjvdepmccga1echmgqw5vbmltysbqb3n0ysbdzxj0awzpy2f0ysbtlnau qs4xldaqbgkqhkig9w0bcqwhxbvc3rhlqgfucg9jzx j0lml10mb4m4mtaymtiwot3mjqnvoxxzzdzzzzzdzdzdztywot3mjqqnzzwzzwzzzzwg9bw9bwg9bwg9Eguy5Wlkejkozihvcnaqkbfh1wb3n0ys1jzxj0awzpy2f0Yubh bWy2vydc5pddcbnzanbgkqhkig9w0Baqefaobjqawgqcg8j+qK kdxv9lzdmp0p8h/kwbi0szzzzzzzzzzzznTznTznTzm9Ul09hdyyyx8AgjgzzzzzzzzzHyPzzzHyKf3bH73gf-Alzel4mql4mqlqwzzzzw4m8WbWbzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzWZCBWDBGNVHQ4EFGQUN8LC0ZNQWES0XSPZ/ABZSAGVRZMWGZAGAUDIW SBIDCBHYAUN8LC0ZNQWES0XPZ/ABZSAGVRZOQHAQROMGZZAJBGNVBAYT AKLUMSKWYDVQKEYBBBm9UAW1HIFBVC3RHIENLCNRPZMLJYXRHIFMUCC 5BLMCOGCSQIB3DQEYDG9ZDGEY2VYDYDOBYDGGWW5WB2NL CNQUAYXSCAWDQ0BAWKKK8BY2N/BGZAKKKKKKKKQQB9WW5W5W5WB2NZ+q1qSKpuffzTBpMtbeFkDIxMqMa+YCNXDMNVCWGCM1A9ZIFJSVQYHDQA XXFHJKRZXUSZKYQ6WIQCSLP0AYVY40QCIWBOUNHRVSH3VSG5CGN76JZZZ9 5Z/1CFNHLFQF1VH2NSS8TAYCCI/VO7W1Q1KkcA2VlxlQP7McSUw==邮件收据：ssacceptance@postalser.example.comLDIFLocationURL：https://anpocert.example.com/anpocert.ldif.p7m managedDomains:mail.anpocert.example.com managedDomains:cert.company.example.com managedDomains:costmec.example.com说明：公司的认证邮件服务
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
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
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
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:
以下LDIF文件表示PEC提供程序目录的示例，其中包含一个基本根目录和两个虚构的提供程序，其中第一个提供程序还处理辅助环境。插入的证书是两个自签名证书，仅用于示例目的：
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: 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.
dn:providerName=Anonymous Certified Mail S.p.A.，o=PostCert objectclass:top objectclass: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
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@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
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
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
BZZXJWB3N0YWWUAXQWHHCNMDIXMJA5MTCZMJE2WHCNMXMMJA5MTCZMJE2 WJBUMQSWCQYDVQGEWJVDEFMB0GA1ECHMWU2VYDML6ASBQB3N0YWYPMA0GA1ECXGRC5KUMS0WKWYJWYKOZNAQFH5WB3N0YS1JZJJJJJJ0AWZ2F0YWUZYWWUQWYWZ8WYWZZZJW8WDJ3N0YWYWYWWWWWYWYWWWYWYWYWWWWYWYWYWYWYWYWYWYVCNAQQBQ8BQ8BQBQ8WYBQQ8WYBQ8WYBQ8G8GygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIEaYZhYRGjhbcuJ9H/ZdtWdX XCWWN4WFZLSASOGSH5JEQS8DB3WKVHO9EUFACYK8YMAKXYDCTLD9S 9Tcyzete2UT9GMBAAGGCSWGCGWHQYDVR0OBYEFHPW7VJIOIM3VYHUHA EAWPF5LEM7VJIOIM3HYHAEYWAEKW7V7VYWAEYWAEYW9U2KKKKYW6MWKYW7V7V7V7V7V7JJJJJJJJJJJJKKKKYYYYW6MW6MW6MW6MW7YYYYYYYYW9LXPIFMUCI5SLJEPMA0GA1ECXMGRC5DLKMUMS0WKWWYJKOZIHVCNAQKBFH5W B3N0YS1JZJ0AWZPY2F0YUBZZXJWB3N0YWWUAXSCAQAYDVR0BAUWAW EB/ZANBKKKQHKIG9W0BAQQFAQOBGQAPQEXVMOYWHMRXPEXPEXELMZWV4QQ R4XTQ6SS9JRSBEBZRs+NMBCJJJJJJJJJJJ7E7EKJ7EKJ7EKJ7EKJ7EKJ7EFW7EKJ7EKJ7EKJ7EKJ7EKW7EKKKW7KKKKKKKKKKKKKZZZZZZZZZZZKKKKKKKKKKKKKssacceptance@postalser.example.comLDIFLocationURL：http://postalser.example.com/ldif.txt.p7m managedDomains:postal-services.example.com managedDomains:receivedmail.example.com说明：面向公众的认证邮件服务
It is recommended that a dedicated hardware module be used to handle private key and signature operations, the specifications of which are outside the scope of this document. It's up to the PEC providers to conform to security requisites expected for the service.
建议使用专用硬件模块处理私钥和签名操作，其规范不在本文档范围内。PEC提供商需要遵守服务的安全要求。
User access to PEC services through the Access Point MUST be allowed only upon successful user authentication on the system.
只有在系统上成功进行用户身份验证后，才能允许用户通过接入点访问PEC服务。
For example, authentication might use user-ID and password, or, if available and considered necessary for the type of service provided, an electronic ID card or the national services card. Choice of authentication method is left to the better judgment of the service provider. Authentication is necessary to guarantee as much as possible that the message is sent by a PEC user whose identification data is congruent with the specified sender, so as to avoid falsification of the latter.
例如，认证可以使用用户ID和密码，或者，如果提供的服务类型可用且认为必要，可以使用电子ID卡或国民服务卡。认证方法的选择取决于服务提供商的更好判断。身份验证是必要的，以尽可能保证消息由PEC用户发送，其标识数据与指定的发送者一致，从而避免后者被篡改。
To guarantee that the original message remains unaltered during transaction, envelopment and signature are applied on outgoing messages at the Access Point, and subsequent verification of incoming messages is done at the Incoming Point.
为了保证原始消息在事务处理过程中保持不变，在接入点对传出消息应用信封和签名，并在传入点对传入消息进行后续验证。
All communications within the PEC network MUST use secure channels. Integrity and confidentiality of connections between PEC provider and user MUST be guaranteed through the use of secure protocols, such as those based on [TLS] and those that create a secure transport channel on which non-secure protocols can transmit (e.g., IPsec).
PEC网络内的所有通信必须使用安全通道。必须通过使用安全协议来保证PEC提供商和用户之间连接的完整性和机密性，例如基于[TLS]的协议和创建非安全协议可以传输的安全传输通道的协议（例如IPsec）。
The interaction between providers MUST take place using SMTP on [TLS], as per [SMTP-TLS]. The Incoming Point MUST provide and announce its support for the STARTTLS extension, as well as accept both unencrypted connections (for ordinary mail) and protected ones. To guarantee complete traceability in the flow of PEC messages, these MUST NOT transit on systems external to the PEC network. When exchanging messages between different providers, all transactions MUST take place between machines that belong to the PEC network or are directly managed by the provider. An "MX" type record MAY be associated to each PEC domain defined within the system for name resolution, in which case secondary reception systems specified in that record MUST be under direct control of the provider. All in conformance with [SMTP].
提供程序之间的交互必须按照[SMTP-TLS]在[TLS]上使用SMTP进行。传入点必须提供并宣布其对STARTTLS扩展的支持，以及接受未加密的连接（对于普通邮件）和受保护的连接。为保证PEC消息流的完整可追溯性，这些消息不得在PEC网络外部的系统上传输。在不同提供商之间交换消息时，所有事务必须在属于PEC网络或由提供商直接管理的机器之间进行。“MX”类型的记录可能与系统内定义的每个PEC域相关联，用于名称解析，在这种情况下，该记录中指定的二级接收系统必须由提供商直接控制。均符合[SMTP]。
Another important security aspect that concerns the PEC system, is related to the technical and functional architecture that MUST block the presence of viruses from endangering the security of all handled messages. It is therefore REQUIRED to have installations and continuous updates of anti-virus systems that hinder infections as much as possible without intervening on the content of the certified mail, in compliance with what has been discussed thus far.
PEC系统的另一个重要安全方面与技术和功能架构有关，该架构必须阻止病毒的存在，以免危及所有已处理消息的安全。因此，要求按照迄今为止讨论的内容，安装和持续更新防病毒系统，以尽可能阻止感染，而不干预挂号信的内容。
In this document the S/MIME certificate profile is defined for use in the certification of PEC messages done by the providers. The proposed profile of the S/MIME certificate is based on the IETF standards [SMIMECERT] and [CRL], which in turn are based on the standard ISO/IEC 9594-8:2001.
在本文档中，定义了S/MIME证书配置文件，以便在提供者完成的PEC消息认证中使用。S/MIME证书的拟议配置文件基于IETF标准[SMIMECERT]和[CRL]，而IETF标准又基于标准ISO/IEC 9594-8:2001。
The information related to the PEC provider holder of the certificate MUST be inserted in the Subject field (Subject DN). More precisely, the Subject DN MUST contain the PEC provider's name as it is in the "providerName" attribute published in the PEC providers directory (section 4.5), but the Subject DN does not have to match the Provider entry DN in the LDIF. The providerName MUST be present in the CommonName or OrganizationName attributes of the "Subject:" field in the certificate.
必须在“主题”字段（主题DN）中插入与证书的PEC提供商持有人相关的信息。更准确地说，主题DN必须包含PEC提供程序的名称，因为它位于PEC提供程序目录（第4.5节）中发布的“providerName”属性中，但主题DN不必与LDIF中的提供程序条目DN匹配。providerName必须出现在证书中“Subject:”字段的CommonName或OrganizationName属性中。
Certificates MUST contain an Internet mail address, which MUST have a value in the subjectAltName extension, and SHOULD NOT be present in the Subject Distinguished Name.
证书必须包含Internet邮件地址，该地址必须在subjectAltName扩展名中具有值，并且不应出现在Subject可分辨名称中。
Valid subjectDN are:
有效主题DN为：
C=IT, O=AcmePEC S.p.A, CN=Posta Certificata
C=IT, O=AcmePEC S.p.A, CN=Posta Certificata
C=IT, O=ServiziPEC S.p.A, CN=Posta Certificata
C=IT, O=ServiziPEC S.p.A, CN=Posta Certificata
Valorization of other attributes in the Subject DN, if present, MUST be done in compliance with [CRL].
主题DN中其他属性的价值化（如果存在）必须按照[CRL]进行。
Extensions that MUST be present in the S/MIME certificate are:
S/MIME证书中必须存在的扩展包括：
o Key Usage
o 关键用法
o Authority Key Identifier
o 颁发机构密钥标识符
o Subject Key Identifier
o 主体密钥标识符
o Subject Alternative Name
o 主题替代名称
The Basic Constraints extension (Object ID:2.5.29.19) MUST NOT be present.
基本约束扩展（对象ID:2.5.29.19）不能存在。
The valorization of the above listed extensions for the described profile follows.
下面是所述配置文件的上述扩展的价值化。
The Key Usage extension (Object ID: 2.5.29.15) MUST have the digitalSignature bit (bit 0) activated and MUST be marked as critical. The extension MAY contain other active bits corresponding to different Key Usage, as long as that doesn't contrast with the indications in [CRL].
密钥使用扩展（对象ID:2.5.29.15）必须激活数字签名位（位0），并且必须标记为关键。扩展可以包含对应于不同密钥使用的其他活动位，只要与[CRL]中的指示不对比。
The Authority Key Identifier (Object ID: 2.5.29.35) MUST contain at least the keyIdentifier field and MUST NOT be marked as critical.
授权密钥标识符（对象ID:2.5.29.35）必须至少包含密钥标识符字段，并且不得标记为关键。
The Subject Key Identifier extension (Object ID: 2.5.29.14) MUST contain at least the keyIdentifier field and MUST NOT be marked as critical.
主题密钥标识符扩展（对象ID:2.5.29.14）必须至少包含密钥标识符字段，并且不得标记为关键。
The Subject Alternative Name (Object ID: 2.5.29.17) MUST contain at least the rfc822Name field and MUST NOT be marked as critical.
主题备选名称（对象ID:2.5.29.17）必须至少包含rfc822Name字段，且不得标记为关键。
Adding other extensions that have not been described in this document is to be considered OPTIONAL, as long as it remains compliant with [CRL]; such added extensions MUST NOT be marked as critical.
添加本文档中未描述的其他扩展被视为可选，只要它仍然符合[CRL]；此类添加的扩展不得标记为关键扩展。
Following is an example of an S/MIME certificate compliant with the minimal requisites described in this profile. Values used are of fictitious providers generated for example purposes only.
下面是一个S/MIME证书的示例，该证书符合此概要文件中描述的最低要求。所使用的值是仅为示例目的生成的虚拟提供程序的值。
An asterisk near the label of an extension means that such an extension has been marked as critical.
扩展标签附近的星号表示该扩展已标记为关键扩展。
VERSION: 3
SERIAL: 11226 (0x2bda)
INNER SIGNATURE:
ALG. ID: id-sha1-with-rsa-encryption
PARAMETER: 0
ISSUER:
Country Name: IT
Organization Name: Certifier 1
Organizational Unit Name: Certification Service Provider
Common Name: Certifier S.p.A.
VALIDITY:
Not Before: Oct 5, 04 09:04:23 GMT
Not After: Oct 5, 05 09:04:23 GMT
SUBJECT:
Country Name: IT
Organization Name: AcmePEC S.p.A.
Common Name: Certified Mail
PUBLIC KEY: (key size is 1024 bits)
ALGORITHM:
ALG. ID: id-rsa-encryption
PARAMETER: 0
MODULUS: 0x00afbeb4 5563198a aa9bac3f 1b29b5be
7f691945 89d01569 ca0d555b 5c33d7e9
VERSION: 3
SERIAL: 11226 (0x2bda)
INNER SIGNATURE:
ALG. ID: id-sha1-with-rsa-encryption
PARAMETER: 0
ISSUER:
Country Name: IT
Organization Name: Certifier 1
Organizational Unit Name: Certification Service Provider
Common Name: Certifier S.p.A.
VALIDITY:
Not Before: Oct 5, 04 09:04:23 GMT
Not After: Oct 5, 05 09:04:23 GMT
SUBJECT:
Country Name: IT
Organization Name: AcmePEC S.p.A.
Common Name: Certified Mail
PUBLIC KEY: (key size is 1024 bits)
ALGORITHM:
ALG. ID: id-rsa-encryption
PARAMETER: 0
MODULUS: 0x00afbeb4 5563198a aa9bac3f 1b29b5be
7f691945 89d01569 ca0d555b 5c33d7e9
... d15ff128 6792def5 b3f884e6 54b326db cf EXPONENT: 0x010001 EXTENSIONS: Subject Alt Name: RFC Name: posta-certificata@acmepec.it Key Usage*: Digital Signature Authority Key Identifier: 0x12345678 aaaaaaaa bbbbbbbb cccccccc dddddddd Subject Key Identifier: 0x3afae080 6453527a 3e5709d8 49a941a8 a3a70ae1 SIGNATURE: ALG. ID: id-sha1-with-rsa-encryption PARAMETER: 0 VALUE: 0x874b4d25 70a46180 c9770a85 fe7923ce b22d2955 2f3af207 142b2aba 643aaa61 ... d8fd10b4 c9e00ebc c089f7a3 549a1907 ff885220 ce796328 b0f8ecac 86ffb1cc
... d15ff128 6792def5 b3f884e6 54b326db cf指数：0x010001扩展名：主题替换名：RFC名称：posta-certificata@acmepec.it密钥用法*：数字签名机构密钥标识符：0x12345678 aaaaaaaa bbbbbbbb cccccc dddddd主题密钥标识符：0x3AFAEE080 6453527a 3e5709d8 49a941a8 a3a70ae1签名：ALG。ID:ID-sha1-with-rsa-encryption参数：0值：0x874b4d25 70a46180 c9770a85 fe7923ce b22d2955 2f3af207 142b2aba 643AA61。。。d8fd10b4 c9e00ebc c089f7a3 549a1907 ff885220 ce796328 b0f8ecac 86ffb1cc
0 30 794: SEQUENCE {
4 30 514: SEQUENCE {
8 A0 3: [0] {
10 02 1: INTEGER 2
: }
13 02 2: INTEGER 11226
17 30 13: SEQUENCE {
19 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
30 05 0: NULL
: }
32 30 101: SEQUENCE {
34 31 11: SET {
36 30 9: SEQUENCE {
38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
43 13 2: PrintableString 'IT'
: }
: }
47 31 28: SET {
49 30 26: SEQUENCE {
51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
56 13 19: PrintableString 'Certificatore 1'
: }
: }
77 31 22: SET {
0 30 794: SEQUENCE {
4 30 514: SEQUENCE {
8 A0 3: [0] {
10 02 1: INTEGER 2
: }
13 02 2: INTEGER 11226
17 30 13: SEQUENCE {
19 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
30 05 0: NULL
: }
32 30 101: SEQUENCE {
34 31 11: SET {
36 30 9: SEQUENCE {
38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
43 13 2: PrintableString 'IT'
: }
: }
47 31 28: SET {
49 30 26: SEQUENCE {
51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
56 13 19: PrintableString 'Certificatore 1'
: }
: }
77 31 22: SET {
79 30 20: SEQUENCE {
81 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
86 13 13: PrintableString 'Certification Service Provider'
: }
: }
101 31 32: SET {
103 30 30: SEQUENCE {
105 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
110 13 23: PrintableString 'Certificatore S.p.A.'
: }
: }
: }
135 30 30: SEQUENCE {
137 17 13: UTCTime '041005090423Z'
152 17 13: UTCTime '051005090423Z'
: }
167 30 66: SEQUENCE {
169 31 11: SET {
171 30 9: SEQUENCE {
173 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
178 13 2: PrintableString 'IT'
: }
: }
182 31 23: SET {
184 30 21: SEQUENCE {
186 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
191 13 14: PrintableString 'AcmePEC S.p.A.'
: }
: }
207 31 26: SET {
209 30 24: SEQUENCE {
211 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
216 13 17: PrintableString 'Posta Certificata'
: }
: }
: }
235 30 159: SEQUENCE {
238 30 13: SEQUENCE {
240 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549
1 1 1)
251 05 0: NULL
: }
253 03 141: BIT STRING 0 unused bits
: 30 81 89 02 81 81 00 AF BE B4 55 63 19 8A AA 9B
: AC 3F 1B 29 B5 BE 7F 69 19 45 89 D0 15 69 CA 0D
: 55 5B 5C 33 D7 E9 C8 6E FC 14 46 C3 C3 09 47 DD
: CD 10 74 1D 76 4E 71 14 E7 69 42 BE 1C 47 61 85
: 4D 74 76 DD 0B B5 78 4F 1E 84 DD B4 86 7F 96 DF
79 30 20: SEQUENCE {
81 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
86 13 13: PrintableString 'Certification Service Provider'
: }
: }
101 31 32: SET {
103 30 30: SEQUENCE {
105 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
110 13 23: PrintableString 'Certificatore S.p.A.'
: }
: }
: }
135 30 30: SEQUENCE {
137 17 13: UTCTime '041005090423Z'
152 17 13: UTCTime '051005090423Z'
: }
167 30 66: SEQUENCE {
169 31 11: SET {
171 30 9: SEQUENCE {
173 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
178 13 2: PrintableString 'IT'
: }
: }
182 31 23: SET {
184 30 21: SEQUENCE {
186 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
191 13 14: PrintableString 'AcmePEC S.p.A.'
: }
: }
207 31 26: SET {
209 30 24: SEQUENCE {
211 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
216 13 17: PrintableString 'Posta Certificata'
: }
: }
: }
235 30 159: SEQUENCE {
238 30 13: SEQUENCE {
240 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549
1 1 1)
251 05 0: NULL
: }
253 03 141: BIT STRING 0 unused bits
: 30 81 89 02 81 81 00 AF BE B4 55 63 19 8A AA 9B
: AC 3F 1B 29 B5 BE 7F 69 19 45 89 D0 15 69 CA 0D
: 55 5B 5C 33 D7 E9 C8 6E FC 14 46 C3 C3 09 47 DD
: CD 10 74 1D 76 4E 71 14 E7 69 42 BE 1C 47 61 85
: 4D 74 76 DD 0B B5 78 4F 1E 84 DD B4 86 7F 96 DF
: 5E 7B AF 0E CE EA 12 57 0B DF 9B 63 67 4D F9 37
: B7 48 35 27 C2 89 F3 C3 54 66 F7 DA 6C BE 4F 5D
: 85 55 07 A4 97 8C D1 5F F1 28 67 92 DE F5 B3 F8
: [ Another 12 bytes skipped ]
: }
397 A3 123: [3] {
399 30 121: SEQUENCE {
401 30 39: SEQUENCE {
403 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
408 04 32: OCTET STRING
: 30 1E 81 1C 70 6F 73 74 61 2D 63 65 72 74 69 66
: 69 63 61 74 61 40 61 63 6D 65 70 65 63 2E 69 74
: }
442 30 14: SEQUENCE {
444 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
449 01 1: BOOLEAN TRUE
452 04 4: OCTET STRING
: 03 02 07 80
: }
458 30 31: SEQUENCE {
460 06 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
465 04 24: OCTET STRING
: 30 16 11 11 11 11 AA AA AA AA AA BB BB BB BB CC CC
: CC CC DD DD DD DD
: }
491 30 29: SEQUENCE {
493 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
498 04 22: OCTET STRING
: 04 14 3A FA E0 80 64 53 52 7A 3E 57 09 D8 49 A9
: 41 A8 A3 A7 0A E1
: }
: }
: }
: }
522 30 13: SEQUENCE {
524 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
535 05 0: NULL
: }
537 03 257: BIT STRING 0 unused bits
: 87 4B 4D 25 70 A4 61 80 C9 77 0A 85 FE 79 23 CE
: B2 2D 29 55 2F 3A F2 07 14 2B 2A BA 64 3A AA 61
: 1F F0 E7 3F C4 E6 13 E2 09 3D F0 E1 83 A0 C0 F2
: C6 71 7F 3A 1C 80 7F 15 B3 D6 1E 22 79 B8 AC 91
: 51 83 F2 3A 84 86 B6 07 2B 22 E8 01 52 2D A4 50
: 9F C6 42 D4 7C 38 B1 DD 88 CD FC E8 C3 12 C3 62
: 64 0F 16 BF 70 15 BC 01 16 78 30 2A DA FA F3 70
: E2 D3 0F 00 B0 FD 92 11 6C 55 45 48 F5 64 ED 98
: 5E 7B AF 0E CE EA 12 57 0B DF 9B 63 67 4D F9 37
: B7 48 35 27 C2 89 F3 C3 54 66 F7 DA 6C BE 4F 5D
: 85 55 07 A4 97 8C D1 5F F1 28 67 92 DE F5 B3 F8
: [ Another 12 bytes skipped ]
: }
397 A3 123: [3] {
399 30 121: SEQUENCE {
401 30 39: SEQUENCE {
403 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
408 04 32: OCTET STRING
: 30 1E 81 1C 70 6F 73 74 61 2D 63 65 72 74 69 66
: 69 63 61 74 61 40 61 63 6D 65 70 65 63 2E 69 74
: }
442 30 14: SEQUENCE {
444 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
449 01 1: BOOLEAN TRUE
452 04 4: OCTET STRING
: 03 02 07 80
: }
458 30 31: SEQUENCE {
460 06 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
465 04 24: OCTET STRING
: 30 16 11 11 11 11 AA AA AA AA AA BB BB BB BB CC CC
: CC CC DD DD DD DD
: }
491 30 29: SEQUENCE {
493 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
498 04 22: OCTET STRING
: 04 14 3A FA E0 80 64 53 52 7A 3E 57 09 D8 49 A9
: 41 A8 A3 A7 0A E1
: }
: }
: }
: }
522 30 13: SEQUENCE {
524 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
535 05 0: NULL
: }
537 03 257: BIT STRING 0 unused bits
: 87 4B 4D 25 70 A4 61 80 C9 77 0A 85 FE 79 23 CE
: B2 2D 29 55 2F 3A F2 07 14 2B 2A BA 64 3A AA 61
: 1F F0 E7 3F C4 E6 13 E2 09 3D F0 E1 83 A0 C0 F2
: C6 71 7F 3A 1C 80 7F 15 B3 D6 1E 22 79 B8 AC 91
: 51 83 F2 3A 84 86 B6 07 2B 22 E8 01 52 2D A4 50
: 9F C6 42 D4 7C 38 B1 DD 88 CD FC E8 C3 12 C3 62
: 64 0F 16 BF 70 15 BC 01 16 78 30 2A DA FA F3 70
: E2 D3 0F 00 B0 FD 92 11 6C 55 45 48 F5 64 ED 98
: [ Another 128 bytes skipped ] : }
：[另跳过128个字节]：}
The contents of the PEC providers directory MUST be queried via [HTTP] on a Secure Socket Layer (SSL), as described in [TLS], exclusively by licensed providers that have the necessary user certificates; this access modality guarantees authenticity, integrity, and confidentiality of data. Each provider downloads the LDIF file through an [HTTPS] session, which is authenticated by checking the X.509 certificate issued by a certification authority.
PEC providers目录的内容必须通过[HTTP]在安全套接字层（SSL）上查询，如[TLS]中所述，由具有必要用户证书的许可提供商独家查询；这种访问方式保证了数据的真实性、完整性和机密性。每个提供者通过[HTTPS]会话下载LDIF文件，该会话通过检查证书颁发机构颁发的X.509证书进行身份验证。
This section lists the prerequisites that must be respected by a client in order to guarantee the minimal operative functionalities to the user of a general PEC system:
本节列出了客户必须遵守的先决条件，以保证通用PEC系统用户的最低操作功能：
o handling of Access and Delivery Points through secure channels;
o 通过安全通道处理接入点和交付点；
o handling of user authentication in message dispatch and reception which make use of standard protocols, such as [IMAP], [POP3], and [HTTP];
o 在使用标准协议（如[IMAP]、[POP3]和[HTTP]）的消息发送和接收中处理用户身份验证；
o support for MIME format according to [MIME1] and [MIME5];
o 根据[MIME1]和[MIME5]支持MIME格式；
o support for "ISO-8859-1 (Latin-1)" character set;
o 支持“ISO-8859-1（拉丁语-1）”字符集；
o support for S/MIME v3 standard, as in [SMIMEV3], for verification of signatures applied to PEC envelopes and notifications.
o 支持S/MIME v3标准，如[SMIMEV3]，用于验证应用于PEC信封和通知的签名。
All security considerations from [CMS] and [SMIMEV3] apply to applications that use procedures described in this document.
[CMS]和[SMIMEV3]中的所有安全注意事项适用于使用本文档中描述的过程的应用程序。
The centralized LDAP server is a critical point for the security of the whole PEC system. An attack could compromise the whole PEC system. PEC providers that periodically download the LDIF file SHOULD use the best security technology to protect it from local attacks. A PEC provider could be compromised if an attacker changed a certificate or modified the list of domains associated to it in the LDIF file that was copied to the PEC provider system.
集中式LDAP服务器是整个PEC系统安全的关键点。攻击可能危及整个PEC系统。定期下载LDIF文件的PEC提供商应使用最佳安全技术保护其免受本地攻击。如果攻击者在复制到PEC提供程序系统的LDIF文件中更改了证书或修改了与其关联的域列表，则PEC提供程序可能会受到威胁。
When verifying the validity of the signature of a message, the recipient system SHOULD verify that the certificate included in the [CMS] message is present in the LDIF file (section 4.5) and that the domain extracted by the [EMAIL] "From:" header is listed in the managedDomains attribute associated to said certificate.
在验证邮件签名的有效性时，收件人系统应验证[CMS]邮件中包含的证书是否存在于LDIF文件中（第4.5节），以及[EMAIL]“From:”标题提取的域是否列在与所述证书相关的managedDomains属性中。
This document defines new header fields used in the messages that transit in the PEC network. As specified and required by [HEADERS-IANA], this document registers new header fields as Provisional Message Header Fields as follows.
本文档定义了在PEC网络中传输的消息中使用的新标头字段。根据[HEADERS-IANA]的规定和要求，本文档将新的头字段注册为临时消息头字段，如下所示。
8.1.1. Header Field: X-Riferimento-Message-ID:
8.1.1. 标题字段：X-Riferimento-Message-ID:
Applicable protocol: mail [EMAIL]
适用协议：邮件[电子邮件]
Status: provisional
现状：临时
Author/Change controller:
作者/变更控制员：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137罗马意大利电子邮件：PETRUCCI@digitpa.gov.it
Specification document: this document, section 2.2.1, Appendix A.
规范文件：本文件，第2.2.1节，附录A。
8.1.2. Header Field: X-Ricevuta:
8.1.2. 标题字段：X-Ricevuta:
Applicable protocol: mail [EMAIL]
适用协议：邮件[电子邮件]
Status: provisional
现状：临时
Author/Change controller:
作者/变更控制员：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137罗马意大利电子邮件：PETRUCCI@digitpa.gov.it
Specification document: this document, sections 2.1.1.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.6, 3.2.1, 3.2.3, 3.2.4, 3.3.2, 3.3.3, Appendix A.
规范文件：本文件，第2.1.1.1.1、3.1.2、3.1.3、3.1.4、3.1.6、3.2.1、3.2.3、3.2.4、3.3.2、3.3.3节，附录A。
8.1.3. Header Field: X-VerificaSicurezza:
8.1.3. 标题字段：X-VerificationCasicurezza:
Applicable protocol: mail [EMAIL]
适用协议：邮件[电子邮件]
Status: provisional
现状：临时
Author/Change controller:
作者/变更控制员：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137罗马意大利电子邮件：PETRUCCI@digitpa.gov.it
Specification document: this document, sections 2.1.1.1.3, 3.1.3, 3.2.4, Appendix A.
规范文件：本文件，第2.1.1.1.3、3.1.3、3.2.4节，附录A。
8.1.4. Header Field: X-Trasporto:
8.1.4. 标题字段：X-Trasporto:
Applicable protocol: mail [EMAIL]
适用协议：邮件[电子邮件]
Status: provisional
现状：临时
Author/Change controller:
作者/变更控制员：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137罗马意大利电子邮件：PETRUCCI@digitpa.gov.it
Specification document: this document, sections 3.1.5, 3.2.2, Appendix A.
规范文件：本文件，第3.1.5节，第3.2.2节，附录A。
8.1.5. Header Field: X-TipoRicevuta:
8.1.5. 标题字段：X-TipoRicevuta:
Applicable protocol: mail [EMAIL]
适用协议：邮件[电子邮件]
Status: provisional
现状：临时
Author/Change controller:
作者/变更控制员：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137罗马意大利电子邮件：PETRUCCI@digitpa.gov.it
Specification document: this document, sections 3.1.5, 3.3.2, 3.3.2.1, 3.3.2.2, 3.3.2.3, Appendix A.
规范文件：本文件，第3.1.5、3.3.2、3.3.2.1、3.3.2.2、3.3.2.3节，附录A。
8.1.6. Header Field: X-Mittente:
8.1.6. 标题字段：X-Mittente:
Applicable protocol: mail [EMAIL]
适用协议：邮件[电子邮件]
Status: provisional
现状：临时
Author/Change controller:
作者/变更控制员：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137罗马意大利电子邮件：PETRUCCI@digitpa.gov.it
Specification document: this document, sections 3.2.3, Appendix A.
规范文件：本文件，第3.2.3节，附录A。
This document defines new LDAP attributes and object classes for object identifier descriptors. As specified and required by [LDAP-IANA], this document registers new descriptors as follows per the Expert Review.
本文档为对象标识符描述符定义了新的LDAP属性和对象类。根据[LDAP-IANA]的规定和要求，本文件根据专家评审登记了以下新描述符。
Subject: Request for LDAP Descriptor Registration
主题：请求LDAP描述符注册
Descriptor (short name): See comments
描述符（简称）：参见注释
Object Identifier: See comments
对象标识符：请参阅注释
Person & email address to contact for further information: See "Author/Change Controller"
联系人和电子邮件地址以了解更多信息：请参阅“作者/变更控制者”
Usage: See comments
用法：参见注释
Specification: (I-D)
规格：（I-D）
Author/Change Controller:
作者/变更控制员：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137罗马意大利电子邮件：PETRUCCI@digitpa.gov.it
Comments:
评论：
The following object identifiers and associated object classes/ attribute types are requested to be registered.
请求注册以下对象标识符和关联的对象类/属性类型。
OID Descriptor Usage
------------------------ --------------------- ------
1.3.6.1.4.1.16572.2.1.1 LDIFLocationURLObject O
1.3.6.1.4.1.16572.2.1.2 provider O
1.3.6.1.4.1.16572.2.2.1 providerCertificateHash A
1.3.6.1.4.1.16572.2.2.2 providerCertificate A
1.3.6.1.4.1.16572.2.2.3 providerName A
1.3.6.1.4.1.16572.2.2.4 mailReceipt A
1.3.6.1.4.1.16572.2.2.5 managedDomains A
1.3.6.1.4.1.16572.2.2.6 LDIFLocationURL A
1.3.6.1.4.1.16572.2.2.7 providerUnit A
OID Descriptor Usage
------------------------ --------------------- ------
1.3.6.1.4.1.16572.2.1.1 LDIFLocationURLObject O
1.3.6.1.4.1.16572.2.1.2 provider O
1.3.6.1.4.1.16572.2.2.1 providerCertificateHash A
1.3.6.1.4.1.16572.2.2.2 providerCertificate A
1.3.6.1.4.1.16572.2.2.3 providerName A
1.3.6.1.4.1.16572.2.2.4 mailReceipt A
1.3.6.1.4.1.16572.2.2.5 managedDomains A
1.3.6.1.4.1.16572.2.2.6 LDIFLocationURL A
1.3.6.1.4.1.16572.2.2.7 providerUnit A
Legend
-------------------
O => Object Class
A => Attribute Type
Legend
-------------------
O => Object Class
A => Attribute Type
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[CMS]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[CRL] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[CRL]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[EMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[电子邮件]Resnick，P.，Ed.“互联网信息格式”，RFC 5322，2008年10月。
[HEADERS-IANA] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[HEADERS-IANA]Klyne，G.，Nottingham，M.，和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[HTTPS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTPS]Rescorla，E.，“TLS上的HTTP”，RFC 28182000年5月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[LDAP] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[LDAP]Zeilenga，K.，编辑，“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[LDAP-IANA] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[LDAP-IANA]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 4520，2006年6月。
[LDAP-SYNTAXES] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[LDAP-SYNTAXES]Legg，S.，Ed.，“轻量级目录访问协议（LDAP）：语法和匹配规则”，RFC 45172006年6月。
[LDIF] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[LDIF]Good，G.，“LDAP数据交换格式（LDIF）-技术规范”，RFC 28492000年6月。
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME1]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[MIME5]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提交资料]Gellens，R.和J.Klensin，“邮件信息提交”，RFC 4409，2006年4月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ]Bradner，S.，“在RFC中用于指示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[SHA1]Eastlake 3rd，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 31742001年9月。
[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[MIME-SECURE]Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[SMIMEV3] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[SMIMEV3]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[SMIMECERT] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010.
[SMIMECERT]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2证书处理”，RFC 57502010年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[SMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[SMTP-DSN]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月。
[TIMESTAMP] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[时间戳]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，2002年7月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, November 2008, <http://www.w3.org/TR/2006/REC-xml-20060816/>.
[XML]W3C，“可扩展标记语言（XML）1.0（第五版）”，W3C建议，2008年11月<http://www.w3.org/TR/2006/REC-xml-20060816/>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option", RFC 4522, June 2006.
[RFC4522]Legg，S.，“轻量级目录访问协议（LDAP）：二进制编码选项”，RFC4522，2006年6月。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006.
[RFC4523]Zeilenga，K.，“X.509证书的轻型目录访问协议（LDAP）模式定义”，RFC4523，2006年6月。
The Italian document on which this document is based, is a product of the collaboration of many with the supervision of the National Center for Informatics in the Public Administration of Italy (DigitPA).
本文件所依据的意大利文件是许多人与意大利公共行政信息学国家中心（DigitPA）合作的产物。
NOTE: The right column represents a translation of the Italian fields for readability's sake only. Header fields that MUST be used are the ones in the left column.
注：右栏表示意大利语字段的翻译，仅出于可读性考虑。必须使用的标题字段是左列中的字段。
X-Riferimento-Message-ID Reference Message Identifier X-Ricevuta Notification non-accettazione non acceptance accettazione server-user acceptance preavviso-errore-consegna delivery error advance notice presa-in-carico server-server acceptance rilevazione-virus virus detection errore-consegna delivery error avvenuta-consegna message delivered X-Mittente Sender X-VerificaSicurezza Security Verification errore error X-Trasporto Transport posta-certificata certified mail errore error X-TipoRicevuta Notification Type completa complete breve brief sintetica concise
X-Riferimento-Message-ID参考消息标识符X-Ricevuta通知非ACCETTAZONE非验收ACCETTAZONE服务器用户验收前VVISO错误consegna传递错误carico服务器验收前通知presa病毒检测错误consegna传递错误avvenuta consegna消息传递X-Mittente发件人X-VerificationCasicurezza安全验证错误X-Trasporto Transport posta certificata认证邮件错误X-TipoRicevuta通知类型complete完整breve简要信息简洁
certificatore certificator
认证者认证者
Subject values:
主题价值：
Accettazione SERVER-USER ACCEPTANCE Posta certificata CERTIFIED MAIL Presa in carico SERVER-SERVER ACCEPTANCE Consegna DELIVERY Anomalia messaggio MESSAGE ANOMALY Problema di sicurezza SECURITY PROBLEM Avviso di non accettazione NON ACCEPTANCE PEC NOTIFICATION Avviso di non accettazione VIRUS DETECTION INDUCED NON per virus ACCEPTANCE PEC NOTIFICATION Avviso di mancata consegna NON DELIVERY PEC NOTIFICATION Avviso di mancata consegna NON DELIVERY DUE TO VIRUS PEC per virus NOTIFICATION Avviso di mancata consegna NON DELIVERY DUE TO TIMEOUT PEC per sup. tempo massimo NOTIFICATION
Accettazione服务器-用户接受邮政证书认证邮件在carico服务器-服务器接受服务中发送异常消息消息异常问题sicurezza安全问题Avviso di non-Accettazione未接受PEC通知Avviso di non-Accettazione病毒检测导致非每病毒接受PEC通知Avviso di mancata consegna未交付PEC通知Avviso di mancata consegna因病毒PEC未交付每病毒通知Avviso di mancata consegna因超时PEC每sup未交付。节奏马西莫通知
Italian terms in the DTD relative to the certification XML file:
DTD中与认证XML文件相关的意大利语术语：
accettazione server-user acceptance altro other avvenuta-consegna delivered certificato certificate consegna delivery data date dati data destinatari recipients esterno external errore error errore-consegna delivery error errore-esteso extensive error gestore-emittente transmitting provider giorno day identificativo identifier intestazione header mittente sender no-dest(inatario) no recipient no-dominio no domain non-accettazione non acceptance nessuno none oggetto subject ora hour posta-certificata certified mail preavviso-errore-consegna delivery error advance notice presa-in-carico server-server acceptance ricevuta notification ricezione receipt (the act of receiving) rilevazione-virus virus detection risposte replies tipo type
ACCETTAZONE服务器用户验收altro其他avvenuta consegna交付证书证书consegna交付数据日期dati数据目的地收件人ESTER无外部错误错误错误consegna交付错误ESTER如此广泛的错误gestore发射发送提供商giorno day标识INTESTAZONE头收件人地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址地址rilevazione病毒检测risposte-tipo型
Authors' Addresses
作者地址
Claudio Petrucci DigitPA Viale Marx 31/49 00137 Roma Italy
克劳迪奥·彼得鲁奇·迪吉塔·维亚勒·马克思31/49 00137意大利罗马
EMail: petrucci@digitpa.gov.it
EMail: petrucci@digitpa.gov.it
Francesco Gennai ISTI-CNR Via Moruzzi, 1 56126 Pisa Italy
弗朗西斯科·根奈意大利比萨156126号摩鲁齐国际旅行社
EMail: francesco.gennai@isti.cnr.it
EMail: francesco.gennai@isti.cnr.it
Alba Shahin ISTI-CNR Via Moruzzi, 1 56126 Pisa Italy
阿尔巴·沙欣·伊斯蒂-CNR途经摩鲁齐，156126意大利比萨
EMail: alba.shahin@isti.cnr.it
EMail: alba.shahin@isti.cnr.it
Alessandro Vinciarelli Via delle Vigne di Morena 113 00118 Roma Italy
亚历山德罗·文森亚雷利途经莫雷纳大道113 00118罗马-意大利
EMail: alessandro.vinciarelli@gmail.com
EMail: alessandro.vinciarelli@gmail.com