[要約] RFC 6109は、イタリアの認定電子メール（PEC）に関する規格であり、その目的は、イタリアでの電子メールの認証とセキュリティを確保することです。
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 Certificata-イタリアの認定電子メール
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年には、2年間の技術的テストの後、公式電子配信サービスの特徴であるCertified Electronic Mail（イタリア語の「Posta Elettronica Certiveata」）が定義され、システムに法的な地位が与えられました。
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）、特にCNRの情報科学技術研究所（ISTI）に、サービスのプロバイダーでテストを実行して正しい実装と相互運用性を保証するタスクを与えました。このドキュメントでは、イタリアで採用された認定電子メールシステムについて説明しています。イタリアの法律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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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年、2年間の技術的テストの後、公式の電子配信サービスの特性は、認定電子メール（イタリアのエレトロニカ証明書で、今後は「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_tecniche_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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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：暗号化メッセージ構文CNIPA：イタリア国立デジタル管理局（L'informatica nella pubblica amministrazione）CNR：イタリア国立研究評議会（Consiglio Nazionale Delle ricerche）CRL：CRL DP：証明書の取り消しリストDNS：ドメイン名サービスDTD：ドキュメントタイプ定義FQDN：完全資格のドメイン名ISTI：CNRの情報科学技術研究所（ISTITUTO DI SCIENZA E TECNOLOGIE DELL'INFORAZIONE "A.FAEDO"）LDAP：LightWeight Directory Access Protocol LDIF：LDAPデータインターチェンジフォーマットMIME：多目的インターネットメールエクステンションPEC：認定電子メール（Posta Elettronica Certificata）S/MIME：Secure/MIME SMTP：Simple Mail Transfer Protocol TLS：Transport Layer Security 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プロバイダーによって認定された一連のデータ。これには、ディスパッチの日付と時刻、送信者のメールアドレス、受信者のメールアドレス（ES）、件名、およびメッセージ識別子が含まれます。
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.
送信されたメッセージ：送信者の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.
受信したメッセージ：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：MSGIDを代用するPECシステムによって生成される一意の識別子です。
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プロバイダー：アクセス、受信、配信の相対的なポイントで1つ以上の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プロバイダーのキー：すべてのPECプロバイダーにDigitPaによってリリースされたキーです。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プロバイダーディレクトリ：すべてのPECサービスプロバイダーが到達可能なエリアに配置されたLDAPサーバーです。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.
タイムスタンプ：拒否できない一時的な参照が1つ以上の文書に起因するデジタル証拠。
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システムは、記述的なテキストパーツおよびその他の[MIME1]パーツで構成されるMIME形式でメッセージを生成します。その数とコンテンツは、生成されたメッセージの種類によって異なります。
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証明書は、前述の構造に含める必要があります。[SMIMEV3]のセクション3.4.3で説明されているように、システムで生成されたメッセージに署名するために使用されるS/MIME形式は、「マルチパート/署名された」形式（.p7s）です。
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：」で、元のメッセージに含まれるものとは異なる単一の著者のアドレスをフィールドに示しなければなりません。受信ユーザーによるメッセージの使いやすさを可能にするために、元のメッセージの著者のメールアドレスが「ディスプレイ名」として挿入されます。たとえば、「from：」のフィールド：
From: "John Smith" <john.smith@domain.example.com>
would result in the following "From:" value in the respective PEC transport envelope:
次の「from」になります。それぞれのPEC輸送エンベロープの値：
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.
「from：」と「sender：」の両方のフィールドには、同じ値が含まれている必要があります。返信を適切な目的地に正しく送り返すためには、「返信」：PECトランスポートエンベロープのフィールドは、元のメッセージの「Reply-to」フィールドと同じ変更値を含める必要があります。元のメッセージで明示的に指定されていない場合、PEC Transport Envelopeを生成するシステムは、元のメッセージの「From：」フィールドから情報を抽出することで作成します。
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通知は、元のメッセージのヘッダーに存在する可能性のある「Reply-To」フィールドを考慮せずに、送信者の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ダイアログフェーズでは、逆パスとフォワードパスデータ（ "Mail from"および "Commands）は、それぞれ送信者と受信者の両方の認証データと見なされます。メッセージ本文に存在するデータのアドレス指定（ "to"および "cc："フィールド）は、必要に応じてプライマリコピーレシピエントとカーボンコピーの受信者を区別するためにのみ使用されます。「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メッセージの受信または処理のためのプロバイダー側の承認を示しています。より具体的には、サーバーユーザーの受け入れ、サーバーサーバーの受け入れ、または配信の3つの状況のいずれかを示すことができます。
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.
サーバーサーバーの受け入れまたは配信PEC通知（24時間遅延に相当）の兆候なしにさらに12時間が過ぎた場合、別の遅延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-verificasicurezza：[オプション]
"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.1（成功通知）に示されているのと同じ役割があります。「X-verificasicurezza：」（セキュリティ検証）は、ウイルス関連の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 Return-Path:
o CC：o return-path：
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
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プロバイダーディレクトリで利用可能なデータを使用して（セクション4.5を参照）、アクセスポイントは、元のメッセージに存在する「to」および「cc：」フィールドのすべての受信者のチェックを実行して、それらがPECインフラストラクチャに属しているかどうかを確認します。非PECドメインへ。このようなチェックは、PECプロバイダーディレクトリ内で見つかった「マネージドドメイン」属性の受信者のドメインの存在を確認することにより、存在を確認することによって行われます。したがって、サーバーユーザーの受け入れ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]>
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通知に送信されたメッセージをリンクできるようにするには、MSGIDを元のメッセージと相対PEC通知およびトランスポートエンベロープに挿入する必要があります。存在する場合、次のヘッダーフィールドを追加することにより、元のメッセージのヘッダーに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 Transport Envelopeおよび通知に挿入され、認証データに関連します（セクション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時間に等しいメッセージIDLNENESの時間制限を採用する必要があります。
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 Anomaly Envelopeは、配信ポイントに転送されます。
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プロバイダーに属しているかどうかを確認します。PECプロバイダーディレクトリでの署名とその存在の検証に使用される証明書を抽出することにより。チェックを容易にするために、証明書の[SHA1]ハッシュ値を計算し、PECプロバイダーディレクトリにある「ProviderCertificateHash」属性内の16進表現のケース非感受性検索を実行することができます。この操作により、抽出された証明書とプロバイダーの記録に存在する証明書との間の後続の必要な一致するチェックのために、送信者プロバイダーを簡単に識別できます。
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 署名の妥当性-S/MIME署名の正確性は、署名値を再計算し、認証パス全体をチェックし、[CRL]と証明書の時間的妥当性を検証することにより検証されます。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 Transport Envelopeおよび通知）に準拠していることを保証するために十分で必要なチェックを実行します。
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輸送エンベロープの内容が検証される第2フェーズで検出されます。したがって、受信ポイントはメッセージの転送を受信者に転送することを控え、代わりに配信の適切な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システムに入る前に着信ポイントで破棄できます。言い換えれば、エラーのための特別な治療は予約されていません。これは、インターネットを通過するメッセージに対して通常続く手順に準拠した方法で処理されます。
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.
配信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 recipient(s) of original message
o 元のメッセージの送信者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 [電子メール]ヘッダーセクションには、[from： "ヘッダーフィールドが含まれています。
o [EMAIL] header section contains a "To:" header field holding one or more [EMAIL] compliant email addresses;
o [電子メール]ヘッダーセクションには、1つ以上の[電子メール]準拠の電子メールアドレスを保持しているヘッダーフィールドが含まれています。
o sender's address, specified in the SMTP reverse path, coincides with the one in the message's "From:" header field;
o SMTPリバースパスで指定された送信者のアドレスは、メッセージの「From：」ヘッダーフィールドのものと一致します。
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フォワードパスで指定された受信者 'アドレスは、メッセージの「to」または「cc：」ヘッダーフィールドに存在するものと一致します。
o "Bcc:" header field does not contain any value;
o 「BCC：」ヘッダーフィールドには価値が含まれていません。
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]
The notification body will contain a text part that constitutes the actual notification in readable format according to a model that relates the following information:
通知本体には、次の情報を関連付けるモデルに従って、読み取り可能な形式で実際の通知を構成するテキストパーツが含まれます。
Error in message acceptance
On [date] at [time] ([time zone]), in the message "[subject]"
originating from "[original sender]" and addressed to:
[recipient_1]
[recipient_2]
[recipient_n]
a problem was detected that prevents its acceptance due to
[error description].
The message was not accepted.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]
The same certification information is inserted in an XML file to be added to the notification body, thus allowing automatic checks on the message (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the provider for provider-specific services. Regardless, the original message MUST NOT be included. The message MUST follow the format described in section 4.3.
同じ認定情報が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]
The body contains a readable text part according to the following model:
本体には、次のモデルに従って読みやすいテキスト部分が含まれています。
Error in message acceptance due to virus presence
On [date] at [time] ([time zone]), in the message "[subject]"
originating from "[original sender]" and addressed to:
[recipient_1]
[recipient_2]
[recipient_n]
a security problem was detected [ID of detected content type].
The message was not accepted.
Message identifier: [PEC msgid of corresponding
PEC transport envelope]
The same certification data is inserted in an XML file added to the notification to allow for automatic checks (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the provider for provider-specific services. Regardless, the original message MUST NOT be included. The message MUST follow the format described in section 4.3.
自動チェックを可能にするために、通知に追加された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]
The message body contains a text part that constitutes the notification in readable format, according to a model that relates the following information:
メッセージ本文には、次の情報を関連付けるモデルに従って、読み取り可能な形式で通知を構成するテキストパーツが含まれています。
Server-User Acceptance PEC notification
On [date] at [time] ([time zone]), the message "[subject]"
originating from "[original sender]" and addressed to:
[recipient_1] (["certified mail" | "ordinary mail"])
[recipient_2] (["certified mail" | "ordinary mail"])
[recipient_n] (["certified mail" | "ordinary mail"])
was accepted by the system and forwarded to the recipient(s).
Message identifier: [PEC msgid of corresponding
PEC transport envelope]
The same certification data is inserted in an XML file added to the notification message, allowing automatic checks on it (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the provider for provider-specific services. The message MUST follow the format described in section 4.3.
同じ認定データが通知メッセージに追加された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 Transport Envelopeは、元のメッセージと認証データを含むアクセスポイントによって生成されるメッセージです。
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 CC：
o Return-Path:
o 復路：
o Reply-To: (if present) On the other hand, the following fields MUST be modified, or inserted if necessary:
o 返信：（存在する場合）一方、次のフィールドを変更するか、必要に応じて挿入する必要があります。
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 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部品には、認定データを含む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]
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]
[Time]（[Time Zone]）での[日付]に関する非配信PEC通知、「[Subject]」は「[Original Sender]」に由来し、「[受信者]」に宛てられたメッセージは、最初には配信されていません。派遣後12時間。メッセージが最終的に配信される可能性があることを除外していないため、ディスパッチには肯定的な結果が得られない可能性があると考えると有用であると考えられています。システムは、次の12時間以内に受信者から確認が受け取られていない場合、別の非配信PEC通知を送信することを確認します。メッセージ識別子：[対応するPEC Transport Envelopeの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.
[Time]（[Time Zone]）での[日付]の[日付]に関する非配信PEC通知、「[件名]」は「[Original Sender]」に由来し、「[受信者]」に宛てられたメッセージは24時間以内に配信されていません。その派遣の。
The transaction is deemed to be considered terminated with a negative outcome. Message identifier: [PEC msgid of corresponding PEC transport envelope]
トランザクションは、負の結果で終了したと見なされるとみなされます。メッセージ識別子：[対応するPEC Transport Envelopeの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通知のいずれも受け取りません。この場合、2つのタイムアウト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 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トランスポートエンベロープ（セクション2.2.2で定義されている）がPECプロバイダー間で交換される場合、受信者はServer-Server Acceptance PEC通知を送信者に送信する必要があります。SMTPトランザクションのルーティングデータ（フォワードパスおよびリバースパス）に記載されているように、単一の派遣通知は、同じプロバイダーに属し、受信メッセージに対処されたすべての受信者に関するものです。単一のサーバーサーバー受け入れPEC通知の認証データ内で、それが参照するメッセージのすべての受信者がリストされています。一般に、PECトランスポートエンベロープを受信する場合、各プロバイダーは、SMTP輸送エラーがない場合、その管轄区域のすべての受信者をカバーするために、1つまたは複数のサーバーサーバーの受け入れ通知を放出する必要があります。
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]
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]
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 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:
着信メッセージのテストがエラーを検出するか、メッセージが通常のメールであると識別され、プロバイダーが受信者に転送されるように設定されている場合、システムはそのようなメッセージをPEC Anomaly Envelopeに挿入する必要があります。配信の前に、着信ポイントで受信したメッセージ全体が、[MIME1]部分として[メール]に準拠した形式で挿入されます。新しいメッセージ内の[MIME1]部分は、受信したメッセージから次のヘッダーフィールドの未修正値を継承する必要があります。
o Received:
o 受け取った：
o To:
o に：
o Cc:
o CC：
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)]
The body contains a user-readable text part according to a model that relates the following data:
本文には、次のデータを関連付けるモデルに従って、ユーザーが読むことができるテキストパーツが含まれています。
Message anomaly
On [date] at [time] ([time zone]), the message "[subject]"
originating from "[original sender]" and addressed to:
[recipient_1]
[recipient_2]
[recipient_n]
was received.
The data has not been certified due to the following error:
[concise description of error]
The original message is attached.
Due to uncertainty regarding origin and/or conformity of the message received, the PEC anomaly envelope MUST NOT contain [MIME1] parts other than the entire message that arrived at the Incoming Point.
受信したメッセージの起源および/または適合性に関する不確実性のため、PEC Anomaly Envelopeには、受信ポイントに到達したメッセージ全体以外の[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]
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]
[Time]（[Time Zone]）での[日付]の[日付]に関するウイルス検出PEC通知、「[Subject]」[[Original Sender]]に由来し、「[受信者]」に宛てられたセキュリティ問題が検出されました。検出されたコンテンツタイプの]。メッセージ識別子：[対応するPEC Transport Envelopeの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]
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]
[Time]（[Time Zone]）での[日付]のウイルスによるPEC通知「[Time Zone]）、「[subject]」に「[recionient]」にアドレス指定されたセキュリティ問題が検出されました[コンテンツタイプのIDが検出されましたウイルス対策]。メッセージは配信されませんでした。メッセージ識別子：[対応するPEC Transport Envelopeの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通知は、正しいPEC輸送エンベロープ（セクション2.2.2および3.1.5）が受信者のメールボックスに配信された後にのみ発行されます。
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 Anomaly Enveloperes、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]
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.
「X-TiporiceVuta：」の値は、PEC Transport Envelopeのヘッダーフィールドが元のメッセージから派生しているため、送信者は元のメッセージの主要な受信者から要求された配信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 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通知のデフォルト値です。「X-TiporiceVuta：」の値が指定されていない場合、または値「Completa」（完全）が含まれている場合、システムは「to：」の宛先からの完全な配信PEC通知が必要です。（セクション3.3.2.3）は、「CC：」フィールドのものから必要です。主要なレシピエントとカーボンコピーのレシピエントとの区別は、「to」と「cc：」フィールドの分析を通じて行われます。プライマリ受信者に代わって送信されたPEC通知の場合、添付ファイルとともに元のメッセージの完全なコピーが通知に挿入されます。配達を担当するシステムが、「to」と「cc：」フィールドのあいまいさの問題のために受信者の種類を決定できない場合、配達は一次受信者に宛てられた場合、配達を考慮し、の完全なコピーを含める必要があります。元のメッセージ。
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]
[TIME]（[タイムゾーン]）での[日付]の配信PEC通知、「[件名]」から「[元の送信者]」に由来し、「[受信者]」に宛てられたメッセージは、宛先のメールボックスに配置されました。メッセージ識別子：[対応するPEC Transport Envelopeの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 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.
注：PECはこれらのリラックスした仕様を使用していますが、20を超えるサービスプロバイダー間のPEC相互運用性テストは、問題を明らかにしたことはありません。これは、おそらく、変更を適用せずに受け取るメッセージをそのまま残すために、メールサーバーがさらに傾いているためです。ただし、サーバーがエンコードされたパーツを変更することを決定した場合、問題が発生する可能性があります。たとえば、レシーバーの端で計算されたハッシュ値が送信者側のハッシュ値とは異なります。
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通知と、カーボンコピーの受信者に代わって簡潔なもの（セクション3.3.2.3）を放出します。PEC Transport Envelopeのヘッダーフィールドの値は、元のメッセージから派生しています。
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]
[Time]（[Time Zone]）での[日付]に関する簡単な配信PEC通知、「[件名]」は「[Original Sender]」に由来し、「[受信者]」に宛てられたメッセージが宛先のメールボックスに配置されました。メッセージ識別子：[対応するPEC Transport Envelopeの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構造は、通知に追加されると変更されていませんが、ヘッダーフィールドに「名前」パラメーターを備えた各mimeパーツは、 "content-type："または "filename" parameter in the headerフィールドのコンテンツ - 処分：「その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]): o multipart/signed
元のメッセージにS/MIME形式がある場合、メッセージ構造の整合性を変更しないでください。元のメッセージのS/MIMEパーツの検証は、トップレベルエンティティのMIMEタイプ（メッセージ自体と一致する）がチェックされたときに行われます。s/mimeメッセージには、次のmimeタイプがある場合があります（[smimev3]に従って）：o multipart/signed
Represents an original message signed by the sender using the structure described in [MIME-SECURE]. The message is made up of two MIME parts: the first is the message itself before the application of the sender's signature, whereas the second contains signature data. The second part (generally of type "application/pkcs7-signature" or "application/x-pkcs-signature") contains data added during the signing phase and MUST be left unchanged to avoid compromising the overall message structure;
[mime-secure]で説明されている構造を使用して、送信者が署名した元のメッセージを表します。メッセージは2つのMIMEパーツで構成されています。1つ目は、送信者の署名を適用する前のメッセージ自体ですが、2つ目には署名データが含まれています。2番目の部分（一般に「アプリケーション/PKCS7-署名」または「アプリケーション/X-PKCS-Signature」の2番目の部分には、署名フェーズ中に追加されたデータが含まれており、メッセージ全体の侵害を避けるために変更されておく必要があります。
o "application/pkcs7-mime" or "application/x-pkcs7-mime"
o 「アプリケーション/PKCS7-MIME」または「Application/X-PKCS7-MIME」
The message is composed of a sole CMS object within the MIME part. Given that attachments cannot be separated from the CMS object, the MIME part is left intact (i.e., it is not replaced by the hash value); therefore, the brief PEC notification is the same as the complete PEC notification.
メッセージは、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.
元のメッセージに「コンテンツタイプ：」が「メッセージ/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. MultiPart/Signed 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 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.
o 元のメッセージに「アプリケーション/PKCS7-MIME」または「Application/X-PKCS7-MIME」MIMEタイプが含まれている場合、メッセージに存在する添付ファイルは、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文字の単一シーケンスとして16進表現を使用してファイルに記述されます。これらの添付ファイルのmimeタイプは、テキストの性質を強調するために「テキスト/プレーン」に設定されています。
If the PEC transport envelope contains the header:
PECトランスポートエンベロープにヘッダーが含まれている場合：
X-TipoRicevuta: sintetica
X-TiporiceVuta：Sintetica
the Delivery Point emits, both to primary and carbon copy recipients, a concise delivery PEC notification that does not contain the original message.
デリバリーポイントは、プライマリコピーレシピエントとカーボンコピーの両方の受信者の両方に、元のメッセージが含まれていない簡潔な配信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]
[Time]（[Time Zone]）での[日付]に関する簡潔な配信通知、「[件名]」は「[Original Sender]」に由来し、「[受信者]」に宛てられたメッセージが宛先のメールボックスに配置されました。メッセージ識別子：[対応するPEC Transport Envelopeの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]
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]
[Time]（[Time Zone]）での[日付]の[日付]の[[件名] "[[元の送信者]]からのメッセージの非配信PEC通知と「[受信者]」に宛てられたエラーが検出された[briefエラーの説明]。メッセージはシステムによって拒否されました。メッセージ識別子：[対応するPEC Transport Envelopeの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:
2つの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
time-offset = "(" ("+" / "-") time-hour ":" time-minute ")"
partial-time = time-hour ":" time-minute ":" time-second
full-date = date-mday "/" date-month "/" date-fullyear full-time = partial-time time-offset
フルデート=日付-Day "/" Date-Month "/" Date-Full Year fulltime = Partial-Time Time-Offset
NOTE: For number of days in a month, leap year, and leap second restrictions see section 5.7 of [TIMESTAMP].
注：1か月の日数、跳躍年、および跳躍2番目の制限は、[タイムスタンプ]のセクション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システムによって生成された通知について説明します。メッセージパーツの1つに、範囲0-127（7ビットASCII）の外側の値を持つ文字が含まれている場合、その部分は7ビット輸送の互換性が保証されるように適切にエンコードする必要があります（例えば、引用符で囲まれた、base64[mime1]あたり）。
Before applying the signature, the message body has Content-Type: multipart/mixed. Each part is described in the sections below. The first part is the user readable text generated by the PEC system, while the second and third parts are interchangeable in order and contain the original message and the XML file for the certification data.
署名を適用する前に、メッセージ本文にはコンテンツタイプ：MultiPart/Mixedがあります。各部分については、以下のセクションで説明します。最初の部分は、PECシステムによって生成されたユーザー読み取り可能なテキストですが、2番目と3番目の部分は順番に交換可能であり、認定データの元のメッセージとXMLファイルが含まれています。
Character set: ISO-8859-1 (Latin-1) MIME type: text/plain or multipart/alternative
文字セット：ISO-8859-1（ラテン-1）MIMEタイプ：テキスト/プレーンまたはマルチパート/代替
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:
マルチパート/代替MIMEタイプを使用して、システム生成メッセージの本文のHTMLバージョンを追加できます。この場合、2つのサブパートが存在する必要があります。1つはタイプテキスト/プレーン、もう1つのテキスト/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タイプ：メッセージ/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.
以下は、PEC通知に添付された認証データを含む[XML]ファイルに対するDTDです。
<!--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 | presa-in-carico | avvenuta-consegna | posta-certificata | errore-consegna | preavviso-errore-consegna | rilevazione-virus）ウイルス| altro） "nessuno">
<!--Header of the original message-->
<!ELEMENT intestazione (mittente,
destinatari+,
risposte,
oggetto?)>
<!--Sender ("From:" field) of the original message-->
<!ELEMENT mittente (#PCDATA)>
<!--Complete list of recipients ("To:" and "Cc:" fields)-->
<!--of the original message-->
<!--"tipo" indicates the typology of the recipient-->
<!ELEMENT destinatari (#PCDATA)>
<!ATTLIST destinatari
tipo (certificato | esterno) "certificato">
<!--Value of the "Reply-To:" field of the original message-->
<!ELEMENT risposte (#PCDATA)>
<!--Value of the "Subject:" field of the original message-->
<!ELEMENT oggetto (#PCDATA)>
<!--PEC message data--> <!ELEMENT dati (gestore-emittente, data, identificativo, msgid?, ricevuta?, consegna?, ricezione*, errore-esteso?)>
<！ - PECメッセージデータ - > <！要素dati（Gestore-Emittente、data、Identificativo、msgid？、ricevuta？、consegna？、riezione*、errore-esteso？）>
<!--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>
<!--Day in "dd/mm/yyyy" format-->
<!ELEMENT giorno (#PCDATA)>
<!--Local hour in "hh:mm:ss" format-->
<!ELEMENT ora (#PCDATA)>
<!--PEC msgid-->
<!ELEMENT identificativo (#PCDATA)>
<!--msgid of the original message before modifications-->
<!ELEMENT msgid (#PCDATA)>
<!--For PEC transport envelopes and delivery notifications-->
<!--indicate the type of PEC notification requested by the-->
<!--sender-->
<!ELEMENT ricevuta EMPTY>
<!ATTLIST ricevuta
tipo (completa |
breve |
sintetica ) #REQUIRED>
<!--For delivery, non-delivery, virus-induced non-delivery, -->
<!-- virus detection, and timeout PEC notifications-->
<!--Recipient address to which delivery has been carried -->
<!--out/tried-->
<!ELEMENT consegna (#PCDATA)>
<!--For server-server acceptance PEC notifications-->
<!--recipients for whom it is the relative PEC notification-->
<!ELEMENT ricezione (#PCDATA)>
<!--In case of error-->
<!--brief description of the error-->
<!ELEMENT errore-esteso (#PCDATA)>
The PEC providers directory is created through a centralized LDAP server that contains the providers' data and their corresponding PEC mail domains.
PECプロバイダーディレクトリは、プロバイダーのデータとそれに対応するPECメールドメインを含む集中LDAPサーバーを介して作成されます。
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
- MailReceipt：プロバイダーレセプションメールアドレス
- managedDomains: managed domains
- マネージドドメイン：マネージドドメイン
- 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 = PostAcert」であり、単一レコードの「DistingUishedName」は "<providername = <name>、o = postacert>"です。ディレクトリ内の検索は、主に「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]ファイルに包まれています。[ldif]ファイルは[https]オブジェクトとして利用可能であり、「dn：o = postacert」の「ldiflocationurl」属性が記録されているURLにあります（セクション4.5.6を参照）。信頼性を保証するには、そのファイルは、単一のプロバイダーに記載されている方法を使用して、そのPECサービスに関する運用のプロバイダーによって署名されなければなりません。ファイル、署名、およびX.509V3証明書は、「.P7M」拡張機能を備えたファイルとして、バイナリASN.1 Der形式のPKCS＃7構造に挿入する必要があります。集中化された[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]ファイルを介して、単一のプロバイダーは、メッセージElaborationフェーズごとに中央システムへの継続的な要求ディスパッチを回避することにより、システムのパフォーマンスを改善するために、毎日更新されるディレクトリのコピーをローカルに保持する必要があります。
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形式のハッシュの16進表現です。
( 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名 'ProviderCertificateHash' Desc 'Hash Sha1 of X.509証明書のHash Sha1' equality Caseignoreia5Match Syntax 1.3.6.1.4.4.1.1466.115.121.1.1.1.1.
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-Syntaxes]で定義されています。
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 'X.509証明書ASN.1 Der Binary Format'構文1.3.6.1.4.1.146.115.121.1.1.1.8）
The Certificate syntax ( 1.3.6.1.4.1.1466.115.121.1.8 ) is defined in [RFC4523].
証明書構文（1.3.6.1.4.1.1466.115.121.1.8）は[RFC4523]で定義されています。
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名 'プロバイダー名' desc 'pecプロバイダー名' equality caseignorematch substringsubstringsmatch構文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.1.146.115.121.1.15）構文は[LDAP-Syntaxes]で定義されています。
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.
「MailReceipt」属性には、サーバーサーバーの受け入れとウイルス検出PEC通知が送信されるプロバイダー内のプロバイダーのメールアドレスが含まれています。このアドレスは、[email]（角度ブラケットなし）で説明されている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」desc 'サービスメールボックスの電子メールアドレス' equality caseignoreia5match subst caseignoreia5substringsmatch Syntax 1.3.6.1.4.1.1466.115.121.1.26単一値）sing-value）
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-Syntaxes]で定義されています。
The 'managedDomains' attribute holds a set of domains [SMTP] that are handled by a PEC provider. Domains are limited to dot-atom form ([RFC1034], [EMAIL]).
「ManagedDomains」属性には、PECプロバイダーによって処理されるドメイン[SMTP]のセットが保持されます。ドメインは、ドットアトム形式（[RFC1034]、[メール]）に限定されています。
( 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 'DESC'ドメインは、PECプロバイダー「Caseignoreiaia5Match Substringiignoreia5Substringsmatch Syntax」によって処理されました。
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-Syntaxes]で定義されています。
The 'managedDomains' attribute holds a set of domains [SMTP] that are handled by a PEC provider. Domains are limited to dot-atom form ([RFC1034], [EMAIL]).
「ManagedDomains」属性には、PECプロバイダーによって処理されるドメイン[SMTP]のセットが保持されます。ドメインは、ドットアトム形式（[RFC1034]、[メール]）に限定されています。
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」属性には、プロバイダーのレコードを定義する[LDIF]ファイルの位置を指す[https] URLが含まれています。属性がレコード「DN：O = PostAcert」に存在する場合、[LDIF]形式のディレクトリ全体の定義が含まれます。LDIFファイルには、パラメーターSMIMEタイプ/署名されたデータを備えたMIMEタイプのアプリケーション/PKCS7-MIMEがあります。[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.
二次環境記録には、プロバイダーに接続されたすべてのレコードに対してメイン環境の属性から取得される「LDIFLOCOTIONURL」属性を含めてはなりません。
( 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名 'ldiflocationurl' desc 'エントリを定義するLDIFファイルのURL' equality caseexactmatch構文1.3.6.1.4.1.14666.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.1.146.115.121.1.15）構文は[LDAP-Syntaxes]で定義されています。
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.
セカンダリオペレーティング環境に対するレコードの「DistinguishedName」は、 "<providerunits = <環境>、providername = <name>、o = postacert>"です。すべてのプロバイダーは、レコード内に「ProviderUnit」属性とDistinguedNameに属性がないために区別できる独自の主要な環境に関連付けられたレコードを持つ必要があります。
( 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 '' desc '' evality caseignorematch substringsubstringsmatch構文1.3.6.1.4.1.14666.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.1.146.115.121.1.15）構文は[LDAP-Syntaxes]で定義されています。
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 name 'ldiflocationurlobject' sup top auxiliary 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 Name 'Provider' SUP TOP Structural Must（ProviderCertificateHash ProviderCertificate Providername MailReceipt ManagedDomains）
MAY ( description LDIFLocationURL providerUnit )
5月（説明ldiflocationurl providerunit）
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ファイルは、ベースルートと2つの架空のプロバイダーを含むプロバイダーのディレクトリの例を表しています。挿入された証明書は、たとえば目的でのみ使用される2つの自己署名証明書です。
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 = PostAcert ObjectClass：Top ObjectClass：ObjectClass：ldiflocationurlobject O：postacert ldiflocationurl：https：//igpec.rupa.example.com/igpec.ldif.p7m説明：PEC Probiders Directory DNのベースルート認定メールS.P.A.、O = Postacert ObjectClass：Top ObjectClass：Provider Providername：Anonymous Certified Mail S.P.A. ProviderCertificateHash：7E7AEF1059AE0F454F2643A95F69EC3556009239 Providefificate; 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: 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
Z9 5Z/1OCFNHLFQF1VH2NSS8TAYCCI/VO7W1Q1KCA2VLXLQP7MCSUW == MALERECEIPT：ssacceptance@postalser.example.com ldiflocationurl：https://anpocermamp.commainp.commapmamp.commapmapmapmapmapmapmapmapmapmapmapmapmapmapmapmapmapmapmapmapmapmamp.Commed..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 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
xpifmuci5slj.example.com説明：一般のための認定メールサービス
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ファイルは、ベースルートと2つの架空のプロバイダーを含むPECプロバイダーのディレクトリの例を表しています。挿入された証明書は、たとえば目的でのみ使用される2つの自己署名証明書です。
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 = Postacert Objectlass：Top ObjectClass：Provider Providername：Anonymous Certified Mail S.P.A.
providerCertificateHash: 7E7AEF1059AE0F454F2643A95F69EC3556009239 providerCertificate;binary:: MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9 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
.example.com ManagedDomains：costmec.example.com説明：企業向けの認定メールサービスExample.com ManagedDomains：infornical.anpocert.example.com説明：企業内部サービスDN：プロバイダーname =郵便サービスs.r.l.、o =郵便局オブジェクトクラス：トップオブジェクトクラス：プロバイダープロバイダー名：郵便サービスs.r.l.説明：一般のための認定郵便サービス
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システムに関係するもう1つの重要なセキュリティの側面は、すべての処理されたメッセージのセキュリティを危険にさらすことをウイルスの存在をブロックする必要がある技術的および機能的アーキテクチャに関連しています。したがって、これまでに議論されてきたことに準拠して、認定郵便の内容に介入することなく、可能な限り感染を妨げるアンチウイルスシステムの設置と継続的な更新が必要です。
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]に基づいており、標準の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.
証明書のPECプロバイダー保有者に関連する情報は、サブジェクトフィールド（サブジェクトDN）に挿入する必要があります。より正確には、サブジェクトDNは、PECプロバイダーディレクトリ（セクション4.5）に公開されている「プロビダヤーム」属性にあるため、PECプロバイダーの名前を含める必要がありますが、主題DNはLDIFのプロバイダーエントリDNを一致させる必要はありません。プロバイダー名は、「件名：」のcommonnameまたはguntionalName属性に存在する必要があります。証明書のフィールド。
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.
証明書にはインターネットメールアドレスが含まれている必要があります。インターネットメールアドレスには、subjectaltname拡張子に値が必要であり、件名の著名な名前に存在しないでください。
Valid subjectDN are:
有効な件名は次のとおりです。
C=IT, O=AcmePEC 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）には、DigitalSignatureビット（ビット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.
Authority Key Identifier（オブジェクトID：2.5.29.35）には、少なくともKeyIdentifierフィールドが含まれている必要があり、クリティカルとしてマークされてはなりません。
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
... 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
A3A70AE1署名：アルグ。ID：ID-SHA1-WITH-RSA-INCRYPTIONパラメーター：0値：0x874B4D25 70A46180 C9770A85 FE7923CE B22D2955 2F3AF207 142B2ABA 643AAA61 ... D8FD104442888888888888888888888888888888888888888888888492B2B2AB2AB2AB2AB2A
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
: 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プロバイダーディレクトリの内容は、[TLS]で説明されているように、必要なユーザー証明書を持つライセンスプロバイダーのみが[TLS]に記載しているように、[HTTP]を介して[HTTP]を介して照会する必要があります。このアクセスモダリティは、データの信頼性、完全性、および機密性を保証します。各プロバイダーは、[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（LATIN-1）」文字セットのサポート。
o support for S/MIME v3 standard, as in [SMIMEV3], for verification of signatures applied to PEC envelopes and notifications.
o [SMIMEV3]のように、S/MIME V3標準のサポート、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）に存在すること、および[メール]で抽出されたドメインが「：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-Aiana]によって指定および要求されているように、このドキュメントは、新しいヘッダーフィールドを次のように暫定メッセージヘッダーフィールドとして登録します。
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 Roma Italyメール：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 Roma Italyメール：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-verificasicurezza：
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 Roma Italyメール：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 Roma Italyメール：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 Roma Italyメール：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 Roma Italyメール：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-Aiana]が指定および要求するように、このドキュメントは、専門家のレビューに従って新しい記述子を次のように登録します。
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 Roma Italyメール：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
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 5652、2009年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 5280、2008年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-Aiana] 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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[HTTPS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTPS] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[LDAP] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[LDAP] Zeilenga、K.、ed。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年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-Aiana] Zeilenga、K。、「Internet Assigned Numbers Authority（IANA）Lightweight Directory Access Protocol（LDAP）の考慮事項」、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。、「Lightweight Directory Access Protocol（LDAP）：構文と一致するルール」、RFC 4517、2006年6月。
[LDIF] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[LDIF] Good、G。、「LDAPデータインターチェンジ形式（LDIF） - 技術仕様」、RFC 2849、2000年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。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年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。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提出] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3] Myers、J。and M. Rose、「郵便局プロトコル - バージョン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、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年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のセキュリティマルチパート：MultiPart/Signed and Multipart/暗号化」、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、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年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、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2証明書処理」、RFC 5750、2010年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年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。、「配送ステータス通知（DSNS）のSimple Mail Transfer Protocol（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、「The Transport Layer Security（TLS）Protocolバージョン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（第5版）」、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。、「Lightweight Directory Access Protocol（LDAP）：バイナリエンコードオプション」、RFC 4522、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証明書のLightWeight Directory Access Protocol（LDAP）スキーマ定義」、RFC 4523、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
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
Italian terms in the DTD relative to the certification XML file:
認証XMLファイルに対するDTDのイタリア語の用語：
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
Authors' Addresses
著者のアドレス
Claudio Petrucci DigitPA Viale Marx 31/49 00137 Roma Italy
Claudio Petrucci Digitpa Viale Marx 31/49 00137 Roma Italy
EMail: petrucci@digitpa.gov.it
Francesco Gennai ISTI-CNR Via Moruzzi, 1 56126 Pisa Italy
Francesco Gennai ISTI-CNR経由のMoruzzi、1 56126 Pisa Italy
EMail: francesco.gennai@isti.cnr.it
Alba Shahin ISTI-CNR Via Moruzzi, 1 56126 Pisa Italy
Alba Shahin Isti-Cnr経由のMoruzzi、1 56126 Pisa Italy
EMail: alba.shahin@isti.cnr.it
Alessandro Vinciarelli Via delle Vigne di Morena 113 00118 Roma Italy
Alessandro Vinciarelli Delle Vigne Di Morena 113 00118 Roma Italy
EMail: alessandro.vinciarelli@gmail.com