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
公認電子メール - イタリアの認定電子メール
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年後、（イタリア語の「ポスタELETTRONICA Certificata」で）公式の電子配信サービス、名前の公認電子メールの特性は、システムに法的地位を与えて、定義されていました。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6109.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6109で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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」に、イタリアのポスタELETTRONICA Certificataに）公認の電子メールの名前の公式の電子配信サービスの特徴は、システムに法的地位を与えて、定義されていました。
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 - 11月-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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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
Certification data: A set of data certified by the sender's PEC provider that describes the original message. It includes the date and time of dispatch, sender email address, recipient(s) email address(es), subject, and message identifier.
認定データ：元のメッセージを説明し、送信者のPECプロバイダによって認定されたデータのセット。これは、日付と発送時、送信者の電子メールアドレス、受信者のメールアドレス（複数可）、件名、およびメッセージ識別子を含んでいます。
Certified electronic mail: A service based on electronic mail, as defined by the [EMAIL] and [SMTP] standards and extensions, which permits the transmission of documents produced with informatics tools.
公認電子メール：インフォマティクスツールで作成されたドキュメントの送信を許可する[EMAIL]で定義された電子メールに基づいて、サービス、および[SMTP]の標準と拡張、。
DigitPA: Ex-CNIPA.
DigitPA：元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システムに提出される前に、[EMAIL]で定義されるように、電子メールクライアントによって生成されたメッセージ識別子です。
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プロバイダ：アクセス、レセプション、および配信のそれらの相対的なポイントを一つ以上の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.
封筒。
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: "John Smith" <john.smith@domain.example.com>
From： "ジョン・スミス" <john.smith@domain.example.com>
would result in the following "From:" value in the respective PEC transport envelope:
それぞれのPEC輸送封筒の値：「から」次のようになります：
From: "On behalf of: john.smith@domain.example.com"
<certified-mail@provider.example.com>
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：」と「送信者：」フィールドが同じ値を含まなければなりません。回答が正しく戻って適切な宛先に送信するためには、「返信先：」フィールドPEC輸送封筒に元のメッセージのと同じ変更されていない値が含まれていなければならない「返信先：」フィールドを。元のメッセージ内のフィールド：「から」それが明示的に元のメッセージで指定されていない場合は、PEC輸送エンベロープを生成するシステムは、から情報を抽出し、それを作成します。
When PEC notifications are sent, the system MUST use the original message sender's address as the destination address, as is specified in the reverse path data of the SMTP protocol. PEC notifications MUST be sent to the sender's PEC mailbox without taking into account the "Reply-To:" field, which might be present in the original message's header.
PEC通知が送信される場合、システムは、SMTPプロトコルの逆の経路データに指定されたように、宛先アドレスとして、元のメッセージの送信者のアドレスを使用しなければなりません。フィールド、元のメッセージのヘッダに存在する可能性がある：PECの通知は、「返信先」を考慮に入れずに、送信者のPECのメールボックスに送らなければなりません。
All system-generated PEC messages are identifiable for having a specific header defined in PEC according to the type of message generated.
すべてのシステムによって生成PECメッセージが生成されたメッセージの種類に応じてPECに定義された特定のヘッダを持つために識別可能です。
To determine the certification data, the elements used for the actual routing of the message are employed. In SMTP dialog phases, the reverse path and forward path data ("MAIL FROM" and "RCPT TO" commands) are thus considered certification data of both the sender and the recipients, respectively. Addressing data present in the message body ("To:" and "Cc:" fields) are used solely in order to discriminate between primary and carbon copy recipients when necessary; addressing data present in the "Bcc:" field MUST be considered invalid by the system.
認証データを決定するために、メッセージの実際のルーティングのために使用される要素が使用されます。 SMTPダイアログ段階で、反転経路と往路データ（「FROM MAIL」とコマンド「をRCPT」）はこのように、それぞれ、送信者と受信者の両方の認証データと考えられます。メッセージ本文中に存在するデータをアドレス（「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:
またはX-受信：
o X-Riferimento-Message-ID:
またはX-リファレンス - メッセージ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-メッセージ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メッセージを受信した送信いずれかを通知し、宛先（S）にそれを転送する責任を取ります。それ以降、送信側プロバイダは、もはやメッセージの所在についての責任を負いませんが、配達の成功または失敗のそのユーザに知らせるに限定されています。
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通知は、メッセージが送信者から派遣されてきた、と何のサーバー・サーバーの受け入れや配信PEC通知を受信していない12時間後に送信されます。これらは、遅延をユーザに通知する唯一の目的を持っています。
If another 12 hours go by without any sign of a server-server acceptance or delivery PEC notification (amounting to a 24-hour delay), another delay PEC notification is dispatched to the user informing him of the possible delivery failure. The provider will not keep track of the delay any further.
別の12時間は、サーバーのサーバーの受け入れや配信PEC通知（24時間対応の遅れに相当）の兆候なしで行く場合は、別の遅延PEC通知が可能な配信失敗の彼を知らせるユーザーに派遣されます。プロバイダは、任意の更なる遅延を追跡しません。
They are sent when there is some error in transmission or reception. More specifically, a failure PEC notification can indicate either a formal-exception error or a virus detection.
送信または受信中に何らかのエラーがあったとき、彼らが送信されます。具体的には、故障PEC通知は、正式な例外エラーまたはウイルス検出のいずれかを示すことができます。
Added header fields are:
付加されたヘッダフィールドは、次のとおりです。
o X-Ricevuta:
またはX-受信：
o X-Riferimento-Message-ID:
またはX-リファレンス - メッセージ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-メッセージ-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 Cc: o Return-Path:
O Ccを：リターンパスO：
o Reply-To: (if present)
O返信先：（存在する場合）
Depending on the type of message requesting admission into the PEC network, it will be inserted in either a PEC transport envelope or a PEC anomaly envelope. Distinction will be possible through the addition of the "X-Trasporto:" header field.
PECのネットワークへの承認を要求するメッセージのタイプに応じて、それはPECトランスポート・エンベロープまたはPEC異常エンベロープのいずれかに挿入されます。 「X-Trasporto：」ヘッダフィールドの区別は、の添加によって可能となります。
+-------------+ +------------+
| +--+ | | |
| |AP| | PEC | |
+----+ | +--+ | messages & | +---+ +--+ | +----+
|user|<-->| |<------------->| |InP| |DP| |<-->|user|
+----+ | +--+ +---+ | notifications | +---+ +--+ | +----+
| |DP| |InP| | | |
| +--+ +---+ | | |
+-------------+ +------------+
PEC PEC
sender receiver
provider provider
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.
そして「CC：」：（セクション4.5を参照）PECプロバイダディレクトリで利用可能なデータを使用して、アクセスポイントは、「へ」で、すべての受信者のチェックを実行し、元のメッセージに存在するフィールドは、彼らがPECインフラストラクチャに属しているかどうかを確認したり、非PECドメインへ。このようなチェックはPECプロバイダディレクトリ内で見つかった 『managedDomains』属性に受信者のドメインから、大文字と小文字を区別しない検索によって、存在を確認することによって行われます。したがって、サーバユーザ受付PEC通知（及び関連する認証データ）に関し、アドレスごとに、そのドメインの類型。 PECまたは非PEC。
The message identifier (PEC msgid) of accepted original messages within the PEC infrastructure MUST be unambiguous in order to consent correct tracking of messages and relative PEC notifications. The format of such an identifier is:
PECインフラストラクチャ内に受け入れられ、元のメッセージのメッセージ識別子（PECのMSGID）はメッセージと相対PEC通知の正確なトラッキングを同意するために明白でなければなりません。そのような識別子の形式は次のとおりです。
[alphanumeric string]@[provider mail domain]
[英数字の文字列] @ [プロバイダのメールドメイン]
or:
または：
[alphanumeric string]@[FQDN mail server]
[英数字の文字列] @ [FQDNメールサーバー]
Therefore, both the original message and the corresponding PEC transport envelope MUST contain the following header field:
したがって、元のメッセージと対応PECトランスポート・エンベロープの両方が、次のヘッダフィールドを含まなければなりません。
Message-ID: <[unique identifier]>
メッセージID：<一意の識別子]>
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で置換されていてもSHALL。送信者が相対PEC通知とともに送信されたメッセージをリンクすることを可能にするために、MSGIDは、元のメッセージと同様に相対PEC通知およびトランスポート・エンベロープ内に挿入されなければなりません。存在する場合、MSGIDは、次のヘッダーフィールドを追加することにより、元のメッセージのヘッダに必要とされます。
X-Riferimento-Message-ID: <[msgid]>
X-リファレンス・メッセージ-ID：<[MSGID]>
which will also be inserted in the PEC transport envelope and notifications, and related in the certification data (see section 4.4).
これはまた、PECトランスポート・エンベロープと通知に挿入され、認証データ（セクション4.4を参照）に関連します。
This point permits the exchange of PEC messages and notifications between PEC providers. It is also the point through which ordinary mail messages can be inserted within the system of certified mail.
この点は、PECプロバイダ間PECメッセージや通知の交換を可能にします。また、通常のメールメッセージが証明郵便のシステムの中に挿入可能なポイントです。
The exchange of messages between providers takes place through SMTP-based transactions, as defined in [SMTP]. If SMTP communication errors occur, they MAY be handled using the standard error notification mechanisms, as provided by SMTP in [SMTP] and [SMTP-DSN]. The same mechanism is also adopted for handling transitory errors, that result in long idling periods, during an SMTP transmission phase. In order to guarantee that an error is returned to the user, as defined in section 3.3.3, the system that handles PEC traffic MUST adopt a time limit for message idleness equal to 24 hours.
[SMTP]で定義されるようにプロバイダ間のメッセージの交換は、SMTPベースの取引を通じて行われます。 SMTP通信エラーが発生した場合、それらは[SMTP]および[SMTP-DSN] SMTPによって提供されるように、標準エラー通知メカニズムを使用して処理することができます。同機構はまた、SMTP送信フェーズ中に、長いアイドル期間中に、一時的エラーを処理するためにその結果を採用しています。セクション3.3.3で定義されたように、エラーがユーザに返されることを保証するために、PECのトラフィックを処理するシステムは、24時間に等しいメッセージアイドル状態の時間制限を採用しなければなりません。
Once a message arrives, the Incoming Point runs the following list of checks and operations:
メッセージが到着すると、着信ポイントは、小切手や操作の次のリストを実行します：
o verifies correctness and type of the incoming message;
Oは、着信メッセージの正しさと種類を検証します。
o if the incoming message is a correct and undamaged PEC transport envelope:
O受信メッセージは正しいと破損していないPEC輸送封筒の場合：
- emits a server-server acceptance PEC notification towards the sender provider (section 3.2.1);
- 送信者プロバイダ（セクション3.2.1）に向かってサーバ - サーバ受付PEC通知を発します。
- forwards the PEC transport envelope to the Delivery Point (section 3.3).
- 配信ポイント（セクション3.3）にPEC輸送封筒を転送します。
o if the incoming message is a correct and undamaged PEC notification, forwards the notification to the Delivery Point.
着信メッセージが正しいと無傷PEC通知である場合はO、配信ポイントに通知を転送します。
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.
存在、起源、および署名の有効性について検証を渡し、受信メッセージ、すなわち、正しいと破損していないPEC輸送封筒または通知の前提条件に適合しますが、PECプロバイダから来ていない場合は、O、メッセージがでなければなりません受信者に向けて伝播さ。
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:
着信メッセージ、すなわち、存在、起源、および署名の妥当性について検証を失敗し、PECシステムに由来していない場合、O、メッセージは受信者に伝播する場合、通常のメールとして扱われ、されます。
- is inserted in a PEC anomaly envelope (section 3.2.2);
- PEC異常エンベロープ（セクション3.2.2）に挿入されます。
- the PEC anomaly envelope is forwarded to the Delivery Point.
- PEC異常エンベロープは、配信ポイントに転送されます。
The server-server acceptance PEC notification is generated by the receiving provider and sent to the sending provider. Its purpose is to keep track of the message in its transition from one provider to another, and is therefore strictly intra-provider communication; the end user knows nothing about it.
サーバー・サーバーの受け入れPEC通知は、受信者によって生成され、送信者に送信されます。その目的は、別のプロバイダからの移行にメッセージを追跡することであるため、厳密イントラプロバイダ通信です。エンドユーザーはそれについて何も知りません。
To check the correctness and integrity of a PEC transport envelope or notification, the Incoming Point runs the following tests:
PEC輸送封筒または通知の正確性および完全性をチェックするには、着信ポイントは、次のテストを実行します。
o Signature existence - the system verifies the presence of an S/MIME signature structure within the incoming message;
署名存在O - システムが着信メッセージ内のS / MIME署名構造の存在を検証します。
o Signature origin - the system verifies whether or not the signature belongs to a PEC provider by extracting the certificate used for signing and verifying its presence in the PEC providers directory. To ease the check, it is possible to calculate the certificate's [SHA1] hash value and perform a case-insensitive search of its hexadecimal representation within the "providerCertificateHash" attribute found in the PEC providers directory. This operation allows one to easily identify the sender provider for subsequent and necessary matching checks between the extracted certificate and the one present in the provider's record;
O署名原点 - システムは、署名が署名に使用される証明書を抽出し、PECプロバイダディレクトリにその存在を確認することにより、PECプロバイダに属しているか否かを検証します。チェックを容易にするために、証明書の[SHA1]ハッシュ値を計算し、PECプロバイダディレクトリにある「providerCertificateHash」属性内の16進表現の大文字と小文字を区別しない検索を行うことが可能です。この操作は、1つの容易に抽出した証明書及びプロバイダのレコード内の1つの存在との間の後続の、必要な整合性チェックのために送信者プロバイダを識別することを可能にします。
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;
署名有効○ - 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トランスポート・エンベロープと通知）で指定されたフォーマットに準拠していることを保証するのに十分かつ必要なチェックを実行します。
If a virus-infected PEC transport envelope passes the checks just mentioned, it is still considered correct and undamaged. The presence of the virus will be detected in a second phase, during which the contents of the PEC transport envelope are verified. Thus, the Incoming Point will refrain from forwarding the message to the recipient, instead sending the appropriate PEC notification of non-delivery and storing the virus-infected message in the provider's special storage.
ウイルスに感染したPEC輸送エンベロープは今述べた小切手を渡した場合、それはまだ正しいと破損していないと考えられています。ウイルスの存在は、PECトランスポート・エンベロープの内容が検証されている間に第二相で検出されます。したがって、着信ポイントは、受信者にメッセージを転送する代わりに、不達の適切なPEC通知を送信し、プロバイダの特別なストレージにウイルスに感染したメッセージを格納する控えます。
In case ordinary mail messages are received, the PEC provider SHALL perform virus checks in order to prevent the infiltration of potentially dangerous mail messages within the PEC system. If a virus is detected in an ordinary mail message, the latter can be discarded at the Incoming Point before it enters the PEC system. In other words, no special treatment is reserved for the error; it is handled in a manner that is conformant to the procedures usually followed for messages going through the Internet.
場合には、通常のメールメッセージが受信され、PECプロバイダは、PECシステム内の潜在的に危険なメールメッセージの侵入を防止するために、ウイルスチェックを実行しなければなりません。ウイルスは通常のメールメッセージで検出された場合は、PECシステムに入る前に、後者は、受信時点で廃棄することができます。換言すれば、特別な処理は、エラーのために予約されていません。それは、通常はインターネットを経由するメッセージのために続く手順に準拠した方法で処理されます。
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メールボックスにのみ有効なPECトランスポート・エンベロープ（セクション2.2.2および3.1.5）の受信に送達した後の送達PEC通知（セクション3.3.2）が放出されます。
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:
プロバイダの排他的使用のために、2つだけの場合、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.
PEC輸送封筒や通知を送信するとき、このアドレスはセクション2.2.5で説明したサービスのメールボックスのそれと一致していてもよいセクション3に記述されているように各プロバイダは、使用のために特別な目的の電子メールアドレスを登録する必要があります。
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:
アクセスポイントは、ユーザが送信したいメッセージを受信した場合、それは[EMAIL]で定義された前記メッセージの正式な適合性を保証する、とすることを確認する必要があります。
o [EMAIL] header section contains a "From:" header field holding an [EMAIL] compliant email address;
[EMAIL]準拠の電子メールアドレスを保持するヘッダフィールド; O [EMAIL]ヘッダ部の「From」が含ま
o [EMAIL] header section contains a "To:" header field holding one or more [EMAIL] compliant email addresses;
一つ以上の[EMAIL]準拠の電子メールアドレスを保持するヘッダフィールド; O [EMAIL]ヘッダ部は「」を含みます
o sender's address, specified in the SMTP reverse path, coincides with the one in the message's "From:" header field;
O SMTPリバースパスで指定された送信者のアドレスは、メッセージの「から：」中の1つに一致するヘッダ・フィールドと
o recipients' addresses specified in the SMTP forward path coincide with the ones present in the "To:" or "Cc:" header fields of the message;
または 『CC：』：O SMTPフォワードパスで指定された受信者のアドレス 『は』中に存在するものと一致するメッセージのヘッダフィールド。
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メガバイトであるとして、この制限を指定しています。
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]
「[元の送信者」から[日]で[時間]（[時間帯]）、メッセージ中の「[被験者]」元のメッセージ受付における誤差と宛：[recipient_1] [recipient_2] [recipient_n]問題原因[エラーの説明]への受け入れを防止することを検出しました。メッセージは受け入れられませんでした。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
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.
同一の認証情報は、このように、メッセージ（セクション4.4）に自動検査を可能にする、通知の本体に追加するXMLファイルに挿入されます。解析はXMLの一部で行われなければなりません。追加の部品は、プロバイダ固有のサービスの提供者が含まれるかもしれません。いずれにしても、元のメッセージを含んではいけません。メッセージは、セクション4.3で記述されたフォーマットに従わなければなりません。
The Access Point MUST run some tests on the content of messages it receives from its users and reject them if a virus is detected. In which case, a virus-detection-induced non-acceptance PEC notification MUST be emitted to clearly inform the user of the reason the message was refused.
アクセスポイントは、それがそのユーザーから受信したメッセージの内容にいくつかのテストを実行し、ウイルスが検出された場合、それらを拒絶しなければなりません。その場合には、ウイルス検出誘導性非受付PEC通知は、明らかにメッセージが拒否された理由をユーザに知らせるために放射されなければなりません。
The notification header contains the following fields:
通知ヘッダは、次のフィールドが含まれています。
X-Ricevuta: non-accettazione X-VerificaSicurezza: errore Date: [notification emission date] Subject: AVVISO DI NON ACCETTAZIONE PER VIRUS: [original subject] From: posta-certificata@[mail domain] To: [original sender] X-Riferimento-Message-ID: [msgid]
X-受信：X-VerificaSicurezzaの非受理：エラー日付：[通知放出日付]件名：から[元の件名]：警告はVIRUSに同意しない認定メール@ [電子メールドメイン]宛先：[元の送信者] X-リファレンス - メッセージ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]
「[元の送信者」から[日]で[時間]（[時間帯]）、メッセージ中の「[被験者]」元にウイルスの存在にメッセージ受付における誤差と宛：[recipient_1] [recipient_2] [ recipient_n】セキュリティ上の問題が検出されたコンテンツタイプの[ID]を検出しました。メッセージは受け入れられませんでした。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
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.
同一の認証データは、自動チェック（セクション4.4）を可能にするために、通知に加えXMLファイルに挿入されます。解析はXMLの一部で行われなければなりません。追加の部品は、プロバイダ固有のサービスの提供者が含まれるかもしれません。いずれにしても、元のメッセージを含んではいけません。メッセージは、セクション4.3で記述されたフォーマットに従わなければなりません。
The server-user acceptance PEC notification is a message sent to the sender by his server, containing date and time of message acceptance into the system, sender and recipient data, and subject.
サーバ・ユーザ受け入れPEC通知は、彼のサーバーによって送信者に送信されるメッセージは、システム内のメッセージの受け入れの日付と時刻を含む、送信者と受信者データ、及び対象となります。
The header contains the following fields:
ヘッダーには、次のフィールドがあります。
X-Ricevuta: accettazione Date: [actual date of server-user acceptance] Subject: ACCETTAZIONE: [original subject] From: posta-certificata@[mail domain] To: [original sender] X-Riferimento-Message-ID: [msgid]
X-受信：受入日：から[元の件名]：[実際のサーバー・ユーザーの受け入れの日付]件名：ACCEPTED認定メール@ [電子メールドメイン]宛先：[差出人] X-リファレンス - メッセージ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]
[時間]（[タイムゾーン]）で、[日付]でサーバー・ユーザー受け入れPEC通知、メッセージ「[件名]」「[元の送信者]」からの発信元と宛て：[recipient_1]（[「証明郵便」| 「普通郵便」]）[recipient_2]（[「書留郵便」|「普通郵便」]）[recipient_n]（[「書留郵便」|「普通郵便は」]）システムによって受け入れられ、受信者に転送された（S ）。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
The same certification data is inserted in an XML file added to the notification message, allowing automatic checks on it (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the provider for provider-specific services. The message MUST follow the format described in section 4.3.
同一の認証データをXMLファイルに挿入され、その上に自動チェック（セクション4.4）を可能にする、通知メッセージに付加。解析はXMLの一部で行われなければなりません。追加の部品は、プロバイダ固有のサービスの提供者が含まれるかもしれません。メッセージは、セクション4.3で記述されたフォーマットに従わなければなりません。
A PEC transport envelope is a message generated by the Access Point that contains the original message as well as certification data.
PEC輸送エンベロープは元のメッセージだけでなく、認証データが含まれているアクセスポイントによって生成されたメッセージです。
As mentioned in section 2.1.1.2, the PEC transport envelope inherits from the original message the values of the following header fields, which MUST be related unmodified:
セクション2.1.1.2で述べたように、PECトランスポート・エンベロープは、修飾されていない関連していなければならない元のメッセージ次のヘッダフィールドの値を継承します。
o Received:
O受信：
o To:
中：
o Cc:
O Ccと：
o Return-Path:
Oリターンパスを：
o Reply-To: (if present)
O返信先：（存在する場合）
On the other hand, the following fields MUST be modified, or inserted if necessary:
一方、次のフィールドは、変更、または必要に応じて挿入されなければなりません。
X-Trasporto: posta-certificata Date: [actual date of server-user acceptance] Subject: POSTA CERTIFICATA: [original subject] From: "On behalf of: [original sender]" <certified-mail@[mail_domain]> Reply-To: [original sender] (inserted only if not present) Message-ID: [PEC msgid generated as in section 2.2.1] X-Riferimento-Message-ID: [msgid] X-TipoRicevuta: [completa/breve/sintetica]
X-Trasporto：ポスタ - certificata日：[サーバー・ユーザーの受け入れの実際の日付]件名：POSTA CERTIFICATA：[オリジナル件名]から： "に代わって：[元の送信者]" <認定メール@ [MAIL_DOMAIN]> Reply- （のみ存在しない場合に挿入された）元の送信者]メッセージID：にX-Riferimento-メッセージID [PECはセクション2.2.1のように生成MSGID]：[MSGID] X-TipoRicevuta：[completa /ブレーベ/ sintetica]
The "X-TipoRicevuta:" field indicates the type of delivery PEC notification the sender wishes to receive -- complete, brief, or concise.
「X-TipoRicevutaは：」 - 、完全な簡単な、または簡潔なフィールドは、送信者が受信を希望する配信PEC通知の種類を示します。
The body of the PEC transport envelope contains a text part that constitutes the readable format of the message according to a model that relates the following certification data:
PECトランスポート・エンベロープの本体には、以下の認証データを関連づけるモデルに従ってメッセージの読み取り可能なフォーマットを構成するテキストの一部を含みます。
Certified mail message On [date] at [time] ([time zone]), the message "[subject]" was sent by "[original sender]" and addressed to: [recipient_1] [recipient_2] [recipient_n] The original message is included in attachment. Message identifier: [PEC msgid of corresponding PEC transport envelope]
[時間]で[日]（[時間帯]）、メッセージ「[件名]」で認定メールメッセージは「[元の送信者]」によって送られ宛てた：recipient_1] [recipient_2] [recipient_n]元のメッセージ添付ファイルに含まれています。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
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トランスポート・エンベロープ内に、全体の、非改変元のメッセージは、その認証データを含む（メッセージ識別子について前記されたものを除く）[EMAIL]、ならびに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通知を発するが、22時間が経過していない前に、メッセージ発送後24時間以内に送達PEC通知を受信しません。
Such a communication takes place through a PEC notification of non-delivery due to timeout, the header of which contains the following fields:
そのような通信は、ヘッダは以下のフィールドを含み、タイムアウトにより未配信のPEC通知によって行われます。
X-Ricevuta: preavviso-errore-consegna Date: [date of notification emission] Subject: AVVISO DI MANCATA CONSEGNA PER SUP. TEMPO MASSIMO: [original subject] From: posta-certificata@[mail domain] To: [original recipient] X-Riferimento-Message-ID: [msgid]
X-受信：気づく誤り配信日：SUPのため予告への配信の失敗：件名[通知放射の日]。 TIMEのLIMIT：[元の件名]から：へ認定メール@ [電子メールドメイン]：[元の受信者] X-リファレンス - メッセージID：[MSGID]
The body of the first non-delivery PEC notification (12-hour timeout) contains a text part that represents the readable format of the notification which will relate the following data:
最初の非配信PEC通知（12時間のタイムアウト）の本体は、次のデータを関連付けるであろう通知の可読フォーマットを表すテキストの一部を含みます。
Non-delivery PEC notification On [date] at [time] ([time zone]), the message "[subject]" originating from "[original sender]" and addressed to "[recipient]" has not been delivered within the first 12 hours following its dispatch. Not excluding that the message might eventually be delivered, it is deemed useful to consider that dispatch might not have a positive outcome. The system will see to sending another non-delivery PEC notification if in the following twelve hours no confirmation is received from the recipient. Message identifier: [PEC msgid of corresponding PEC transport envelope]
[時間]で[日]（[時間帯]）、メッセージ「[件名」由来する「[元の送信者」上の非デリバリーPEC通知とは、「[受信者]」第一内で配信されていないためにアドレスその派遣後12時間。メッセージは最終的に配信される可能性があることを排除しない、発送は肯定的な結果を持っていないかもしれないことを考慮することが有用であると考えています。このシステムは、次の12時間では確認が受信者から受信されない場合は別の非配信PEC通知を送信するに表示されます。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
On the other hand, 24-hour-timeout induced PEC notifications, which have the same header as described above, will have the following text in their body:
一方、上記のように同じヘッダを有する24時間タイムアウト誘起PEC通知は、自分の体に次のテキストを持っているであろう。
Non-delivery PEC notification On [date] at [time] ([time zone]), the message "[subject]" originating from "[original sender]" and addressed to "[recipient]" has not been delivered within 24 hours of its dispatch.
[時間]（[時間帯]）で[日付]上の非デリバリーPEC通知、メッセージ「[件名]」「[元の送信者]」から発信し、「[受信者]が」24時間以内に配信されていないためにアドレスその派遣の。
The transaction is deemed to be considered terminated with a negative outcome. Message identifier: [PEC msgid of corresponding PEC transport envelope]
トランザクションは否定的な結果で終了とみなされるものとみなされます。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
The same certification data is inserted in an XML file added to both PEC notification types to allow automatic checks (section 4.4).
同一の認証データを自動チェック（セクション4.4）を可能にするために、両方のPEC通知タイプに加えXMLファイルに挿入されます。
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プロバイダとの間で交換された場合、受信側は送信側にサーバ - サーバ受付PEC通知を送信しなければなりません。単一ディスパッチ通知は、SMTPトランザクションの同じプロバイダに属し、ルーティング・データに記載されているように誰に着信メッセージが、アドレス指定された（順方向および経路を逆に）すべての受信者にも関します。単一のサーバーのサーバー受付PEC通知の証明データ内に、それが参照するメッセージのすべての受信者が記載されています。 PECトランスポート・エンベロープを受信した場合、一般的に、各プロバイダは、SMTPトランスポートエラーが存在しない場合に、その管轄内のすべての受信者をカバーするために1つまたは複数のサーバ - サーバ受付PEC通知を放出しなければなりません。
The header of a server-server acceptance PEC notification contains the following fields:
サーバー・サーバーの受け入れPEC通知のヘッダには、以下のフィールドが含まれています。
X-Ricevuta: presa-in-carico Date: [date of server-server acceptance] Subject: PRESA IN CARICO: [original subject] From: posta-certificata@[mail domain] To: [sender provider service mailbox] X-Riferimento-Message-ID: [msgid]
X-Ricevuta：PRESA・イン・carico日：[サーバーのサーバー受理の日付]件名：CARICO、IN PRESA：[元の件名]から：ポスタ - certificata @ [メールドメイン]に[送信者プロバイダーサービスのメールボックス] 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]
[時間]（[時間帯]）で[日付]上のサーバ - サーバ受付PEC通知、メッセージ "[件名]" "[元の送信者" 由来と宛：[recipient_1] [recipient_2] [recipient_nありましたシステムによって受け入れられます。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
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.
同一の認証データを自動チェック（セクション4.4）を可能にするために、通知メッセージに追加されるXMLファイルに挿入されます。解析は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異常エンベロープにおけるそのようなメッセージを挿入する必要があります。送達前に、メッセージ全体が受信されたメッセージから次のヘッダーフィールドに修飾されていない値を継承する必要があり、新しいメッセージ内の[MIME1]一部として[EMAIL]に準拠した形式で挿入されている受信点で受信しました：
o Received:
O受信：
o To:
中：
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)]
X-Trasplorto：errore日：[mlessage到着日]件名：ANOMALIA MESSAGGIO：[元の件名]から： "に代わって：[元の送信者]" <ポスタ - certificata @ [MAIL_DOMAIN]>返信先：[元の送信者（挿入のみ]）が既に存在していない場合
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.
[時間]（[時間帯]）での異常について[日]メッセージ、 "[元の送信者]" からのメッセージ "[件名" 発信元及び宛て：[recipient_1] [recipient_2] [recipient_n]を受信しました。 [エラーの簡潔な説明]元のメッセージが添付されている：データは、次のエラーのために認証されていません。
Due to uncertainty regarding origin and/or conformity of the message received, the PEC anomaly envelope MUST NOT contain [MIME1] parts other than the entire message that arrived at the Incoming Point.
受信したメッセージの発信元および/または適合性に関する不確実性に、PECの異常エンベロープは着信ポイントに到着したメッセージ全体以外の[MIME1]の部分を含んではなりません。
Note that the routing data of such an envelope (forward and reverse paths) remain unaltered. Doing so guarantees both message forwarding to the recipients, and reception of SMTP error notifications, if any occur, by the sender (as specified in [SMTP] and [SMTP-DSN]).
そのようなエンベロープのルーティングデータ（順方向および経路を逆に）不変のままであることに注意してください。そうすることで受信者にメッセージ転送、およびSMTPのエラー通知の受信の両方を保証し、いずれかが発生した場合、送信者（[SMTP]および[SMTP-DSN]指定されるように）。
If the Incoming Point receives virus-infected PEC messages, it MUST NOT forward them. Rather it MUST inform the sending provider, which will in turn inform the sending user, of the failed transmission. A separate PEC notification of virus detection MUST be sent on behalf of every recipient within the provider's domain.
着信ポイントがウイルスに感染したPECメッセージを受信した場合、それはそれらを転送してはなりません。むしろそれは、順番に失敗した伝送の送信をユーザーに、通知する送信者を、通知しなければなりません。ウイルス検出の別のPEC通知は、プロバイダのドメイン内のすべての受信者に代わって送らなければなりません。
In case a virus is detected during the reception phase of a message whose origin was asserted through sender signature verification, the system generates a virus-detected PEC notification indicating the error found, and sends it to the sending provider's service mailbox.
場合にウイルスが起源送信者の署名検証を通じてアサートされたメッセージの受信フェーズ中に検出され、システムが見つかったエラーを示すウイルス検出PEC通知を生成し、送信プロバイダのサービスメールボックスに送信します。
The header of this PEC notification contains the following fields:
このPEC通知のヘッダには、次のフィールドが含まれています。
X-Ricevuta: rilevazione-virus X-Mittente: [original sender] Date: [date of notification emission] Subject: PROBLEMA DI SICUREZZA: [original subject] From: posta-certificata@[mail domain] To: [sender provider notifications] X-Riferimento-Message-ID: [msgid]
X-受信：認識ウイルスX-送信者：[元の送信者]日付：[通知エミッションの日付]件名：安全保障の問題：[元の件名]から：認定メール@ [電子メールドメイン]に[送信者のプロバイダの通知] X-リファレンス - メッセージID：[MSGID]
The body contains a readable text part according to a model that relates the following data:
本体には、次のデータを関連付けるモデルに従って読み取り可能なテキスト部分が含まれています。
Virus detection PEC notification On [date] at [time] ([time zone]), in the message "[subject]" originating from "[original sender]" and addressed to "[recipient]" a security problem was detected [ID of content type detected]. Message identifier: [PEC msgid of corresponding PEC transport envelope]
メッセージ中の[時間]（[時間帯]）で[日付]でウイルス検出PEC通知、「[被験者]」「[元の送信者]」から発信し、「[受信者]」セキュリティの問題が検出されたに対処[IDコンテンツタイプ]検出。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
The same certification data is inserted in an XML file and added to the notification to allow for automatic checks (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the provider for provider-specific services. Regardless, the original message MUST NOT be included. The message MUST follow the format described in section 4.3.
同じ認証データはXMLファイルに挿入し、自動チェック（セクション4.4）を可能にするために、通知に追加されます。解析はXMLの一部で行われなければなりません。追加の部品は、プロバイダ固有のサービスの提供者が含まれるかもしれません。いずれにしても、元のメッセージを含んではいけません。メッセージは、セクション4.3で記述されたフォーマットに従わなければなりません。
The message body MUST contain the reason for which the transmission could not be completed.
メッセージ本文は、送信が完了できなかった理由を含まなければなりません。
At the reception of a virus detection PEC notification from the receiving provider, the sender provider emits a non-delivery PEC notification to the sending user.
受信者からのウイルス検出PEC通知の受信時に、送信者は、送信ユーザに配信不能PEC通知を発します。
The header for this notification contains the following fields:
この通知のヘッダーには、以下のフィールドが含まれています。
X-Ricevuta: errore-consegna X-VerificaSicurezza: errore Date: [date of notification emission] Subject: AVVISO DI MANCATA CONSEGNA PER VIRUS: [original subject] From: posta-certificata@[mail domain] To: [original sender] X-Riferimento-Message-ID: [msgid]
X-受信：エラー・デリバリーX-VerificaSicurezza：エラー日付：[通知エミッションの日付]件名：ウイルスの配信に失敗した注意：[元の件名]から：認定メール@ [電子メールドメイン]宛先：[元の送信者] X -reference-メッセージID：[MSGID]
The body contains a readable text part according to a model that relates the following data:
本体には、次のデータを関連付けるモデルに従って読み取り可能なテキスト部分が含まれています。
Delivery error PEC notification due to virus On [date] at [time] ([time zone]), in the message "[subject]" addressed to "[recipient]" a security problem was detected [ID of content type detected by the anti-virus]. The message was not delivered. Message identifier: [PEC msgid of corresponding PEC transport envelope]
メッセージ中の[時間]（[時間帯]）で[日付]に起因するウイルスへの配信エラーPEC通知、「[被験者]」「[受信者]」セキュリティの問題が検出されたに対処[コンテンツタイプのIDにより検出されアンチウイルス]。メッセージは配信されませんでした。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
All the information necessary for the construction of such a PEC notification can be obtained from the correlated virus-detected PEC notification.
このようなPEC通知の構築のために必要なすべての情報は、相関ウイルス検出PEC通知から得ることができます。
The same certification data is inserted in an XML file and added to the notification message to allow for automatic checks (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the provider for provider-specific services. The reason the transaction was not completed MUST be specified in the message, which MUST follow the format described in section 4.3.
同じ認証データはXMLファイルに挿入し、自動チェック（セクション4.4）を可能にするために、通知メッセージに付加されます。解析はXMLの一部で行われなければなりません。追加の部品は、プロバイダ固有のサービスの提供者が含まれるかもしれません。トランザクションが完了しなかった理由は、セクション4.3で説明したフォーマットに従わなければならないメッセージ、で指定する必要があります。
When a message arrives at the Delivery Point, the system verifies:
メッセージが配信ポイントに到着すると、システムが検証します。
o message type
Oメッセージの種類
o whether or not a PEC notification has to be returned.
PEC通知が返されることがあるかどうか、O。
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異常封筒、PEC通知）において、送達PEC通知が発行されていません。かかわらず、配達の時点で受信したメッセージは変わらず、受信者のメールボックスに配信されなければなりません。
This notification tells the user that his/her message has been successfully delivered to the specified recipient. It includes readable text that certifies the date and time of delivery, sender and receiver data, and the subject. It also contains an XML certification data file and other optional parts for functionalities offered by the provider.
この通知は、彼/彼女のメッセージが正常に指定した受信者に配信されたことをユーザに通知します。これは、読み込み可能な配達の日時を証明するテキスト、送信者と受信者データ、および件名が含まれています。また、プロバイダによって提供される機能のためのXML認定データファイルや他のオプションパーツが含まれています。
The following fields are inserted in the header:
次のフィールドがヘッダに挿入されます。
X-Ricevuta: avvenuta-consegna Date: [delivery date] Subject: CONSEGNA: [original subject] From: posta-certificata@[mail domain] To: [original sender] X-Riferimento-Message-ID: [msgid]
X-受信：発生した配信日：[配送日]件名：配信：[元の件名]から：認定メール@ [電子メールドメイン]宛先：[差出人] X-リファレンス - メッセージ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トランスポート・エンベロープ内のヘッダフィールドは、このように送信者が元のメッセージの一次受信者から要求された配信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」（完了）場合、システムは「：」で受取人からの完全な送達PEC通知を必要とする分野、簡潔PEC通知一方フィールド：（セクション3.3.2.3）は、「CC」のものから必要とされます。そして「CC：」フィールド：主な受信者とカーボン・コピーのものとの区別は、「へ」の分析を通じて行われます。主受信者の代わりに送信PEC通知の場合、すべての添付ファイルと一緒に元のメッセージの完全なコピーが通知に挿入されています。場合配達担当システム「とは：」における曖昧性の問題に起因する受信者のタイプを決定することができず、「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]
送達PECの[時間]で[日]（[時間帯]）、メッセージ「[件名」由来する「[元の送信者]」の通知とは、「[受信者]を」先のメールボックスに入れた宛て。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
The same certification data is inserted in an XML file and added to the notification (section 4.4), along with any other parts that MAY be inserted by the provider for provider-specific services. Parsing MUST be done on the XML part only. The delivery PEC notification MUST be issued on behalf of every recipient of the message, and MUST follow the format described in section 4.3.
同じ認証データはXMLファイルに挿入し、プロバイダ固有のサービスのプロバイダによって挿入され得る任意の他の部分と一緒に、通知（セクション4.4）に添加します。解析はXMLの一部で行われなければなりません。配信PEC通知は、メッセージのすべての受信者に代わって発行されなければならない、とセクション4.3で説明したフォーマットに従わなければなりません。
In order to decrease the amount of data flowing, it is possible for the sender to ask for a delivery PEC notification in "brief" format. The brief delivery PEC notification contains the original message and a ciphered hash value for each of its parts. The hash value SHOULD be calculated on base64 encoded parts. As specified in section 5.3, PEC messages MUST transit only on machines that belong to the PEC network and that MUST NOT alter the encoding of the message during its transition/processing.
送信者が「簡単」形式で配信PEC通知を依頼するために流れるデータ量を減少させるためには、それが可能です。簡単配信PEC通知は、元のメッセージとその部品のそれぞれについて暗号化ハッシュ値を含みます。ハッシュ値は、base64エンコードされた部分に計算されるべきです。セクション5.3で指定されるように、PECのみのネットワークに属し、それは、そのトランジション/処理中メッセージのエンコードを変更してはなりませんマシン上PECメッセージMUSTトランジット。
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の相互運用性テストは、すべての問題を明らかにしたことがありません。これはおそらく、彼らは変更を適用せずにそのまま受け取るメッセージを残すことの方がより傾いサーバを郵送する予定です。サーバーは、エンコードされた部分を修正することを決定した場合でも、問題が発生する可能性があります。例えば、そのハッシュ値は、受信機の端部で算出され、次いで送信者側とは異なるであろうBASE64の行の長さを、変更します。
To be able to verify the transmitted contents it is necessary for the sender to keep the unaltered original copy of the part(s) to which the hash values refer.
送信者は、ハッシュ値が参照した部分（S）の変更されていない元のコピーを保持することが必要である送信内容を確認することができるように。
If the PEC transport envelope contains the header:
PEC輸送エンベロープはヘッダが含まれている場合：
X-TipoRicevuta: breve
X-TipoRicevuta：ショート
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通知、およびカーボンコピーの受取人に代わって、簡潔な1（セクション3.3.2.3）を発します。 PECトランスポート・エンベロープ内のヘッダフィールドの値は、元のメッセージから導出されます。
The notification body contains a readable text part according to a model that relates the following certification data:
通知本体は、次の認証データを関連付けるモデルに応じて読みやすいテキスト部分が含まれています。
Brief delivery PEC notification On [date] at [time] ([time zone]), the message "[subject]" originating from "[original sender]" and addressed to "[recipient]" was placed in the destination's mailbox. Message identifier: [PEC msgid of corresponding PEC transport envelope]
[時間]（[時間帯]）で[日付]の簡単な送達PEC通知、メッセージ「[件名]」「[元の送信者]」から発信し、「[受信者が」送信先のメールボックスに入れた宛て。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
The same certification data is inserted in an XML file and added to the notification (section 4.4), along with other parts that MAY be included for specific provider-supplied services. Parsing MUST be done on the XML part only. The delivery PEC notification is issued on behalf of every recipient of the message, and MUST follow the format described in section 4.3.
同じ認証データはXMLファイルに挿入し、特定のプロバイダが提供するサービスのために含まれ得る他の部品と一緒に、通知（セクション4.4）に添加します。解析はXMLの一部で行われなければなりません。配信PEC通知は、メッセージのすべての受信者に代わって発行され、そして4.3節で説明したフォーマットに従わなければなりません。
The MIME structure of the original message is unaltered as it is added to the notification, but each MIME part with a "name" parameter in the header field "Content-Type:" or a "filename" parameter in the header field "Content-Disposition:" MUST be substituted by a text file containing that MIME part's hash value.
ヘッダフィールド「のContentまたは「ファイル名」パラメータ：ヘッダフィールド「コンテンツタイプ」の「名前」パラメータを使用して元のメッセージのMIME構造それが通知に追加されるように変更されないが、各MIMEパート処分は：」そのMIMEパートのハッシュ値を含むテキストファイルで置換されていなければなりません。
When the original message has an S/MIME format, it is necessary not to alter the integrity of the message structure. Verification of the S/MIME part in the original message takes place when the MIME type of the top-level entity (which coincides with the message itself) is checked. An S/MIME message MAY have the following MIME types (as per [SMIMEV3]):
元のメッセージは、S / MIME形式を有する場合には、メッセージ構造の完全性を変化させない必要があります。 （メッセージ自体と一致する）最上位エンティティのMIMEタイプが確認されたときに、元のメッセージ内のS / MIMEパートの検証が行われます。 S / MIMEメッセージは、（[SMIMEV3]の通り）は、以下のMIMEタイプを有することができます。
o multipart/signed
Oマルチパート/署名
Represents an original message signed by the sender using the structure described in [MIME-SECURE]. The message is made up of two MIME parts: the first is the message itself before the application of the sender's signature, whereas the second contains signature data. The second part (generally of type "application/pkcs7-signature" or "application/x-pkcs-signature") contains data added during the signing phase and MUST be left unchanged to avoid compromising the overall message structure;
[MIME-SECURE]に記載された構造を使用して送信者によって署名された元のメッセージを表しています。メッセージは、次の2つのMIMEパートで構成されている：第二の署名データが含まれているのに対し、最初は、送信者の署名を適用する前に、メッセージ自体です。第二の部分（一般タイプの「アプリケーション/ PKCS7署名」または「アプリケーション/ X-PKCS署名」）は、署名段階の間に追加されたデータが含まれており、全体的なメッセージ構造を損なうことを回避するために不変のままにしなければなりません。
o "application/pkcs7-mime" or "application/x-pkcs7-mime"
O "アプリケーション/ PKCS7-MIME" または "アプリケーション/ X-PKCS7-MIME"
The message is composed of a sole CMS object within the MIME part. Given that attachments cannot be separated from the CMS object, the MIME part is left intact (i.e., it is not replaced by the hash value); therefore, the brief PEC notification is the same as the complete PEC notification.
メッセージはMIMEパート内で唯一のCMSのオブジェクトで構成されています。添付ファイルがCMSオブジェクトから分離することができないことを考えると、MIME部分は（すなわち、それはハッシュ値で置換されていない）は、無傷のままです。そのため、簡単なPEC通知は、完全なPEC通知と同じです。
If the original message contains parts whose "Content-Type:" is "message/rfc822", i.e., contains an email message as attachment, the entire attached message is substituted with its corresponding hash value.
元のメッセージは、その部品が含まれている場合、「コンテンツタイプ：」、「メッセージ/ RFC822」、すなわち、添付ファイルとして電子メールメッセージを含む、全体の添付されたメッセージは、対応するハッシュ値で置換されています。
Therefore, when emitting a brief delivery PEC notification, the provider MUST:
したがって、簡単な送達PEC通知を発する場合、プロバイダ必要があります。
1. identify and extract all the parts from the first MIME part of the multipart/signed S/MIME message;
1.識別し、マルチパート/署名されたS / MIMEメッセージの最初のMIME部分からすべての部分を抽出します。
2. calculate the hash values of all the files attached by the sender to the original message;
2.元のメッセージに送信者によって接続されているすべてのファイルのハッシュ値を計算します。
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.
元のメッセージは、「アプリケーション/ PKCS7-MIME」または「アプリケーション/ X-PKCS7-MIME」MIMEタイプが含まれている場合は、O、メッセージ内に存在する添付ファイルが原因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：合成
the Delivery Point emits, both to primary and carbon copy recipients, a concise delivery PEC notification that does not contain the original message.
配達ポイントは、プライマリおよびカーボンコピーの受信者、元のメッセージが含まれていない簡潔な配信PEC通知に、放出します。
The message body of the notification contains a readable text part according to a model that relates the following certification data:
通知のメッセージボディには、以下の認証データを関連づけるモデルに従って読み取り可能なテキスト部分が含まれています。
Concise delivery PEC notification On [date] at [time] ([time zone]), the message "[subject]" originating from "[original sender]" and addressed to "[recipient]" was placed in the destination's mailbox. Message identifier: [PEC msgid of corresponding PEC transport envelope]
[時間]（[時間帯]）で[日付]で簡潔な送達PEC通知、メッセージ「[件名]」「[元の送信者]」から発信し、「[受信者が」送信先のメールボックスに入れた宛て。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
The same certification data is inserted within an XML file and added to the notification (section 4.4), along with additional parts that MAY be included for provider-specific services. Parsing MUST be done on the XML part only. The notification is sent to each one of the recipients to whom the message is delivered, and MUST follow the format described in section 4.3.
同じ認証データはXMLファイル内に挿入され、プロバイダ固有のサービスのために含まれ得るさらなる部品とともに、通知（セクション4.4）に添加します。解析はXMLの一部で行われなければなりません。通知は、メッセージが配信されている人に受信者の各々に送られ、セクション4.3で記述されたフォーマットに従わなければなりません。
The concise delivery PEC notification follows the same emission rules as the delivery PEC notification; added to it is only the XML file containing the certification data, not the original message.
簡潔送達PEC通知が配信PEC通知として同じ発光規則に従います。認証データを含むXMLファイルのみではなく、元のメッセージであることを追加しました。
If an error occurs during the delivery of a correct PEC transport message, the system returns to the sender a non-delivery PEC notification that indicates the error condition.
エラーが正しいPEC輸送メッセージの配信中に発生した場合、システムは、送信者にエラー状態を示す配信不能PEC通知を返します。
The header will contain the following fields:
ヘッダーには、次のフィールドが含まれます：
X-Ricevuta: errore-consegna Date: [date of notification emission] Subject: AVVISO DI MANCATA CONSEGNA: [original subject] From: posta-certificata@[mail domain] To: [original sender] X-Riferimento-Message-ID: [msgid]
X-受信：エラー配信日：[通知エミッションの日付]件名：配信の失敗の通知：[元の件名]から：認定メール@ [電子メールドメイン]宛先：[差出人] X-リファレンス - メッセージID： [MSGID]
The notification body contains a readable text part according to a model that relates the following data:
通知体は、以下のデータを関連付けるモデルに従って読み取り可能なテキスト部分が含まれています。
Non-delivery PEC notification On [date] at [time] ([time zone]), in the message "[subject]" originating from "[original sender]" and addressed to "[recipient]" an error was detected [brief error description]. The message was refused by the system. Message identifier: [PEC msgid of corresponding PEC transport envelope]
以下からのメッセージで[時間]で[日]（[時間帯]）、「[被験者]」発信「[元の送信者」上の非デリバリーPEC通知とは、「[受信者]」エラーが検出された宛[短いですエラーの説明]。メッセージはシステムによって拒否されました。メッセージ識別子：[対応PECトランスポート・エンベロープのPECのMSGID]
The same certification data is inserted within an XML file and added to the notification in order to allow for automatic checks (section 4.4). Parsing MUST be done on the XML part only. Additional parts MAY be included by the PEC provider for provider-specific services. The notification MUST follow the format described in section 4.3.
同じ認証データはXMLファイル内に挿入し、自動チェック（セクション4.4）を可能にするために、通知に追加されます。解析はXMLの一部で行われなければなりません。追加の部品は、プロバイダ固有のサービスのためのPECプロバイダによって含まれるかもしれません。通知は、セクション4.3で説明したフォーマットに従わなければなりません。
PEC messages MUST be processed even if both sender and receiver(s) belong to the same PEC domain.
PECメッセージは送信者と受信者（複数可）の両方が同じPECドメインに属している場合でも処理しなければなりません。
A correct transaction between two PEC domains goes through the following steps:
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
日付fullyear = 4桁の日付ヶ月= 2DIGIT。 01-12日付MDAY = 2DIGIT。 1月28日、1月29日、1月30日、1月31日に基づきます。月/年の時間時間= 2DIGIT。 00-23時間分= 2DIGIT。 00-59時間、秒= 2DIGIT。うるう秒に基づいて00から58、00-59、00-60。ルール
time-offset = "(" ("+" / "-") time-hour ":" time-minute ")"
時間オフセット=「（」（「+」/「 - 」）時間時間「：」時間分「）」
partial-time = time-hour ":" time-minute ":" time-second
部分的-時間=時間時間「：」時間分「：」時間秒
full-date = date-mday "/" date-month "/" date-fullyear full-time = partial-time time-offset
フル日付=日付の日「/」日付・月「/」日付通年フルタイム=パーシャル時の時間オフセット
NOTE: For number of days in a month, leap year, and leap second restrictions see section 5.7 of [TIMESTAMP].
注：月の日数、うるう年、および第二の制限を飛躍は[TIMESTAMP]のセクション5.7を参照してください。
This section describes the characteristics of the various components of PEC messages and notifications generated by a PEC system. If one of the message parts contains characters with values outside of the range 0-127 (7-bit ASCII), that part will have to be adequately encoded so that 7-bit transportation compatibility is guaranteed (e.g., quoted-printable, base64 as per [MIME1]).
このセクションでは、PECシステムによって生成されたPECメッセージおよび通知の様々な構成要素の特性を記述する。メッセージ部分のいずれかが範囲0〜127（7ビットASCII）外の値を持つ文字が含まれている場合、その部分は、として、例えば、引用符で囲まれた印刷可能な、BASE64（7ビット輸送互換性が保証されるように適切に符号化されなければなりません[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.
署名を適用する前に、メッセージ本体は、コンテンツタイプを有する：混合/マルチ。各部分は、以下のセクションで説明されています。第二および第三の部分を順に交換可能であり、元のメッセージと認証データのXMLファイルを含むながら、最初の部分は、PECシステムによって生成されたユーザ可読テキストです。
Character set: ISO-8859-1 (Latin-1) MIME type: text/plain or multipart/alternative
文字セット：ISO-8859-1（Latin-1の）MIMEタイプ：text / plainのか、マルチパート/代替
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つのサブ部分が存在しなければならない：タイプtext / plainでの、他のテキスト/ 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タイプ：application / 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
<！ - ルートとして要素「postacert」を使用 - > <！ - 「タイプは」PECメッセージの類型を示します - > <！ - 属性「エラー」は、以下の値を持つことができます - > < ！ - "いいえ" =エラーなし - > <！ - "ノー-DEST"（タイプ= "エラー・デリバリー" で）= - > <！ - 間違った受信者 - > <！ - 「なし-dominio "（エラー配信タイプ=と" "）= - > <！ - 間違ったドメイン - > <！ - " - > <=ウイルス "（「エラー・デリバリータイプ=と"）ウイルス！ - "ウイルス" ウイルス（タイプ= "非受理" 付き）= - > <！ - "その他" の一般的なエラー= - ！> <！ELEMENTのpostacert（ヘッダ、データ）> <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">
<!--Header of the original message--> <!ELEMENT intestazione (mittente, destinatari+, risposte, oggetto?)>
<！ - 元のメッセージのヘッダー - > <！ELEMENTヘッダ（？送信者、受信者+、回答、対象）>
<!--Sender ("From:" field) of the original message--> <!ELEMENT mittente (#PCDATA)>
< - 送信者（の "From：" フィールド）！オリジナルのメッセージの - > <！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">
<！ - 完全な受信者のリスト（ "へ：" と "CC：" フィールド） - > <！ - 元のメッセージのは、 - > <！ - "TIPOは、" 受信者の類型を示し、 - > <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)>
<！ - "返信先：" の値元のメッセージのフィールド - > <！ELEMENTのrisposte（#PCDATA）> <！ - "件名：" の値元のメッセージのフィールド - > < ！ELEMENTのoggetto（#PCDATA）>
<!--PEC message data--> <!ELEMENT dati (gestore-emittente, data, identificativo, msgid?, ricevuta?, consegna?, ricezione*, errore-esteso?)>
<！ - PECメッセージ所与 - > <！ELEMENTデータ（？？？？オペレータ発行者、日付、識別、MSGID、受信、配信、受信*、拡張エラー）>
<!--Descriptive string of the provider that certifies --> <!--the data--> <!ELEMENT gestore-emittente (#PCDATA)>
<！ - 証明プロバイダの説明文字列 - > <！ - データ - > <！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>
< - "透明帯" の現地時間とUTCとの間の差である - > <！ - - メッセージの精緻化の日付/時間！>は、<！ - "[+ | - ] HHMM" 形式 - > <！ ELEMENTデータ（GIORNO、ORA）> <！ATTLISTデータゾナCDATA #REQUIRED>
<!--Day in "dd/mm/yyyy" format--> <!ELEMENT giorno (#PCDATA)> <!--Local hour in "hh:mm:ss" format--> <!ELEMENT ora (#PCDATA)>
< - "DD / MM / YYYY" 形式でデイ - > <！ELEMENTのGIORNO（#PCDATA）> <！ - "hh：mm：ss" の中に現地時間！フォーマット - > <！ELEMENT ORA（＃ PCDATA）>
<!--PEC msgid--> <!ELEMENT identificativo (#PCDATA)>
<！ - PEC MSGID - > <！ELEMENT識別子（#PCDATA）>
<!--msgid of the original message before modifications--> <!ELEMENT msgid (#PCDATA)>
<！ - 修正前の元のメッセージのMSGID - > <！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>
<！ - PEC輸送封筒と配信通知の場合 - > <！ - 送信者 - > <！ELEMENT ricevuta EMPTY> <！ATTLIST ricevuta TIPO（<！ - - によって要求されたPEC通知の種類を示している>をcompleta |ブレーベ| 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)>
<！ - 配信、不着、ウイルス誘導性非配信については、 - > <！ - ウイルス検出、およびタイムアウトPEC通知 - > <！ - 配信が行われているために受信者のアドレス - > <！ - アウト/試してみました - > <！ELEMENTのconsegna（#PCDATA）> <！ - サーバー - サーバーの受け入れPECの通知の場合 - > <！ - それは相対的なPEC通知である誰のための受信者 - > < ！ELEMENTのricezione（#PCDATA）>
<!--In case of error--> <!--brief description of the error--> <!ELEMENT errore-esteso (#PCDATA)>
<！ - エラーの場合 - > <！ - エラーの簡単な説明 - > <！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
- providerNameで：プロバイダ名
- mailReceipt: provider reception email address
- mailReceipt：プロバイダの受信メールアドレス
- managedDomains: managed domains
- managedDomains：管理対象ドメイン
- LDIFLocationURL: provider LDIF record URL
- LDIFLocationURL：プロバイダのLDIFレコードURL
- providerUnit: secondary operating environment name
- providerUnit：二次オペレーティング環境名
The directory's base root is "o=postacert" and the "DistinguishedName" of single records is of the type "<providerName=<name>,o=postacert>". Search within the directory is carried out mainly in case-sensitive mode using the "providerCertificateHash" attribute (during envelope signature verification phase) or the "managedDomains" attribute (during message acceptance phase). It is possible for the record of a single provider to contain multiple "providerCertificate" attributes with the related "providerCertificateHash" attributes in order to allow the handling of the renewal of expiring certificates. The provider MUST make sure to update its record with sufficient advance before the certificate expiration date, by adding a new certificate whose validity overlaps that of the previous one.
ディレクトリの基本ルートは、「<providerNameで= <名前>、O = postacert>」「O = postacert」とシングルレコードの「識別名は」型であるです。ディレクトリ内の検索は、（エンベロープ署名検証フェーズ中に）「providerCertificateHash」属性または（メッセージ受付段階中）「managedDomains」属性を使用して、大文字と小文字が区別モードで主に行われます。単一のプロバイダのレコードが複数の「providerCertificate」を含んで期限切れの証明書の更新の取り扱いを可能にするために属性関連「providerCertificateHash」を持つ属性することが可能です。プロバイダは、その妥当性以前のもののように重なって新しい証明書を追加することにより、証明書の有効期限の前に十分な事前とのレコードを更新することを確認しなければなりません。
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プロバイダのデータは[HTTPS]オブジェクトとして利用可能であり、URLで見つけることができる[LDIF]ファイルに包含されている「DN：O = postacert」における「LDIFLocationURL」属性レコードポイント（ ）のセクション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]ファイルを介して、単一のプロバイダは、すべてのメッセージの推敲フェーズのために中央システムに連続要求ディスパッチを回避することにより、システム性能を向上させるためには、毎日のように更新され、ローカルディレクトリのコピーを保持しなければなりません。
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 )
（ '16進形式のX.509証明書のハッシュSHA1' 1.3.6.1.4.1.16572.2.2.1 NAME 'providerCertificateHash' DESC平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）
The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in [LDAP-SYNTAXES].
IA5String（1.3.6.1.4.1.1466.115.121.1.26）構文は[LDAP-構文]で定義されています。
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 NAME 'providerCertificate' DESC 'ASN.1 DERバイナリ形式のX.509証明書' SYNTAX 1.3.6.1.4.1.1466.115.121.1.8）
The Certificate syntax ( 1.3.6.1.4.1.1466.115.121.1.8 ) is defined in [RFC4523].
証明書構文（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と、バイナリ」[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 NAME 'providerNameで' DESC 'PECプロバイダ名' 平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15単一値）
The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is defined in [LDAP-SYNTAXES].
ディレクトリ文字列（1.3.6.1.4.1.1466.115.121.1.15）構文は、[LDAP-構文]で定義されています。
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スペック構築物の限定されたバージョンです。それは、「@」の左右両側にドット原子テキスト形式を許可し、内部のCFWSを持っていないだけ。
( 1.3.6.1.4.1.16572.2.2.4 NAME 'mailReceipt' DESC 'E-mail address of the service mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
（1.3.6.1.4.1.16572.2.2.4 NAME 'mailReceipt' DESC 'サービスメールボックスのE-mailアドレス' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE）
The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in [LDAP-SYNTAXES].
IA5String（1.3.6.1.4.1.1466.115.121.1.26）構文は[LDAP-構文]で定義されています。
The 'managedDomains' attribute holds a set of domains [SMTP] that are handled by a PEC provider. Domains are limited to dot-atom form ([RFC1034], [EMAIL]).
「managedDomains」属性は、PECプロバイダによって処理されるドメイン[SMTP]のセットを保持します。ドメインは、ドット原子フォーム（[RFC1034]、[EMAIL]）に制限されています。
( 1.3.6.1.4.1.16572.2.2.5 NAME 'managedDomains' DESC 'Domains handled by the PEC provider' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（1.3.6.1.4.1.16572.2.2.5 NAME 'managedDomains' DESC 'PECプロバイダによって扱わドメイン' 平等caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）
The IA5String ( 1.3.6.1.4.1.1466.115.121.26 ) syntax is defined in [LDAP-SYNTAXES].
IA5String（1.3.6.1.4.1.1466.115.121.26）構文は[LDAP-構文]で定義されています。
The 'managedDomains' attribute holds a set of domains [SMTP] that are handled by a PEC provider. Domains are limited to dot-atom form ([RFC1034], [EMAIL]).
「managedDomains」属性は、PECプロバイダによって処理されるドメイン[SMTP]のセットを保持します。ドメインは、ドット原子フォーム（[RFC1034]、[EMAIL]）に制限されています。
The 'LDIFLocationURL' attribute contains an [HTTPS] URL that points to the location of the [LDIF] file defining the provider's record. When the attribute is present in the record "dn: o=postacert", then it contains the definition of the entire directory in [LDIF] format. The LDIF file will have a MIME type of application/pkcs7-mime, with the parameter smime-type/signed-data. [SMIMEV3] The LDIF file is encoded using the UTF-8 character set.
「LDIFLocationURL」属性は、プロバイダのレコードを定義する[LDIF]ファイルの場所を指す[HTTPS] URLが含まれています。 「DN：= postacert o」の属性がレコード中に存在する場合、それは[LDIF]形式でディレクトリ全体の定義が含まれています。 LDIFファイルには、パラメータSMIME型/署名データと、アプリケーション/ 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.
二次環境レコードは、プロバイダに接続されているすべてのレコードの主な環境の属性から取得された「LDIFLocationURL」属性を含めることはできません。
( 1.3.6.1.4.1.16572.2.2.6 NAME 'LDIFLocationURL' DESC 'URL of the LDIF file that defines the entry' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.4.1.16572.2.2.6 NAME「LDIFLocationURL」DESC「エントリを定義するLDIFファイルのURL」平等CaseExactMatchの構文1.3.6.1.4.1.1466.115.121.1.15単一値）
The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is defined in [LDAP-SYNTAXES].
ディレクトリ文字列（1.3.6.1.4.1.1466.115.121.1.15）構文は、[LDAP-構文]で定義されています。
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.
二次オペレーティング環境に対するレコードの「識別名は、」タイプである「<providerUnits = <環境>、providerNameで= <名前>、O = postacert>」。すべてのプロバイダは、レコード内の「providerUnit」属性と識別名の不在のために区別できる独自のメイン環境に関連するレコードを、持っていなければなりません。
( 1.3.6.1.4.1.16572.2.2.7 NAME 'providerUnit' DESC 'Name of the secondary operative environment' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15単一値1.3.6.1.4.1.16572.2.2.7 NAME 'providerUnit' DESC '二次動作環境の名前'）
The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is defined in [LDAP-SYNTAXES].
ディレクトリ文字列（1.3.6.1.4.1.1466.115.121.1.15）構文は、[LDAP-構文]で定義されています。
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トップ補助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 'プロバイダ' SUPトップSTRUCTURAL MUST（providerCertificateHash providerCertificate providerNameでmailReceipt managedDomains）
MAY ( description LDIFLocationURL providerUnit )
MAY（説明LDIF場所のURLプロバイダ・ユニット）
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つの自己署名証明書です。
dn: o=postacert
objectclass: top
objectclass: organization
objectClass: LDIFLocationURLObject
o: postacert
LDIFLocationURL: https://igpec.rupa.example.com/igpec.ldif.p7m
description: Base root for the PEC providers directory
dn: providerName=Anonymous Certified Mail S.p.A.,o=postacert
objectclass: top
objectclass: provider
providerName: Anonymous Certified Mail S.p.A.
providerCertificateHash:
7E7AEF1059AE0F454F2643A95F69EC3556009239
providerCertificate;binary::
MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9 5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw== mailReceipt: ssacceptance@postalser.example.com LDIFLocationURL: https://anpocert.example.com/anpocert.ldif.p7m managedDomains: mail.anpocert.example.com managedDomains: cert.company.example.com managedDomains: costmec.example.com description: Certified mail services for companies
MIIDBjCCAm + gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J + QK KdxV9LzDMPqwnEy0P8H / KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf alZelqrwqmElna4MNUaLhbOvTd / sqPUS378w5IaIhWxzy34XcCAwEAAaOB wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ / aBzsaGvRZMwgZAGA1UdIw SBiDCBhYAUN8lC0znQWEs0xspZ / aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl cnQuaXSCAQAwDAYDVR0TBAUwAwEB / zANBgkqhkiG9w0BAQQFAAOBgQA58B Z + q1qSKpuffzTBpMtbeFkDIxMqMa + ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76Jz Z9 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 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
DN：providerNameで=郵便サービススパ、O = postacertオブジェクトクラス：トップオブジェクトクラス：プロバイダproviderNameで：郵便サービス鉱泉providerCertificateHash：e00fdd9d88be0e2cc766b893315caf93d5701a6a providerCertificate、バイナリ:: MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEw JJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA0GA1UE CxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YU BzZXJwb3N0YWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjA5MTczMjE2 WjBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIF Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0 YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQ ADgY0AMIGJAoGBAKoc7n6zA + sO8NATMcfJ + U2aoDEsrj / cObG3QAN6Sr + L ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIEaYZhYRGjhbcuJ9H / ZdtWdX xcwEWN4mwFzlsASogsh5JeqS8db3A1JWkvhO9EUfaCYk8YMAkXYdCtLD9s 9tCYZeTE2ut9AgMBAAGjgcswgcgwHQYDVR0OBBYEFHPw7VJIoIM3VYhuHa eAwpPF5leMMIGYBgNVHSMEgZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leM oXKkcDBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YW xpIFMuci5sLj EPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5w 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説明：公共のための認定メールサービス
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で=匿名証明郵便S.p.A.、O = postacertオブジェクトクラス：トップオブジェクトクラス：プロバイダproviderNameで：匿名証明郵便S.p.A.
providerCertificateHash: 7E7AEF1059AE0F454F2643A95F69EC3556009239 providerCertificate;binary:: MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
providerCertificateHash：7E7AEF1059AE0F454F2643A95F69EC3556009239 providerCertificate、バイナリ:: MIIDBjCCAm + gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J + QK KdxV9LzDMPqwnEy0P8H / KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf alZelqrwqmElna4MNUaLhbOvTd / sqPUS378w5IaIhWxzy34XcCAwEAAaOB wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ / aBzsaGvRZMwgZAGA1UdIw SBiDCBhYAUN8lC0znQWEs0xspZ / aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl cnQuaXSCAQAwDAYDVR0TBAUwAwEB / zANBgkqhkiG9w0BAQQFAAOBgQA58B Z + q1qSKpuffzTBpMtbeF kDIxMqMa + ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw== mailReceipt: notifications@anpocert.it.example LDIFLocationURL: http://anpocert.example.com/anpocert.ldif.p7m managedDomains: mail.anpocert.example.com managedDomains: cert.company.example.com managedDomains: costmec.example.com description: Certified mail services for companies dn: providerUnit=Secondary Environment, providerName=Anonymous Certified Mail S.p.A.,o=postacert objectclass: top objectclass: provider providerName: Certified Mail S.p.A. providerUnit: Secondary Environment providerCertificateHash: 7E7AEF1059AE0F454F2643A95F69EC3556009239 providerCertificate;binary:: MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9 5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw== mailReceipt: notifications@secondary.anpocert.example.com managedDomains: management.anpocert.example.com managedDomains: personnel.anpocert.example.com description: Corporate internal services dn: providerName=Postal Services S.r.l.,o=postacert objectclass: top objectclass: provider providerName: Postal Services S.r.l. providerCertificateHash: e00fdd9d88be0e2cc766b893315caf93d5701a6a providerCertificate;binary:: MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEw JJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA0GA1UE CxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YU
5Z / 1OCFNhLfqf1VH2NSS8TaYCCi / VO7W1Q1KkcA2VlxlQP7McSUw == mailReceipt：LDIFLocationURL notifications@anpocert.it.example：http://anpocert.example.com/anpocert.ldif.p7m managedDomains：mail.anpocert.example.com managedDomains：cert.company.example。 COM managedDomains：costmec.example.com説明：企業のdnの認定メールサービス：providerUnit =セカンダリ環境、providerNameで=匿名証明郵便スパ、O = postacertオブジェクトクラス：トップオブジェクトクラス：プロバイダproviderNameで：認定メールの鉱泉providerUnit：セカンダリ環境providerCertificateHash：7E7AEF1059AE0F454F2643A95F69EC3556009239をproviderCertificate;バイナリ:: MIIDBjCCAm + gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh bnBvY2Vy dC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J + 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説明：企業の内部サービスのDN：providerNameで=郵便サービスSrlは、O = postacertオブジェクトクラス：トップオブジェクトクラス：プロバイダproviderNameで：ポスタLサービスS.r.l. providerCertificateHash：e00fdd9d88be0e2cc766b893315caf93d5701a6a providerCertificate;バイナリ:: 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
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 .exam ple.com/ldif.txt.p7m managedDomains：postal-services.example.com managedDomains：receivedmail.example.com説明：公共のための認定メールサービス
It is recommended that a dedicated hardware module be used to handle private key and signature operations, the specifications of which are outside the scope of this document. It's up to the PEC providers to conform to security requisites expected for the service.
この文書の範囲外にある仕様そのうち、専用のハードウェアモジュールは、秘密鍵と署名操作を処理するために使用することをお勧めします。これは、サービスのために期待されるセキュリティ要件に準拠するようにPECプロバイダ次第です。
User access to PEC services through the Access Point MUST be allowed only upon successful user authentication on the system.
アクセスポイント経由PECサービスへのユーザーアクセスは、システム上のユーザ認証成功時に許可する必要があります。
For example, authentication might use user-ID and password, or, if available and considered necessary for the type of service provided, an electronic ID card or the national services card. Choice of authentication method is left to the better judgment of the service provider. Authentication is necessary to guarantee as much as possible that the message is sent by a PEC user whose identification data is congruent with the specified sender, so as to avoid falsification of the latter.
利用できると、電子IDカードや国民サービスカードを提供するサービスの種類のために必要と考えられる場合たとえば、認証は、ユーザーIDとパスワードを使用するか、または可能性があります。認証方法の選択は、サービスプロバイダのより良い判断に任されています。認証が可能な限りメッセージは、その識別データ後者の改ざんを回避するように、指定された送信者と合同であり、PECのユーザによって送信されることを保証する必要があります。
To guarantee that the original message remains unaltered during transaction, envelopment and signature are applied on outgoing messages at the Access Point, and subsequent verification of incoming messages is done at the Incoming Point.
元のメッセージがトランザクション中に変更されないままであることを保証するために、包囲及び署名は、アクセスポイントの送信メッセージに適用され、受信メッセージのその後の検証は着信ポイントで行われます。
All communications within the PEC network MUST use secure channels. Integrity and confidentiality of connections between PEC provider and user MUST be guaranteed through the use of secure protocols, such as those based on [TLS] and those that create a secure transport channel on which non-secure protocols can transmit (e.g., IPsec).
PECネットワーク内のすべての通信は、安全なチャネルを使用しなければなりません。 PECプロバイダとユーザとの間の接続の完全性と機密性は、[TLS]に基づくものと非セキュアなプロトコル（例えば、IPsec）を送信することができる上に、安全なトランスポートチャネルを作成するものなどのセキュアプロトコルを使用することによって保証されなければなりません。
The interaction between providers MUST take place using SMTP on [TLS], as per [SMTP-TLS]. The Incoming Point MUST provide and announce its support for the STARTTLS extension, as well as accept both unencrypted connections (for ordinary mail) and protected ones. To guarantee complete traceability in the flow of PEC messages, these MUST NOT transit on systems external to the PEC network. When exchanging messages between different providers, all transactions MUST take place between machines that belong to the PEC network or are directly managed by the provider. An "MX" type record MAY be associated to each PEC domain defined within the system for name resolution, in which case secondary reception systems specified in that record MUST be under direct control of the provider. All in conformance with [SMTP].
プロバイダー間の相互作用は、[SMTP-TLS]に従って、[TLS]にSMTPを使用して行われなければなりません。着信ポイントは提供し、STARTTLS拡張のサポートを発表するだけでなく、両方（普通郵便のための）暗号化されていない接続および保護されたものを受け入れなければなりません。 PECメッセージの流れの中で完全なトレーサビリティを保証するために、これらは、PECネットワークの外部のシステムでのトランジットはいけません。異なるプロバイダ間でメッセージを交換するときは、すべてのトランザクションは、PECのネットワークに属しているか、直接プロバイダによって管理されているマシン間で行われなければなりません。 「MX」タイプのレコードは、そのレコードに指定された第二の受信システムは、提供者の直接の制御下にある必要があり、その場合、名前解決のためにシステム内で定義された各PECドメインに関連付けることができます。全ての[SMTP]に準拠インチ
Another important security aspect that concerns the PEC system, is related to the technical and functional architecture that MUST block the presence of viruses from endangering the security of all handled messages. It is therefore REQUIRED to have installations and continuous updates of anti-virus systems that hinder infections as much as possible without intervening on the content of the certified mail, in compliance with what has been discussed thus far.
PECシステムに関するもう一つの重要なセキュリティ面では、すべての処理されるメッセージのセキュリティを危険にさらすから、ウイルスの存在を阻止しなければならない技術的および機能アーキテクチャに関連しています。したがって、インストールや、これまで議論してきたものを遵守し、認定を受けたメールの内容に介入せずに、できるだけ多くの感染症を妨げるアンチウイルスシステムの継続的な更新が必要となります。
In this document the S/MIME certificate profile is defined for use in the certification of PEC messages done by the providers. The proposed profile of the S/MIME certificate is based on the IETF standards [SMIMECERT] and [CRL], which in turn are based on the standard ISO/IEC 9594-8:2001.
この文書では、S / MIME証明書プロファイルはプロバイダによって行わPECメッセージの認証で使用するために定義されています。 2001：S / MIME証明書の提案プロファイルが順番に標準ISO / IEC 9594から8に基づいているIETF標準規格[SMIMECERT]と[CRL]、に基づいています。
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）に挿入されなければなりません。より正確には、それはPECプロバイダーディレクトリ（セクション4.5）に発表された「providerNameで」属性であるようサブジェクトDNは、PECプロバイダの名前が含まれている必要がありますが、件名はDNは、LDIFでプロバイダエントリDNと一致する必要はありません。証明書のフィールド：ProviderNameは、「件名」ののCommonNameや組織名属性に存在しなければなりません。
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:
有効なsubjectDNは以下のとおりです。
C=IT, O=AcmePEC S.p.A, CN=Posta Certificata
C = GB、O = AcmePEC S.p.A.、CN =証明郵便
C=IT, O=ServiziPEC S.p.A, CN=Posta Certificata
C = GB、O = ServiziPEC S.p.A.、CN =証明郵便
Valorization of other attributes in the Subject DN, if present, MUST be done in compliance with [CRL].
サブジェクトDN内の他の属性のValorizationは、存在する場合、[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.
説明プロファイルのため、上記の拡張子のvalorizationは、以下の通りです。
The Key Usage extension (Object ID: 2.5.29.15) MUST have the digitalSignature bit (bit 0) activated and MUST be marked as critical. The extension MAY contain other active bits corresponding to different Key Usage, as long as that doesn't contrast with the indications in [CRL].
鍵用途拡張（オブジェクトID：2.5.29.15）は、デジタル署名のビット（ビット0）が活性化などの重要マークを付ける必要があります持っている必要があります。拡張があればそれは[CRL]における適応症と対比しないように、異なるキー使用法に対応する他のアクティブビットを含むかもしれません。
The Authority Key Identifier (Object ID: 2.5.29.35) MUST contain at least the keyIdentifier field and MUST NOT be marked as critical.
認証局キー識別子（オブジェクトID：2.5.29.35）少なくとも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）は、少なくともkeyIdentifierフィールドを含まなければならないし、などの重要なマークされてはなりません。
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
... d15ff128 6792def5 b3f884e6 54b326db CF EXPONENT：0x010001 EXTENSIONS：サブジェクト代替名：RFC名：posta-certificata@acmepec.itキー使用法*：デジタル署名認証局キー識別子：0x12345678のAAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDDサブジェクトキー識別子：0x3afae080 6453527a 3e5709d8 49a941a8 a3a70ae1 SIGNATURE：ALG。 ID：ID-SHA1-と-RSA暗号PARAMETER：0 VALUE：0x874b4d25 70a46180 c9770a85 fe7923ce b22d2955 2f3af207 142b2aba 643aaa61 ... d8fd10b4 c9e00ebc c089f7a3 549a1907 ff885220 ce796328 b0f8ecac 86ffb1cc
0 30 794: SEQUENCE { 4 30 514: SEQUENCE { 8 A0 3: [0] { 10 02 1: INTEGER 2 : } 13 02 2: INTEGER 11226 17 30 13: SEQUENCE { 19 06 9: OBJECT IDENTIFIER : sha1withRSAEncryption (1 2 840 113549 1 1 5) 30 05 0: NULL : } 32 30 101: SEQUENCE { 34 31 11: SET { 36 30 9: SEQUENCE { 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 43 13 2: PrintableString 'IT' : } : } 47 31 28: SET { 49 30 26: SEQUENCE { 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 56 13 19: PrintableString 'Certificatore 1' : } : } 77 31 22: SET {
0 30 794：SEQUENCE {4 30 514：SEQUENCE {8 A0 3：[0] {10 02 1：INTEGER 2：} 13 02 2：INTEGER 11226 17 30 13：SEQUENCE {19 06 9：オブジェクト識別子：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：オブジェクト識別子COUNTRYNAME（2 5 4 6）43 13 2：のprintablestring 'IT'：}} 47 31 28：SET {49 30 26：SEQUENCE {51 06 3：オブジェクト識別子organizationNameの（2 5 4 10）56 13 19はPrintableString 'Certificatore 1'：}} 77 31 22：SET {
79 30 20: SEQUENCE { 81 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 86 13 13: PrintableString 'Certification Service Provider' : } : } 101 31 32: SET { 103 30 30: SEQUENCE { 105 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 110 13 23: PrintableString 'Certificatore S.p.A.' : } : } : } 135 30 30: SEQUENCE { 137 17 13: UTCTime '041005090423Z' 152 17 13: UTCTime '051005090423Z' : } 167 30 66: SEQUENCE { 169 31 11: SET { 171 30 9: SEQUENCE { 173 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 178 13 2: PrintableString 'IT' : } : } 182 31 23: SET { 184 30 21: SEQUENCE { 186 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 191 13 14: PrintableString 'AcmePEC S.p.A.' : } : } 207 31 26: SET { 209 30 24: SEQUENCE { 211 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 216 13 17: PrintableString 'Posta Certificata' : } : } : } 235 30 159: SEQUENCE { 238 30 13: SEQUENCE { 240 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 251 05 0: NULL : } 253 03 141: BIT STRING 0 unused bits : 30 81 89 02 81 81 00 AF BE B4 55 63 19 8A AA 9B : AC 3F 1B 29 B5 BE 7F 69 19 45 89 D0 15 69 CA 0D : 55 5B 5C 33 D7 E9 C8 6E FC 14 46 C3 C3 09 47 DD : CD 10 74 1D 76 4E 71 14 E7 69 42 BE 1C 47 61 85 : 4D 74 76 DD 0B B5 78 4F 1E 84 DD B4 86 7F 96 DF
79 30 20：SEQUENCE {81 06 3：オブジェクト識別子organizationalUnitName（2 5 4 11）86 13 13はPrintableString '認証サービスプロバイダー'：}} 101 31 32：SET {103 30 30：SEQUENCE {105 06 3：OBJECT IDENTIFIER commonNameの（2 5 4 3）110 13 23はPrintableString 'Certificatore SpAの' ：}}} 135 30 30：SEQUENCE {137 17 13：UTC時刻 '041005090423Z' 152 17 13：UTC時刻 '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： 'IT' をのprintablestring：}} 182 31 23：SET {184 30 21：SEQUENCE {186 06 3：オブジェクト識別子organizationNameの（2 5 4 10）191 13 14：PrintableStringの 'AcmePEC SpAの' ：}} 207 31 26：SET {209 30 24：SEQUENCE {211 06 3：オブジェクト識別子のcommonName（2 5 4 3）216 13 17はPrintableString 'ポスタCertificata'：}}} 235 30 159：SEQUENCE { 238 30 13：SEQUENCE {240 06 9：オブジェクト識別子rsaEncryption（1 2 840 113549 1 1 1）251 05 0：NULL：} 253 03 141：ビット列0の未使用ビット：30 81 89 02 81 81 00 AFはB4 55 BE 63 19（a）のAAの9B：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 AC 3F 1B 29 B5は7F 69 19 45 89 D0 15 69カリフォルニア0D BE 42 1C 47 61 85 BE：4D 74 76 DD 0B B5 78 4F 1E 84 DDのB4 86 7F 96 DF
: 5E 7B AF 0E CE EA 12 57 0B DF 9B 63 67 4D F9 37 : B7 48 35 27 C2 89 F3 C3 54 66 F7 DA 6C BE 4F 5D : 85 55 07 A4 97 8C D1 5F F1 28 67 92 DE F5 B3 F8 : [ Another 12 bytes skipped ] : } 397 A3 123: [3] { 399 30 121: SEQUENCE { 401 30 39: SEQUENCE { 403 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 408 04 32: OCTET STRING : 30 1E 81 1C 70 6F 73 74 61 2D 63 65 72 74 69 66 : 69 63 61 74 61 40 61 63 6D 65 70 65 63 2E 69 74 : } 442 30 14: SEQUENCE { 444 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 449 01 1: BOOLEAN TRUE 452 04 4: OCTET STRING : 03 02 07 80 : } 458 30 31: SEQUENCE { 460 06 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 465 04 24: OCTET STRING : 30 16 11 11 11 11 AA AA AA AA AA BB BB BB BB CC CC : CC CC DD DD DD DD : } 491 30 29: SEQUENCE { 493 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 498 04 22: OCTET STRING : 04 14 3A FA E0 80 64 53 52 7A 3E 57 09 D8 49 A9 : 41 A8 A3 A7 0A E1 : } : } : } : } 522 30 13: SEQUENCE { 524 06 9: OBJECT IDENTIFIER : sha1withRSAEncryption (1 2 840 113549 1 1 5) 535 05 0: NULL : } 537 03 257: BIT STRING 0 unused bits : 87 4B 4D 25 70 A4 61 80 C9 77 0A 85 FE 79 23 CE : B2 2D 29 55 2F 3A F2 07 14 2B 2A BA 64 3A AA 61 : 1F F0 E7 3F C4 E6 13 E2 09 3D F0 E1 83 A0 C0 F2 : C6 71 7F 3A 1C 80 7F 15 B3 D6 1E 22 79 B8 AC 91 : 51 83 F2 3A 84 86 B6 07 2B 22 E8 01 52 2D A4 50 : 9F C6 42 D4 7C 38 B1 DD 88 CD FC E8 C3 12 C3 62 : 64 0F 16 BF 70 15 BC 01 16 78 30 2A DA FA F3 70 : E2 D3 0F 00 B0 FD 92 11 6C 55 45 48 F5 64 ED 98
：図5Eは、図7（b）AF 0E CE EA 12 57 0B DF 9B 63 67 4D F9 37：85 55 07 A4 97 8C D1 5F F1 28 67 92 DE F5 B3：B7 48 35 27 C2 89 F3 C3 54 66 F7 DA 6Cは4F 5D BE F8：[別の12のバイトをスキップ]：} 397 A3 123：[3] {399 30 121：SEQUENCE {401 30 39：SEQUENCE {403 06 3：オブジェクト識別子のsubjectAltName（2 5 29 17）408 04 32：オクテット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：オブジェクト識別子のkeyUsage（2 5 29 15）449 01 1：BOOLEAN TRUE 452 04 4オクテットSTRING：03 02 07 80：} 458 30 31：SEQUENCE {460 06 3：オブジェクト識別子authorityKeyIdentifier（2 5 29 35）465 04 24：オクテット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：オブジェクト識別子subjectKeyIdentifier（2 5 29 14）498 04 22：OCTET STRING ：04 14（a）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：オブジェクト識別子：SHA 1withRSAEncryption（1 2 840 113549 1 1 5）535 05 0：NULL：} 537 03 257：ビット列0の未使用ビット：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（b）（a）BA 64（a）の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（a）DA FA F3 70：E2 D3 0F 00 B0 FD 92 11（c）55 45 48 F5 64 ED 98
: [ Another 128 bytes skipped ]
: }
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.
必要なユーザー証明書を持っているライセンスのプロバイダによってのみ、[TLS]で説明したようにPECプロバイダディレクトリの内容は、セキュア・ソケット・レイヤー（SSL）で[HTTP]を経由して照会しなければなりません。このアクセスモダリティは信憑性、完全性、およびデータの機密性を保証しています。各プロバイダは、認証局によって発行されたX.509証明書を確認することで認証される[HTTPS]セッションを介して、LDIFファイルをダウンロードします。
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];
【MIME1]および[MIME5]に従ってMIME形式のOサポート。
o support for "ISO-8859-1 (Latin-1)" character set;
"ISO-8859-1（Latin-1の）" 文字セットのOサポート。
o support for S/MIME v3 standard, as in [SMIMEV3], for verification of signatures applied to PEC envelopes and notifications.
O S / MIME v3の標準のサポートは、[SMIMEV3]のように、署名の検証のためにPECエンベロープと通知に適用されます。
All security considerations from [CMS] and [SMIMEV3] apply to applications that use procedures described in this document.
[CMS]と[SMIMEV3]からすべてのセキュリティ上の考慮事項は、この文書に記載されている手順を使用するアプリケーションに適用されます。
The centralized LDAP server is a critical point for the security of the whole PEC system. An attack could compromise the whole PEC system. PEC providers that periodically download the LDIF file SHOULD use the best security technology to protect it from local attacks. A PEC provider could be compromised if an attacker changed a certificate or modified the list of domains associated to it in the LDIF file that was copied to the PEC provider system.
集中型のLDAPサーバは、全体PECシステムのセキュリティのための重要なポイントです。攻撃は全体PECシステムを危険にさらす可能性があります。定期的にLDIFファイルをダウンロードPECプロバイダは、ローカルの攻撃から保護するために最善のセキュリティ技術を使用すべきです。攻撃者は、証明書を変更またはPECプロバイダシステムにコピーされたLDIFファイルに、それに関連付けられたドメインのリストを変更した場合PECプロバイダが損なわれる可能性があります。
When verifying the validity of the signature of a message, the recipient system SHOULD verify that the certificate included in the [CMS] message is present in the LDIF file (section 4.5) and that the domain extracted by the [EMAIL] "From:" header is listed in the managedDomains attribute associated to said certificate.
メッセージの署名の正当性を検証するとき、受信側システムは、（セクション4.5）証明書は、LDIFファイルに存在する[CMS]メッセージに含まれていることを確認しなければならないこと「から」[EMAIL]により抽出されたドメインヘッダは、証明書を前記関連するmanagedDomains属性に記載されています。
This document defines new header fields used in the messages that transit in the PEC network. As specified and required by [HEADERS-IANA], this document registers new header fields as Provisional Message Header Fields as follows.
この文書は、メッセージPECネットワーク内のその輸送に使用される新しいヘッダーフィールドを定義します。 [HEADERS-IANA]で指定し、必要に応じて以下のように、このドキュメントは暫定メッセージヘッダフィールドとして新しいヘッダフィールドを登録します。
Applicable protocol: mail [EMAIL]
該当するプロトコル：メール[EMAIL]
Status: provisional
ステータス：暫定
Author/Change controller:
著者/変更コントローラ：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
クラウディオ・ペトルッチDigitPAヴィアーレカルロ・マルクス49分の31 00137ローマイタリアEメール：PETRUCCI@digitpa.gov.it
Specification document: this document, section 2.2.1, Appendix A.
仕様書：このドキュメント、セクション2.2.1、付録A.
Applicable protocol: mail [EMAIL]
該当するプロトコル：メール[EMAIL]
Status: provisional
ステータス：暫定
Author/Change controller:
著者/変更コントローラ：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
クラウディオ・ペトルッチDigitPAヴィアーレカルロ・マルクス49分の31 00137ローマイタリアEメール：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.
Applicable protocol: mail [EMAIL]
該当するプロトコル：メール[EMAIL]
Status: provisional
ステータス：暫定
Author/Change controller:
著者/変更コントローラ：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
クラウディオ・ペトルッチDigitPAヴィアーレカルロ・マルクス49分の31 00137ローマイタリアEメール：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.
Applicable protocol: mail [EMAIL]
該当するプロトコル：メール[EMAIL]
Status: provisional
ステータス：暫定
Author/Change controller:
著者/変更コントローラ：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
クラウディオ・ペトルッチDigitPAヴィアーレカルロ・マルクス49分の31 00137ローマイタリアEメール：PETRUCCI@digitpa.gov.it
Specification document: this document, sections 3.1.5, 3.2.2, Appendix A.
仕様書：このドキュメント、セクション3.1.5、3.2.2、付録A.
Applicable protocol: mail [EMAIL]
該当するプロトコル：メール[EMAIL]
Status: provisional
ステータス：暫定
Author/Change controller:
著者/変更コントローラ：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
クラウディオ・ペトルッチDigitPAヴィアーレカルロ・マルクス49分の31 00137ローマイタリアEメール：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.
Applicable protocol: mail [EMAIL]
該当するプロトコル：メール[EMAIL]
Status: provisional
ステータス：暫定
Author/Change controller:
著者/変更コントローラ：
Claudio Petrucci DigitPA Viale Carlo Marx 31/49 00137 Roma Italy EMail: PETRUCCI@digitpa.gov.it
クラウディオ・ペトルッチDigitPAヴィアーレカルロ・マルクス49分の31 00137ローマイタリアEメール：PETRUCCI@digitpa.gov.it
Specification document: this document, sections 3.2.3, Appendix A.
仕様書：このドキュメント、セクション3.2.3、付録A.
This document defines new LDAP attributes and object classes for object identifier descriptors. As specified and required by [LDAP-IANA], this document registers new descriptors as follows per the Expert Review.
この文書では、オブジェクト識別子記述子のために新しいLDAP属性とオブジェクトクラスを定義します。 [LDAP-IANA]で指定し、必要に応じて専門家レビューごとに次のように、この文書は、新しい記述子を登録します。
Subject: Request for LDAP Descriptor Registration
件名：LDAP記述子の登録要求
Descriptor (short name): See comments
記述子（ショートネーム）：コメントを参照してください。
Object Identifier: See comments
オブジェクト識別子：コメントを参照してください。
Person & email address to contact for further information: See "Author/Change Controller"
詳細のために連絡する人とEメールアドレス：「著者/変更コントローラ」を参照してください。
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
クラウディオ・ペトルッチDigitPAヴィアーレカルロ・マルクス49分の31 00137ローマイタリアEメール：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.
、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、エド、およびP. Overell、。。
[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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[EMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[EMAIL]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[HEADERS-IANA] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[HEADERS-IANA] Klyne、G.、ノッティンガム、M.、およびJ.モーグル、 "メッセージヘッダフィールドの登録手順"、BCP 90、RFC 3864、2004年9月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[HTTPS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTPS]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、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.、エド、 "ライトウェイトディレクトリアクセスプロトコル（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-IANA] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（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-構文]レッグ、S.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：構文と一致規則"、RFC 4517、2006年6月。
[LDIF] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[LDIF]グッド、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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、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]解放され、N.と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、 "メールのメッセージの提出"、RFC 4409、2006年4月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[SHA1]イーストレーク第3、D.とP.ジョーンズは、 "米国は、ハッシュアルゴリズム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.
ガルビン、J.、マーフィー、S.、クロッカー、S.、およびN.フリード、[MIME-SECURE] "MIMEマルチパートのためのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月。
[SMIMEV3] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
【SMIMEV3] Ramsdell、B.、およびS.ターナー、RFC 5751、2010年1月 "/多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様を固定"。
[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.ターナー、2010年1月、RFC 5750 "/多目的インターネットメール拡張（S / MIME）バージョン3.2証明書の処理を固定"。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J.、 "簡易メール転送プロトコル"、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]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]ホフマン、P.、RFC 3207、2002年2月 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"。
[TIMESTAMP] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[TIMESTAMP] Klyne、G.とC.ニューマン、 "インターネット上の日付と時刻：タイムスタンプ"、RFC 3339、2002年7月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, November 2008, <http://www.w3.org/TR/2006/REC-xml-20060816/>.
[XML] W3C、 "拡張マークアップ言語（XML）1.0（第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]レッグ、S.、 "ライトウェイトディレクトリアクセスプロトコル（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.、 "LDAP（Lightweight Directory Access Protocol）のX.509証明書のためのスキーマ定義"、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）の監督と多くのコラボレーションの製品です。
Appendix A. Italian Fields and Values in English
英語で付録A.イタリアのフィールドと値
NOTE: The right column represents a translation of the Italian fields for readability's sake only. Header fields that MUST be used are the ones in the left column.
注：右の列は読みやすさのためにイタリアの分野の翻訳を表します。使用しなければならないヘッダフィールドは、左の列のものです。
X-Riferimento-Message-ID Reference Message Identifier X-Ricevuta Notification non-accettazione non acceptance accettazione server-user acceptance preavviso-errore-consegna delivery error advance notice presa-in-carico server-server acceptance rilevazione-virus virus detection errore-consegna delivery error avvenuta-consegna message delivered X-Mittente Sender X-VerificaSicurezza Security Verification errore error X-Trasporto Transport posta-certificata certified mail errore error X-TipoRicevuta Notification Type completa complete breve brief sintetica concise
X-参照メッセージIDリファレンスメッセージ識別子X-受信通知非受付ない受付受付サーバユーザ受付通知エラー配信配信エラー予告ジャック担当サーバのサーバ受付検出ウイルスウイルス検出誤差配信配信エラー発生した配信メッセージ配信X-センダセンダX-VerificaSicurezzaセキュリティ検証エラーエラーX-トランス交通認定メール認定メールアドレスエラーエラーX-TipoRicevuta通知の完全な短いフルタイプの簡単な簡潔な概要
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
NOTウイルス承諾PEC通知のお知らせのために誘導非受け入れウイルス検出の非受理しない承諾PEC通知通知の課金サーバ-SERVER受け入れ配信配信メッセージ障害MESSAGE ANOMALY安全性の問題のセキュリティ上の問題の通知を取るメール証明郵便を認定受け入れSERVER-ユーザーの受け入れsupするDUE TIMEOUT PECへの配信を提供しないように、障害のウイルス通知通知のウイルスPECによるものではない配信を提供するために、障害の通知を提供する配信不能通知PECの失敗。最大時間の通知
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
他に受け入れサーバー・ユーザーの受け入れは、他の配信、配信証明書認定配達日配達日のデータが起こった受信者の受信者は、外部エラーエラーエラーエラーエラー配信配信はプロバイダーの日々のID識別子ヘッダヘッダ送信者、送信者の送信を外部広範なエラー・ハンドラの放送局を拡張しNO- DEST（inatario）なし受信者ドメイン無しノードメイン非受理今時間後-Certified認定された電子メールの通知誤り配信配信エラー予告ジャック・イン・担当サーバのサーバ受理通知領収書の領収書を受け取っていない受け入れ誰もなしオブジェクトの件名（ ）検出ウイルス検出の回答を受信する行為は、ウイルスのタイプの種類を返信
Authors' Addresses
著者のアドレス
Claudio Petrucci DigitPA Viale Marx 31/49 00137 Roma Italy
クラウディオ・ペトルッチDigitPAヴィアーレマルクス49分の31 00137ローマイタリア
EMail: petrucci@digitpa.gov.it
メールアドレス：petrucci@digitpa.gov.it
Francesco Gennai ISTI-CNR Via Moruzzi, 1 56126 Pisa Italy
フランチェスコ源内ISTI-CNR経由Moruzzi、1 56126ピサイタリア
EMail: francesco.gennai@isti.cnr.it
メールアドレス：francesco.gennai@isti.cnr.it
Alba Shahin ISTI-CNR Via Moruzzi, 1 56126 Pisa Italy
アルバシャヒンISTI-CNR経由Moruzzi、1 56126ピサイタリア
EMail: alba.shahin@isti.cnr.it
メールアドレス：alba.shahin@isti.cnr.it
Alessandro Vinciarelli Via delle Vigne di Morena 113 00118 Roma Italy
アレッサンドロVinciarelli経由デッレヴィーニェディモレナ113 00118ローマイタリア
EMail: alessandro.vinciarelli@gmail.com
メールアドレス：alessandro.vinciarelli@gmail.com