RFC 6186 - Use of SRV Records for Locating Email Submission/Access Services 日本語訳

URL : https://tools.ietf.org/html/rfc6186
タイトル : RFC 6186 - メール提出/アクセスサービスの検索のためのSRVレコードの使用
翻訳編集 : 自動生成

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

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.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6186で取得することができます。

著作権表示

著作権（C）2011 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  . . . . . . . . . . . . . . . . . . . . . . . . . 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

1. Introduction

1. はじめに

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リソースレコード（RR）を使用して、ローカルエリアネットワーク内と超え特定のサービスを探し出すための手段として採用されている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]は、ドメインのSMTPサービスを検索するDNSのMX RRを使用する方法を指定します。しかし、のMUAは、MXレコードを使用していない[使いrfc4409]で定義されたサブミッションプロトコルを使用することが期待されています。

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異なることができ、そしてユーザに混乱することができ、詳細を入力する際にエラーにつながるので、これは理想的ではありません。あるいは、いくつかの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.

この仕様は、のMUAの簡単な自動設定を有効にするために、メッセージ送信、IMAP、およびPOP3サービスのための新しいSRVサービスタイプを定義します。 SRVレコードの優先度フィールドは、他の上で1つのメッセージ・ストア・アクセス・プロトコルの好みを示すために使用することができます。

2. Conventions Used in This Document

この文書で使用される2.表記

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

Email-related terminology from [RFC5598] is used.

[RFC5598]からのメール関連の用語が使用されています。

3. SRV Service Labels

3. SRVサービスラベル

3.1. Email Submission

3.1. 電子メールの提出

This specification adds one SRV service label for message submission [RFC4409]:

この仕様は、メッセージ送信[使いrfc4409]のための1つのSRVサービスラベルを追加します。

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。

3.2. IMAP

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」機能をアドバタイズかもしれなくて、認証前に「STARTTLS」コマンドを使用するようにMUAを必要とするかもしれIMAPサーバーを識別します。これら2つの拡張が実装に必須ののMUAと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 1993 imap.example.com。

3.3. POP3

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：認証する前に、[RFC2595]「STLS」拡張コマンドを使用するようにMUAを必要とするかもしれ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。

3.4. Priority for Domain Preferences

