[要約] RFC 6186は、電子メールの送信/アクセスサービスを見つけるためのSRVレコードの使用に関する規格です。このRFCの目的は、ドメイン名からメールサービスの場所を特定するための標準化と、メールクライアントが適切なサーバーに接続できるようにすることです。
Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 6186 Apple Inc.
Updates: 1939, 3501 March 2011
Category: Standards Track
ISSN: 2070-1721
Use of SRV Records for Locating Email Submission/Access Services
電子メールの提出/アクセスサービスを見つけるためのSRVレコードの使用
Abstract
概要
This specification describes how SRV records can be used to locate email services.
この仕様では、SRVレコードを使用して電子メールサービスを見つける方法について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6186.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6186で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Email Submission . . . . . . . . . . . . . . . . . . . . . 3
3.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Priority for Domain Preferences . . . . . . . . . . . . . . 4
4. Guidance for MUAs . . . . . . . . . . . . . . . . . . . . . . . 5
5. Guidance for Service Providers . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Internet email protocols include SMTP [RFC5321], IMAP [RFC3501], and POP3 [RFC1939]. IMAP and POP3 are both message store access protocols used by message store user agents (MUAs) to manipulate email messages after delivery. [RFC4409] defines a "profile" of the SMTP service that is specifically used for message submission. MUAs are expected to submit messages to mail submission agents (MSAs) using this approach.
インターネットメールプロトコルには、SMTP [RFC5321]、IMAP [RFC3501]、およびPOP3 [RFC1939]が含まれます。IMAPとPOP3はどちらも、メッセージストアのユーザーエージェント（MUA）が使用するメッセージストアアクセスプロトコルであり、配信後に電子メールメッセージを操作します。[RFC4409]は、メッセージの送信に特別に使用されるSMTPサービスの「プロファイル」を定義します。MUAは、このアプローチを使用して、メール提出エージェント（MSA）にメッセージを送信することが期待されています。
[RFC2782] defines a DNS-based service discovery protocol that has been widely adopted as a means of locating particular services within a local area network and beyond, using DNS SRV resource records (RRs).
[RFC2782]は、DNS SRVリソースレコード（RRS）を使用して、ローカルエリアネットワーク内およびそれ以降の特定のサービスを見つける手段として広く採用されているDNSベースのサービス発見プロトコルを定義します。
[RFC5321] specifies how to use DNS MX RRs to locate SMTP services for a domain. However, MUAs are expected to use the submission protocol defined in [RFC4409], which does not use MX records.
[RFC5321] DNS MX RRSを使用してドメインのSMTPサービスを見つける方法を指定します。ただし、MUAは[RFC4409]で定義された提出プロトコルを使用することが期待されていますが、これはMXレコードを使用していません。
Typically MUAs have required users to enter a fully qualified domain name (FQDN) and port information for the services they need. This is not ideal as the way in which server configuration information is specified can differ from MUA to MUA, and can be confusing to users, leading to errors when inputting the details. Alternatively, some MUAs have adopted a complex "auto-discovery" process involving probing a domain to see what services might be available. A better approach to all this would be to require minimal information to be entered by a user that would result in automatic configuration of appropriate services for that user. The minimal information entered would be the user's email address.
通常、MUAは、ユーザーが必要なサービスの完全資格のドメイン名（FQDN）とポート情報を入力することを要求しています。これは、サーバーの構成情報が指定される方法がMUAごとに異なる場合があり、ユーザーと混同し、詳細を入力するときにエラーにつながるため、理想的ではありません。あるいは、一部のMUAは、ドメインを調査するためにどのサービスが利用可能かを確認する複雑な「自動ディスコーブ」プロセスを採用しています。これに対するより良いアプローチは、そのユーザーに適切なサービスの自動構成をもたらすユーザーが入力する最小限の情報を必要とすることです。入力された最小限の情報は、ユーザーのメールアドレスです。
This specification defines new SRV service types for the message submission, IMAP, and POP3 services, to enable simple auto-configuration of MUAs. The priority field of the SRV record can also be used to indicate a preference for one message store access protocol over another.
この仕様では、メッセージの提出、IMAP、およびPOP3サービスの新しいSRVサービスタイプを定義して、MUAの簡単な自動構成を可能にします。SRVレコードの優先フィールドを使用して、あるメッセージストアアクセスプロトコルよりも優先順位を示すこともできます。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Email-related terminology from [RFC5598] is used.
[RFC5598]からの電子メール関連の用語が使用されます。
This specification adds one SRV service label for message submission [RFC4409]:
この仕様は、メッセージ提出のために1つのSRVサービスラベル[RFC4409]を追加します。
submission: Identifies an MSA using [RFC4409]. Note that this covers connections both with and without Transport Layer Security (TLS) [RFC5246] as defined for SMTP in [RFC3207].
提出：[RFC4409]を使用してMSAを識別します。これは、[RFC3207]のSMTPに対して定義されているように、輸送層のセキュリティ（TLS）[RFC5246]の有無にかかわらず接続をカバーすることに注意してください。
Example: service record
例：サービスレコード
_submission._tcp SRV 0 1 587 mail.example.com.
_Submission._TCP SRV 0 1 587 Mail.example.com。
This specification adds two SRV service labels for IMAP [RFC3501]:
この仕様は、IMAP [RFC3501]に2つのSRVサービスラベルを追加します。
_imap: Identifies an IMAP server that MAY advertise the "LOGINDISABLED" capability and MAY require the MUA to use the "STARTTLS" command prior to authentication. Although these two extensions are mandatory-to-implement for both MUAs and IMAP servers, they are not mandatory-to-use by service providers.
_IMAP：「LogIndisabled」機能を宣伝する可能性のあるIMAPサーバーを識別し、認証の前にMUAに「startTLS」コマンドを使用するように要求する場合があります。これらの2つの拡張機能は、MUASサーバーとIMAPサーバーの両方に対して義務的なものですが、サービスプロバイダーによる使用は必須ではありません。
_imaps: Identifies an IMAP server where TLS [RFC5246] is initiated directly upon connection to the IMAP server.
_IMAPS：TLS [RFC5246]がIMAPサーバーへの接続時に直接開始されるIMAPサーバーを識別します。
Example: service record
例：サービスレコード
_imap._tcp SRV 0 1 143 imap.example.com.
_IMAP._TCP SRV 0 1 143 imap.example.com。
Example: service record
例：サービスレコード
_imaps._tcp SRV 0 1 993 imap.example.com.
_IMAPS._TCP SRV 0 1 993 imap.example.com。
This specification adds two SRV service labels for POP3 [RFC1939]:
この仕様は、POP3 [RFC1939]に2つのSRVサービスラベルを追加します。
_pop3: Identifies a POP3 server that MAY require the MUA to use the "STLS" extension command [RFC2595] prior to authentication.
_POP3：認証前にMUAに「STLS」拡張コマンド[RFC2595]を使用する必要があるPOP3サーバーを識別します。
_pop3s: Identifies a POP3 server where TLS [RFC5246] is initiated directly upon connection to the POP3 server.
_POP3S：TLS [RFC5246]がPOP3サーバーへの接続時に直接開始されるPOP3サーバーを識別します。
Example: service record
例：サービスレコード
_pop3._tcp SRV 0 1 110 pop3.example.com.
_POP3._TCP SRV 0 1 110 pop3.example.com。
Example: service record
例：サービスレコード
_pop3s._tcp SRV 0 1 995 pop3.example.com.
_pop3s._tcp srv 0 1 995 pop3.example.com。
The priority field in the SRV RR allows a domain to indicate that some records have a higher preference than others in the DNS query results (determined by those records having a lower-numbered priority value). Typically, this is used for choosing a record from a set for a single service label; however, it is not restricted to choice within only one service.
SRV RRの優先度フィールドにより、ドメインはDNSクエリの結果（優先度が低いレコードで決定）で他のレコードよりも優先度が高いことをドメインが示すことができます。通常、これは、単一のサービスラベルのセットからレコードを選択するために使用されます。ただし、1つのサービスのみで選択に限定されません。
Often a site will offer both IMAP and POP3 message store access services for users. However, the site may have a preference for one over the other that they want to convey to the user to ensure that, when the user has an MUA capable of using both IMAP and POP3, the preferred choice is used.
多くの場合、サイトはユーザー向けにIMAPとPOP3のメッセージストアアクセスサービスの両方を提供します。ただし、サイトは、ユーザーがIMAPとPOP3の両方を使用できるMUAを持っている場合、ユーザーに伝えたいと思うものよりも優先される場合があります。
To aid with this choice, sites SHOULD offer both sets of IMAP (_imap and/or _imaps) and POP3 (_pop3 and/or _pop3s) SRV records in their DNS and set the priority for those sets of records such that the "preferred" service has a lower-numbered priority value than the other. When an MUA supports both IMAP and POP3, it SHOULD retrieve records for both services and then use the service with the lowest priority value. If the priority is the same for both services, MUAs are free to choose whichever one is appropriate. When considering multiple records for different protocols at the same priority but with different weights, the client MUST first select the protocol it intends to use, then perform the weight selection algorithm given in [RFC2782] on the records associated with the selected protocol.
この選択を支援するために、サイトはDNSにIMAP（_IMAPおよび/または_IMAP）とPOP3（_POP3および/または_POP3S）の両方のセットをDNSに提供し、「優先」サービスの記録セットの優先順位を設定する必要があります。他の優先度の値が少ない。MUAがIMAPとPOP3の両方をサポートする場合、両方のサービスのレコードを取得し、最小優先度の値でサービスを使用する必要があります。両方のサービスで優先度が同じ場合、MUAは適切なものを自由に選択できます。同じ優先順位で異なるプロトコルの複数のレコードを検討する場合、重みが異なる場合、クライアントは最初に使用するプロトコルを選択し、次に選択したプロトコルに関連付けられたレコードに[RFC2782]に与えられた重量選択アルゴリズムを実行する必要があります。
Example: service records for both IMAP and POP3, with IMAP having a lower-numbered priority value (0) than POP3 (10), indicating to the MUA that IMAP is preferred over POP3, when the MUA can support either service.
例：IMAPとPOP3の両方のサービスレコード。IMAPはPOP3（10）よりも低い優先度値（0）を持っています。MUAは、MUAがいずれかのサービスをサポートできる場合、IMAPがPOP3よりも優先されることを示しています。
_imap._tcp SRV 0 1 143 imap.example.com. _pop3._tcp SRV 10 1 110 pop3.example.com.
_IMAP._TCP SRV 0 1 143 imap.example.com。_POP3._TCP SRV 10 1 110 pop3.example.com。
In addition, with SRV RRs it is possible to indicate that a particular service is not supported at all at a particular domain by setting the target of an SRV RR to ".". If such records are present, clients MUST assume that the specified service is not available, and instead make use of the other SRV RRs for the purposes of determining the domain preference.
さらに、SRV RRSを使用すると、SRV RRのターゲットを「」に設定することにより、特定のドメインで特定のサービスがまったくサポートされていないことを示すことができます。そのようなレコードが存在する場合、クライアントは指定されたサービスが利用できないと想定し、代わりにドメイン選好を決定する目的で他のSRV RRを使用する必要があります。
Example: service records for IMAP and POP3 with both TLS and non-TLS service types are present. Both IMAP and POP3 non-TLS service types are marked as not available. IMAP (with TLS) has a lower-numbered priority value 0 than POP3 (with TLS) at priority 10, indicating to the MUA that IMAP is preferred over POP3, when the MUA can support either service, and only the TLS versions of the services are available.
例：TLSと非TLSサービスタイプの両方を備えたIMAPとPOP3のサービスレコードが存在します。IMAPとPOP3の両方の非TLSサービスタイプは、利用できないとマークされています。IMAP（TLSを使用）は、優先度10のPOP3（TLSを含む）よりも少ない優先度値0を持っています。MUAは、MUAがどちらかのサービスをサポートできる場合、およびサービスのTLSバージョンのみをサポートできるPOP3よりもIMAPが優先されることを示しています。利用可能です。
_imap._tcp SRV 0 0 0 . _imaps._tcp SRV 0 1 993 imap.example.com. _pop3._tcp SRV 0 0 0 . _pop3s._tcp SRV 10 1 995 pop3.example.com.
_IMAP._TCP SRV 0 0 0。_IMAPS._TCP SRV 0 1 993 imap.example.com。_POP3._TCP SRV 0 0 0。_POP3S._TCP SRV 10 1 995 pop3.example.com。
By using SRV records as above, MUAs need initially only to prompt the user for their email address [RFC5322]. The "local-part" and "domain" portions are then extracted from the email address by the MUA. The MUA uses the "domain" portion as the service domain to perform SRV lookups for the services it wants to configure. If the SRV lookup is successful, the target FQDN and port for the service can be determined and used to complete MUA configuration. If an SRV record is not found, the MUA will need to prompt the user to enter the FQDN and port information directly, or use some other heuristic. In the case of multiple SRV records returned for a particular service, the MUA MUST use the priority and weight fields in the record to determine which one to use (as per [RFC2782]).
上記のようにSRVレコードを使用することにより、MUASは最初にユーザーに電子メールアドレスを求めるためにのみ必要です[RFC5322]。「ローカルパート」および「ドメイン」部分は、MUAによって電子メールアドレスから抽出されます。MUAは、「ドメイン」部分をサービスドメインとして使用して、構成するサービスのSRVルックアップを実行します。SRVルックアップが成功した場合、サービスのターゲットFQDNとポートを決定し、MUA構成を完了するために使用できます。SRVレコードが見つからない場合、MUAはユーザーにFQDNとポート情報を直接入力するように促すか、他のヒューリスティックを使用する必要があります。特定のサービスのために複数のSRVレコードが返された場合、MUAはレコード内の優先順位と重量フィールドを使用して（[RFC2782]に従って）使用するものを決定する必要があります。
MUAs that support both POP3 and IMAP use the procedure in Section 3.4 to choose between each service when both are offered.
POP3とIMAPの両方をサポートするMUASは、セクション3.4の手順を使用して、両方が提供されたときに各サービスを選択します。
Subsequent to configuration, the MUA will connect to the service. When using "imaps" or "pop3s" services, a TLS [RFC5246] negotiation is done immediately upon connection. With "imap", "pop3", and "submission" services, the "STARTTLS", "STLS", and "STARTTLS" commands respectively are used to initiate a protected connection using TLS [RFC5246]. When using TLS in this way, MUAs SHOULD use the TLS Server Name Indication [RFC6066]. Certificate verification MUST use the procedure outlined in Section 6 of [RFC6125] in regard to verification with an SRV RR as the starting point.
構成に続いて、MUAはサービスに接続します。「IMAPS」または「POP3S」サービスを使用する場合、TLS [RFC5246]交渉は接続の直後に行われます。「IMAP」、「POP3」、および「提出」サービス、「StartTLS」、「STLS」、および「startTLS」コマンドを使用して、TLS [RFC5246]を使用して保護された接続を開始するために使用されます。この方法でTLSを使用する場合、MUAはTLSサーバー名表示[RFC6066]を使用する必要があります。証明書の確認は、SRV RRを使用した検証に関して、[RFC6125]のセクション6で概説されている手順を開始点として使用する必要があります。
Once a suitable connection has been made, and any required protection set up, the MUA will typically need to authenticate with the IMAP, POP3, or SMTP (submission) server. The details of that are governed by the specific protocols themselves, though often times a "user identifier" is required for some form of user/password authentication. When a user identifier is required, MUAs MUST first use the full email address provided by the user, and if that results in an authentication failure, SHOULD fall back to using the "local-part" extracted from the email address. This is in line with the guidance outlined in Section 5. If both these user identifiers result in authentication failure, the MUA SHOULD prompt the user for a valid identifier.
適切な接続が行われ、必要な保護が設定されたら、MUAは通常、IMAP、POP3、またはSMTP（提出）サーバーで認証する必要があります。その詳細は特定のプロトコル自体によって管理されますが、多くの場合、「ユーザー識別子」が何らかの形のユーザー/パスワード認証に必要です。ユーザー識別子が必要な場合、MUAは最初にユーザーが提供する完全な電子メールアドレスを使用する必要があり、その結果、認証障害が発生する場合は、電子メールアドレスから抽出された「ローカルパート」を使用することに戻る必要があります。これは、セクション5で概説されているガイダンスと一致しています。これらの両方のユーザー識別子が認証障害につながる場合、MUAはユーザーに有効な識別子を促す必要があります。
Once a successful connection and authentication have been done, MUAs SHOULD cache the service details (hostname, port, user identity) that were successfully used, and reuse those when connecting again at a later time.
接続と認証が成功したら、MUAは使用されたサービスの詳細（ホスト名、ポート、ユーザーID）をキャッシュし、後で再び接続するときにそれらを再利用する必要があります。
If a subsequent connection attempt fails, or authentication fails, MUAs SHOULD re-try the SRV lookup to "refresh" the cached data for the same protocol the client had chosen earlier; i.e., this means that the client MUST NOT change from IMAP service to POP3 (or vice versa) due to changes in the corresponding SRV priorities without user interaction.
後続の接続試行が失敗した場合、または認証が失敗した場合、MUAはSRV検索を再試行して、クライアントが以前に選択した同じプロトコルのキャッシュデータを「更新」する必要があります。つまり、これは、ユーザーの相互作用なしに対応するSRV優先順位の変更により、クライアントがIMAPサービスからPOP3（またはその逆）に変更してはならないことを意味します。
Service providers wanting to offer IMAP, POP3, or SMTP (submission) services that can be configured by MUAs using SRV records need to follow certain guidelines to ensure proper operation.
SRVレコードを使用してMUASによって構成できるIMAP、POP3、またはSMTP（提出）サービスを提供したいサービスプロバイダーは、適切な操作を確保するために特定のガイドラインに従う必要があります。
a. IMAP, POP3, and SMTP (submission) servers SHOULD be configured to allow authentication with email addresses or email local-parts. In the former case, the email addresses MUST NOT conflict with other forms of permitted user login name. In the latter case, the email local-parts need to be unique across the server and MUST NOT conflict with any login name on the server.
a. IMAP、POP3、およびSMTP（提出）サーバーは、電子メールアドレスまたは電子メールのローカルパートで認証を許可するように構成する必要があります。前者の場合、電子メールアドレスは、許可されたユーザーログイン名の他の形式と競合してはなりません。後者の場合、電子メールのローカルパートはサーバー全体で一意である必要があり、サーバー上のログイン名と競合してはなりません。
b. If the service provider uses TLS [RFC5246], the service provider MUST ensure a certificate is installed that can be verified by MUAs using the procedure outlined in Section 6 of [RFC6125] in regard to verification with an SRV RR as the starting point. If the service provider hosts multiple domains on the same IP address, then the service provider MUST enable support for the TLS Server Name Indication [RFC6066].
b. サービスプロバイダーがTLS [RFC5246]を使用している場合、サービスプロバイダーは、SRV RRを使用した検証に関する[RFC6125]のセクション6で概説されている手順を使用して、MUASによって検証できる証明書をインストールする必要があります。サービスプロバイダーが同じIPアドレスで複数のドメインをホストする場合、サービスプロバイダーはTLSサーバー名表示[RFC6066]のサポートを有効にする必要があります。
c. Install the appropriate SRV records for the offered services.
c. 提供されたサービスに適切なSRVレコードをインストールします。
If a user has explicitly requested a connection with a transport layer security mechanism (user interfaces sometimes present this choice as a "use SSL" or "secure connection" checkbox), the MUA MUST successfully negotiate transport layer security prior to sending an authentication command. For example, the MUA MAY do this with "imaps", "pop3s", "imap" with "STARTTLS", or "pop3" with "STLS". Service providers MAY offer any subset of these four options for the mail service.
ユーザーがトランスポートレイヤーセキュリティメカニズムとの接続を明示的に要求した場合（ユーザーインターフェイスは、この選択を「SSLを使用する」または「セキュア接続」チェックボックスとして表示することがあります）、MUAは認証コマンドを送信する前にトランスポートレイヤーセキュリティを正常にネゴシエートする必要があります。たとえば、MUAは、「IMAPS」、「POP3S」、「IMAP」で「startTLS」を使用して、または「STLS」を使用して「IMAP」でこれを行う場合があります。サービスプロバイダーは、メールサービスのこれら4つのオプションのサブセットを提供する場合があります。
A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially cause MUAs to connect to any IMAP, POP3, or submission server chosen by the attacker. In the absence of a secure DNS option, MUAs SHOULD check that the target FQDN returned in the SRV record matches the original service domain that was queried. If the target FQDN is not in the queried domain, MUAs SHOULD verify with the user that the SRV target FQDN is suitable for use before executing any connections to the host. Alternatively, if TLS [RFC5246] is being used for the email service, MUAs MUST use the procedure outlined in Section 6 of [RFC6125] to verify the service.
DNSサーバーデータにアクセスできる悪意のある攻撃者、または再帰リゾルバーでキャッシュされたスプーフィングされた回答を取得できるため、MUAが攻撃者が選択した任意のIMAP、POP3、または提出サーバーに接続する可能性があります。安全なDNSオプションがない場合、MUASは、SRVレコードで返されたターゲットFQDNが、照会された元のサービスドメインと一致することを確認する必要があります。ターゲットFQDNがクエリドメインにない場合、MUASはユーザーにSRVターゲットFQDNがホストへの接続を実行する前に使用に適していることを確認する必要があります。あるいは、TLS [RFC5246]が電子メールサービスに使用されている場合、MUASは[RFC6125]のセクション6で概説されている手順を使用してサービスを検証する必要があります。
Implementations of TLS [RFC5246] typically support multiple versions of the protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, email clients and email servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further details.
TLS [RFC5246]の実装は、通常、プロトコルの複数のバージョンと古いセキュアソケット層（SSL）プロトコルをサポートしています。既知のセキュリティの脆弱性のため、電子メールクライアントと電子メールサーバーは、SSL 2.0を要求、提供、または使用してはなりません。詳細については、[RFC5246]の付録E.2を参照してください。
Thanks to Tony Finch, Ned Freed, Alfred Hoenes, Suresh Krishnan, Alexey Melnikov, Chris Newman, and Phil Pennock for feedback and suggestions. Some of this work is based on a previously drafted document by John Klensin and Eric Hall.
トニー・フィンチ、ネッド・フリード、アルフレッド・ホーネス、スレシュ・クリシュナン、アレクセイ・メルニコフ、クリス・ニューマン、フィル・ペノックに感謝します。この作品の一部は、ジョンクレンシンとエリックホールによって以前に起草された文書に基づいています。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939] Myers、J。およびM. Rose、「郵便局プロトコル - バージョン3」、STD 53、RFC 1939、1996年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595] Newman、C。、「IMAP、POP3およびACAPでTLSを使用」、RFC 2595、1999年6月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066] EastLake、D。、「輸送層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、2011年1月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「輸送層のセキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開キーインフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、RFC 6125、2011年3月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月。
Author's Address
著者の連絡先
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
EMail: cyrus@daboo.name
URI: http://www.apple.com/