3.4. ドメイン設定のための優先順位

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クエリの結果で他よりも高い優先度を有することを示すことを可能にします。通常、これは単一のサービスラベルのセットからレコードを選択するために使用されます。しかし、それが唯一のサービス内の選択肢に制限されるものではありません。

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および/または_imaps）のセットとPOP3（_pop3および/または_pop3s）SRVレコードを提供し、そのような「好ましい」サービスそのレコードのそれらのセットの優先度を設定すべきです他のより低い番号の優先順位の値を有します。 MUAは、IMAPとPOP3の両方をサポートしている場合、それは両方のサービスのためのレコードを取得してから最低の優先度の値でサービスを使用すべきです。優先度は、両方のサービスに同じである場合は、MUAには、適切な方1自由に選択できます。同じ優先度で異なるプロトコルのために異なる量の複数のレコードを考慮した場合、クライアントは最初に、使用する予定のプロトコルを選択する必要があり、その後、選択されたプロトコルに関連付けられたレコードの[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とIMAPとPOP3の両方のためのサービス・レコード（0）POP3よりも（10）、MUAは、いずれかのサービスをサポートすることができるIMAPはPOP3よりも好ましいことがMUAに示します。

       _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資源レコードと、に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サービスタイプの両方が利用できないものとしてマークされています。（TLSを使用）IMAPは、MUAは、いずれかのサービスをサポートすることができる場合IMAPは、POP3よりも好ましいことMUAに示す優先度10で（TLSで）POP3より低い番号の優先順位値0を有し、およびサービスの唯一のTLSバージョンご利用いただけます。

       _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.

4. Guidance for MUAs

顧客のため4.ガイダンス

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レコードを使用することにより、MUAには、自分のメールアドレス[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の両方をサポートするMUAは、両方が提供されている場合、各サービス間で選択するために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は、第1のユーザによって提供される完全な電子メールアドレスを使用する必要があり、かつ、認証失敗をもたらす場合、バックメールアドレスから抽出された「ローカル部分」を用いに落ちるべきです。これは、これらの両方のユーザ識別子が認証失敗に終わる場合は第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が正常に使用されたサービスの詳細（ホスト名、ポート、ユーザー・アイデンティティ）をキャッシュすべき、と後で再び接続する際に、それらのを再利用します。

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優先度の変化にPOP3にIMAPサービス（またはその逆）から変化してはならないことを意味します。

5. Guidance for Service Providers

サービスプロバイダ向け5.ガイダンス

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レコードを使用してのMUAで設定することができます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に概説した手順を使用してのMUAにより確認することができる証明書がインストールされていることを確認しなければなりません。サービスプロバイダは、同じIPアドレスに複数のドメインをホストする場合は、サービスプロバイダは、TLSサーバー名の表示[RFC6066]のサポートを有効にする必要があります。

c. Install the appropriate SRV records for the offered services.

C。提供されるサービスのための適切なSRVレコードをインストールします。

6. Security Considerations

6.セキュリティの考慮事項

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は "STLS" と "STARTTLS" と "IMAPS"、 "POP3S"、 "IMAP"、または "POP3" でこれを行うことができます。サービスプロバイダは、メールサービスのためのこれらの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サーバーのデータへのアクセス権を持つ悪意のある攻撃者は、再帰的なリゾルバにキャッシュされ、偽装された答えを得ることができ、潜在的に攻撃者が選択した任意のIMAP、POP3、または提出サーバーに接続するのMUAを引き起こす可能性があります。安全なDNSオプションがない場合には、のMUAは、FQDNがSRVレコードに返されたターゲットが照会された元のサービスのドメインと一致していることを確認する必要があります。ターゲットFQDNが照会ドメインにない場合、のMUAはSRVターゲットFQDNがホストへの接続を実行する前に、使用するのに適していることをユーザに確認してください。 TLS [RFC5246]は、電子メールサービスのために使用されている場合、あるいは、のMUAは、サービスを確認するために、[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]の実装は、典型的には、複数のプロトコルのバージョン、ならびに古いのSecure Sockets Layer（SSL）プロトコルをサポートします。そのため、既知のセキュリティの脆弱性のため、電子メールクライアントとメールサーバは、提供を要求し、またはSSL 2.0を使用してはなりません。詳細は[RFC5246]の付録E.2を参照してください。

7. Acknowledgments

7.謝辞

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.

フィードバックや提案のためのトニー・フィンチ、ネッドフリード、アルフレッドHoenes、スレシュクリシュナン、アレクセイ・メルニコフ、クリス・ニューマン、フィル・ペノックに感謝します。この作品のいくつかは、ジョン・クレンシンとエリック・ホールによって、以前に起草された文書に基づいています。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

[RFC1939]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.

[RFC2595]ニューマン、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]ホフマン、P.、 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"、RFC 3207、2002年2月。

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。

[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.

[RFC4409] Gellens、R.とJ. Klensin、 "メールのメッセージの提出"、RFC 4409、2006年4月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[RFC5321] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。

[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.

[RFC6066]イーストレイク、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]サンアンドレ、P.およびJ.ホッジス、「表現およびTransport Layer Security（TLS）の文脈でインターネット公開鍵インフラストラクチャの使用X.509内のドメインベースのアプリケーションサービスのアイデンティティの検証（PKIX）証明書」、 RFC 6125、2011年3月。

8.2. Informative References

8.2. 参考文献

[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.

[RFC5598]クロッカー、D.、 "インターネットメールのアーキテクチャ"、RFC 5598、2009年7月。

Author's Address

著者のアドレス

Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA

サイラスDabooされたApple Inc. 1無限ループクパチーノ、CA 95014 USA

EMail: cyrus@daboo.name URI: http://www.apple.com/

電子メール：cyrus@daboo.name URI：http://www.apple.com/