[要約] RFC 8461は、SMTP MTA Strict Transport Security（MTA-STS）プロトコルに関する規格です。その目的は、電子メールのセキュリティを向上させ、中間者攻撃や盗聴から保護することです。
Internet Engineering Task Force (IETF) D. Margolis
Request for Comments: 8461 M. Risher
Category: Standards Track Google, Inc.
ISSN: 2070-1721 B. Ramakrishnan
Oath, Inc.
A. Brotman
Comcast, Inc.
J. Jones
Microsoft, Inc.
September 2018
SMTP MTA Strict Transport Security (MTA-STS)
SMTP MTA Strict Transport Security（MTA-STS）
Abstract
概要
SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.
SMTP MTA Strict Transport Security（MTA-STS）は、メールサービスプロバイダー（SP）がトランスポート層セキュリティ（TLS）で保護されたSMTP接続を受信する機能を宣言し、送信SMTPサーバーがMXホストへの配信を拒否するかどうかを指定できるようにするメカニズムです。信頼されたサーバー証明書でTLSを提供しないでください。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8461.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8461で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5
3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 6
3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 7
3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 10
3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 11
4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 11
4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 12
4.2. Recipient MTA Certificate Validation . . . . . . . . . . 12
5. Policy Application . . . . . . . . . . . . . . . . . . . . . 12
5.1. Policy Application Control Flow . . . . . . . . . . . . . 13
6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 13
7. Interoperability Considerations . . . . . . . . . . . . . . . 14
7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 14
8. Operational Considerations . . . . . . . . . . . . . . . . . 15
8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 15
8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 15
8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 16
8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 17
9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 17
9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 18
10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 19
10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 19
10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 20
10.5. Compromise of the Web PKI System . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. MTA-STS Example Record and Policy . . . . . . . . . 25
Appendix B. Message Delivery Pseudocode . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to negotiate the use of a TLS channel for encrypted mail transmission.
SMTPのSTARTTLS拡張[RFC3207]により、SMTPクライアントとホストは、暗号化されたメール送信のためのTLSチャネルの使用をネゴシエートできます。
While this opportunistic encryption protocol by itself provides a high barrier against passive man-in-the-middle traffic interception, any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or who can redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform downgrade or interception attacks.
この便宜的な暗号化プロトコル自体は、中間者による受動的なトラフィック傍受に対する高い障壁を提供しますが、SMTPセッションの一部を削除できる攻撃者（「250 STARTTLS」応答など）またはSMTP全体をリダイレクトできる攻撃者セッション（おそらく配信ドメインの解決されたMXレコードを上書きすることにより）は、ダウングレードまたはインターセプト攻撃を実行できます。
This document defines a mechanism for recipient domains to publish policies, via a combination of DNS and HTTPS, specifying:
このドキュメントでは、DNSとHTTPSの組み合わせを介して、受信者ドメインがポリシーを公開するためのメカニズムを定義します。
o whether MTAs sending mail to this domain can expect PKIX-authenticated TLS support
o このドメインにメールを送信するMTAがPKIX認証のTLSサポートを期待できるかどうか
o what a conforming client should do with messages when TLS cannot be successfully negotiated
o TLSが正常にネゴシエートできない場合に、適合しているクライアントがメッセージに対して行うべきこと
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
We also define the following terms for further use in this document:
このドキュメントでさらに使用するために、次の用語も定義します。
o MTA-STS Policy: A commitment by the Policy Domain to support TLS authenticated with PKIX [RFC5280] for the specified MX hosts.
o MTA-STSポリシー：指定されたMXホストのPKIX [RFC5280]で認証されたTLSをサポートするためのポリシードメインによるコミットメント。
o Policy Domain: The domain for which an MTA-STS Policy is defined. This is the next-hop domain; when sending mail to "alice@example.com", this would ordinarily be "example.com", but this may be overridden by explicit routing rules (as described in Section 3.4, "Policy Selection for Smart Hosts and Subdomains").
o ポリシードメイン：MTA-STSポリシーが定義されているドメイン。これはネクストホップドメインです。 「alice@example.com」にメールを送信する場合、これは通常「example.com」になりますが、明示的なルーティングルールによって上書きされることがあります（「3.4スマートホストとサブドメインのポリシー選択」で説明）。
o Policy Host: The HTTPS host that serves the MTA-STS Policy for a Policy Domain. Rules for constructing the hostname are described in Section 3.2, "MTA-STS Policies".
o ポリシーホスト：ポリシードメインのMTA-STSポリシーを提供するHTTPSホスト。ホスト名を作成するためのルールは、3.2項「MTA-STSポリシー」で説明されています。
o Sender or Sending MTA: The SMTP MTA sending an email message.
o 送信者または送信MTA：電子メールメッセージを送信するSMTP MTA。
o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying syntax, defined in [RFC5234] and [RFC7405].
o ABNF：[RFC5234]と[RFC7405]で定義されている、構文を正式に指定するための構文である拡張バッカスナウアフォーム。
The DNS-Based Authentication of a Named Entities (DANE) TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades. For a thorough discussion of this trade-off, see Section 10, "Security Considerations".
名前付きエンティティのDNSベースの認証（DANE）TLSAレコード[RFC7672]も同様です。DANEは、認証されていない暗号化またはプレーンテキスト送信を認証されたダウングレード耐性の暗号化された送信にアップグレードするようにも設計されています。 DANEは認証にDNSSEC [RFC4033]を必要とします。ここで説明するメカニズムは、代わりに証明機関（CA）に依存しており、悪意のあるダウングレードのリスクを犠牲にしてDNSSECを必要としません。このトレードオフの詳細については、「セキュリティに関する考慮事項」を参照してください。
In addition, MTA-STS provides an optional testing-only mode, enabling soft deployments to detect policy failures; partial deployments can be achieved in DANE by deploying TLSA records only for some of a domain's MXes, but such a mechanism is not possible for the per-domain policies used by MTA-STS.
さらに、MTA-STSはオプションのテスト専用モードを提供し、ソフトデプロイメントがポリシーの失敗を検出できるようにします。一部のドメインのMXesに対してのみTLSAレコードをデプロイすることにより、DANEで部分的なデプロイメントを実現できますが、MTA-STSで使用されるドメインごとのポリシーでは、このようなメカニズムは使用できません。
The primary motivation of MTA-STS is to provide a mechanism for domains to ensure transport security even when deploying DNSSEC is undesirable or impractical. However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation.
MTA-STSの主な動機は、DNSSECの導入が望ましくないか実用的でない場合でも、ドメインにトランスポートセキュリティを確保するメカニズムを提供することです。ただし、MTA-STSは、2つが重複する場合にDANEの展開を妨げないように設計されています。特に、MTA-STS検証を実装する送信者は、MTA-STSポリシー検証が失敗したDANE検証をオーバーライドすることを許可してはなりません。
MTA-STS policies are distributed via HTTPS from a "well-known" [RFC5785] path served within the Policy Domain, and their presence and current version are indicated by a TXT record at the Policy Domain. These TXT records additionally contain a policy "id" field, allowing Sending MTAs to check that a cached policy is still current without performing an HTTPS request.
MTA-STSポリシーは、ポリシードメイン内で提供される「既知の」[RFC5785]パスからHTTPS経由で配布され、その存在と現在のバージョンは、ポリシードメインのTXTレコードで示されます。これらのTXTレコードには、ポリシーの「id」フィールドがさらに含まれているため、送信MTAは、HTTPSリクエストを実行せずに、キャッシュされたポリシーがまだ最新であることを確認できます。
To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record. To see if an updated policy is available for a domain for which the sender has a previously cached policy, the sender need only check the TXT record's version "id" against the cached value.
受信者ドメインがMTA-STSを実装しているかどうかを検出するには、送信者は単一のTXTレコードを解決するだけで済みます。送信者が以前にキャッシュされたポリシーを持っているドメインで更新されたポリシーが利用可能かどうかを確認するには、送信者は、キャッシュされた値に対してTXTレコードのバージョン「id」を確認するだけです。
The MTA-STS TXT record is a TXT record with the name "_mta-sts" at the Policy Domain. For the domain "example.com", this record would be "_mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII, semicolon-separated key/value pairs containing the following fields:
MTA-STS TXTレコードは、ポリシードメインの「_mta-sts」という名前のTXTレコードです。ドメイン「example.com」の場合、このレコードは「_mta-sts.example.com」になります。 MTA-STS TXTレコードは、次のフィールドを含むUS-ASCIIのセミコロン区切りのキー/値のペアである必要があります。
o "v" (plaintext, required): Currently, only "STSv1" is supported.
o "v"（プレーンテキスト、必須）：現在、 "STSv1"のみがサポートされています。
o "id" (plaintext, required): A short string used to track policy updates. This string MUST uniquely identify a given instance of a policy, such that senders can determine when the policy has been updated by comparing to the "id" of a previously seen policy. There is no implied ordering of "id" fields between revisions.
o "id"（プレーンテキスト、必須）：ポリシーの更新を追跡するために使用される短い文字列。この文字列は、ポリシーの特定のインスタンスを一意に識別しなければなりません。これにより、送信者は、以前に表示されたポリシーの「id」と比較することにより、ポリシーがいつ更新されたかを判別できます。リビジョン間の暗黙の「id」フィールドの順序はありません。
An example TXT record is as below:
TXTレコードの例は次のとおりです。
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
The formal definition of the "_mta-sts" TXT record, defined using ABNF [RFC7405], is as follows:
ABNF [RFC7405]を使用して定義された "_mta-sts" TXTレコードの正式な定義は次のとおりです。
sts-text-record = sts-version 1*(sts-field-delim sts-field) [sts-field-delim]
sts-text-record = sts-version 1 *（sts-field-delim sts-field）[sts-field-delim]
sts-field = sts-id / ; Note that sts-id record sts-extension ; is required.
sts-field = sts-id /; sts-idレコードsts-extensionに注意してください。必要とされている。
sts-field-delim = *WSP ";" *WSP
sts-version = %s"v=STSv1"
sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=...
sts-extension = sts-ext-name "=" sts-ext-value ; name=value
sts-ext-name = (ALPHA / DIGIT)
*31(ALPHA / DIGIT / "_" / "-" / ".")
sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and CTLs
The TXT record MUST begin with the sts-version field; the order of other fields is not significant. If multiple TXT records for "_mta-sts" are returned by the resolver, records that do not begin with "v=STSv1;" are discarded. If the number of resulting records is not one, or if the resulting record is syntactically invalid, senders MUST assume the recipient domain does not have an available MTA-STS Policy and skip the remaining steps of policy discovery. (Note that the absence of a usable TXT record is not by itself sufficient to remove a sender's previously cached policy for the Policy Domain, as discussed in Section 5.1, "Policy Application Control Flow".) If the resulting TXT record contains multiple strings, then the record MUST be treated as if those strings are concatenated without adding spaces.
TXTレコードはsts-versionフィールドで始まる必要があります。他のフィールドの順序は重要ではありません。 「_mta-sts」の複数のTXTレコードがリゾルバーによって返された場合、「v = STSv1;」で始まらないレコード。破棄されます。結果のレコードの数が1でない場合、または結果のレコードが構文的に無効である場合、送信者は受信者のドメインに利用可能なMTA-STSポリシーがないと想定し、ポリシー検出の残りの手順をスキップする必要があります。 （使用可能なTXTレコードがない場合、セクション5.1「ポリシーアプリケーション制御フロー」で説明されているように、ポリシードメインの送信者の以前にキャッシュされたポリシーを削除するにはそれだけでは不十分です。）結果のTXTレコードに複数の文字列が含まれている場合、次に、レコードは、それらの文字列がスペースを追加せずに連結されているかのように扱われる必要があります。
The "_mta-sts" record MAY return a CNAME that points (directly or via other CNAMEs) to a TXT record, in which case senders MUST follow the CNAME pointers. This can be used for policy delegation, as described in Section 8.2.
「_mta-sts」レコードは、TXTレコードを（直接または他のCNAMEを介して）指すCNAMEを返す場合があります。その場合、送信者はCNAMEポインターに従う必要があります。これは、8.2項で説明されているように、ポリシー委任に使用できます。
The policy itself is a set of key/value pairs (similar to header fields in [RFC5322]) served via the HTTPS GET method from the fixed "well-known" [RFC5785] path of ".well-known/mta-sts.txt" served by the Policy Host. The Policy Host DNS name is constructed by prepending "mta-sts" to the Policy Domain.
ポリシー自体は、「。well-known / mta-sts」の固定された「既知の」[RFC5785]パスからHTTPS GETメソッドを介して提供される一連のキー/値ペア（[RFC5322]のヘッダーフィールドと同様）です。 txt」は、ポリシーホストによって提供されます。ポリシーホストDNS名は、ポリシードメインの前に「mta-sts」を付加することによって作成されます。
Thus, for a Policy Domain of "example.com", the full URL is "https://mta-sts.example.com/.well-known/mta-sts.txt".
したがって、「example.com」のポリシードメインの場合、完全なURLは「https://mta-sts.example.com/.well-known/mta-sts.txt」です。
When fetching a policy, senders SHOULD validate that the media type is "text/plain" to guard against cases where web servers allow untrusted users to host non-text content (typically, HTML or images) at a user-defined path. All parameters other than charset=utf-8 or charset=us-ascii are ignored. Additional "Content-Type" parameters are also ignored.
ポリシーをフェッチするとき、送信者はメディアタイプが「text / plain」であることを検証して、信頼できないユーザーがユーザー定義のパスで非テキストコンテンツ（通常、HTMLまたは画像）をホストできるようにするケースを防ぐ必要があります。 charset = utf-8またはcharset = us-ascii以外のすべてのパラメーターは無視されます。追加の「Content-Type」パラメーターも無視されます。
This resource contains the following CRLF-separated key/value pairs:
このリソースには、次のCRLF区切りのキーと値のペアが含まれています。
o "version": Currently, only "STSv1" is supported.
o 「バージョン」：現在、「STSv1」のみがサポートされています。
o "mode": One of "enforce", "testing", or "none", indicating the expected behavior of a Sending MTA in the case of a policy validation failure. See Section 5, "Policy Application", for more details about the three modes.
o "mode"： "enforce"、 "testing"、または "none"のいずれか。ポリシー検証に失敗した場合の送信MTAの予想される動作を示します。 3つのモードの詳細については、「ポリシーの適用」を参照してください。
o "max_age": Max lifetime of the policy (plaintext non-negative integer seconds, maximum value of 31557600). Well-behaved clients SHOULD cache a policy for up to this value from the last policy fetch time. To mitigate the risks of attacks at policy refresh time, it is expected that this value typically be in the range of weeks or greater.
o 「max_age」：ポリシーの最大存続時間（プレーンテキストの非負整数秒、最大値31557600）。正常に動作するクライアントは、最後のポリシーフェッチ時間からこの値までのポリシーをキャッシュする必要があります（SHOULD）。ポリシーの更新時の攻撃のリスクを軽減するために、この値は通常、数週間以上の範囲にあると予想されます。
o "mx": Allowed MX patterns. One or more patterns matching allowed MX hosts for the Policy Domain. As an example,
o "mx"：許可されたMXパターン。ポリシードメインで許可されたMXホストに一致する1つ以上のパターン。例として、
mx: mail.example.com <CRLF>
mx: *.example.net
indicates that mail for this domain might be handled by MX "mail.example.com" or any MX at "example.net". Valid patterns can be either fully specified names ("example.com") or suffixes prefixed by a wildcard ("*.example.net"). If a policy specifies more than one MX, each MX MUST have its own "mx:" key, and each MX key/value pair MUST be on its own line in the policy file. In the case of Internationalized Domain Names [RFC5891], the "mx" value MUST specify the Punycode-encoded A-label [RFC3492] to match against, and not the Unicode-encoded U-label. The full semantics of certificate validation (including the use of wildcard patterns) are described in Section 4.1, "MX Host Validation".
このドメインのメールはMX「mail.example.com」または「example.net」のMXによって処理される可能性があることを示します。有効なパターンは、完全に指定された名前（ "example.com"）またはワイルドカードを前に付けたサフィックス（ "* .example.net"）のいずれかです。ポリシーで複数のMXを指定する場合、各MXには独自の "mx："キーが必要であり、各MXキーと値のペアはポリシーファイル内の独自の行になければなりません。国際化ドメイン名[RFC5891]の場合、 "mx"値は、一致するPunycodeエンコードAラベル[RFC3492]を指定する必要があり、UnicodeエンコードUラベルは指定しません。証明書検証の完全なセマンティクス（ワイルドカードパターンの使用を含む）については、セクション4.1「MXホストの検証」で説明しています。
An example policy is as below:
ポリシーの例は次のとおりです。
version: STSv1 mode: enforce mx: mail.example.com mx: *.example.net mx: backupmx.example.com max_age: 604800
バージョン：STSv1モード：mxを強制：mail.example.com mx：* .example.net mx：backupmx.example.com max_age：604800
The formal definition of the policy resource, defined using ABNF [RFC7405], is as follows:
ABNF [RFC7405]を使用して定義されたポリシーリソースの正式な定義は次のとおりです。
sts-policy-record = sts-policy-field *WSP *(sts-policy-term sts-policy-field *WSP) [sts-policy-term]
sts-policy-record = sts-policy-field * WSP *（sts-policy-term sts-policy-field * WSP）[sts-policy-term]
sts-policy-field = sts-policy-version / ; required once
sts-policy-mode / ; required once
sts-policy-max-age / ; required once
sts-policy-mx /
; required at least once, except when
; mode is "none"
sts-policy-extension ; other fields
sts-policy-field-delim = ":" *WSP
sts-policy-version = sts-policy-version-field sts-policy-field-delim sts-policy-version-value
sts-policy-version = sts-policy-version-field sts-policy-field-delim sts-policy-version-value
sts-policy-version-field = %s"version"
sts-policy-version-value = %s"STSv1"
sts-policy-mode = sts-policy-mode-field sts-policy-field-delim sts-policy-mode-value
sts-policy-mode = sts-policy-mode-field sts-policy-field-delim sts-policy-mode-value
sts-policy-mode-field = %s"mode"
sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none"
sts-policy-mx = sts-policy-mx-field sts-policy-field-delim sts-policy-mx-value
sts-policy-mx = sts-policy-mx-field sts-policy-field-delim sts-policy-mx-value
sts-policy-mx-field = %s"mx"
sts-policy-mx-value = ["*."] Domain
sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim sts-policy-max-age-value
sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim sts-policy-max-age-value
sts-policy-max-age-field = %s"max_age"
sts-policy-max-age-value = 1*10(DIGIT)
sts-policy-extension = sts-policy-ext-name ; additional sts-policy-field-delim ; extension sts-policy-ext-value ; fields
sts-policy-extension = sts-policy-ext-name;追加のsts-policy-field-delim;拡張sts-policy-ext-value;田畑
sts-policy-ext-name = (sts-policy-alphanum)
*31(sta-policy-alphanum / "_" / "-" / ".")
sts-policy-term = LF / CRLF
sts-policy-ext-value = sts-policy-vchar
[*(%x20 / sts-policy-vchar)
sts-policy-vchar]
; chars, including UTF-8 [RFC3629],
; excluding CTLs and no
; leading/trailing spaces
sts-policy-alphanum = ALPHA / DIGIT
sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of [RFC3629]>
UTF8-3 = <Defined in Section 4 of [RFC3629]>
UTF8-4 = <Defined in Section 4 of [RFC3629]>
Domain = <Defined in Section 4.1.2 of [RFC5321]>
Parsers MUST accept TXT records and policy files that are syntactically valid (i.e., valid key/value pairs separated by semicolons for TXT records), possibly containing additional key/value pairs not specified in this document, in which case unknown fields SHALL be ignored. If any non-repeated field -- i.e., all fields excepting "mx" -- is duplicated, all entries except for the first SHALL be ignored.
パーサーは構文的に有効なTXTレコードおよびポリシーファイル（つまり、TXTレコードのセミコロンで区切られた有効なキー/値のペア）を受け入れる必要があります。このドキュメントで指定されていない追加のキー/値のペアを含む可能性があります。この場合、不明なフィールドは無視されます。繰り返されないフィールド、つまり「mx」以外のすべてのフィールドが重複している場合、最初のSHALLを除くすべてのエントリは無視されます。
Policy bodies are, as described above, retrieved by Sending MTAs via HTTPS [RFC2818]. During the TLS handshake initiated to fetch a new or updated policy from the Policy Host, the Policy Host HTTPS server MUST present an X.509 certificate that is valid for the "mta-sts" DNS-ID [RFC6125] (e.g., "mta-sts.example.com") as described below, chain to a root CA that is trusted by the Sending MTA, and be non-expired. It is expected that Sending MTAs use a set of trusted CAs similar to those in widely deployed web browsers and operating systems. See [RFC5280] for more details about certificate verification.
上記のように、ポリシー本体はHTTPS経由のMTAの送信によって取得されます[RFC2818]。ポリシーホストから新しいポリシーまたは更新されたポリシーをフェッチするために開始されたTLSハンドシェイク中に、ポリシーホストHTTPSサーバーは、「mta-sts」DNS-ID [RFC6125]に有効なX.509証明書（たとえば、「mta -sts.example.com "）以下に説明するように、送信側MTAによって信頼されているルートCAにチェーンし、期限切れにならないようにします。 MTAの送信では、広く展開されているWebブラウザーやオペレーティングシステムと同様の信頼できるCAのセットを使用することが期待されます。証明書の検証の詳細については、[RFC5280]を参照してください。
The certificate is valid for the Policy Host (i.e., "mta-sts" prepended to the Policy Domain) with respect to the rules described in [RFC6125], with the following application-specific considerations:
証明書は、[RFC6125]で説明されているルールに関して、ポリシーホスト（つまり、ポリシードメインの前に付加された「mta-sts」）に対して有効であり、次のアプリケーション固有の考慮事項があります。
o Matching is performed only against the DNS-ID identifiers.
o 照合は、DNS-ID識別子に対してのみ実行されます。
o DNS domain names in server certificates MAY contain the wildcard character '*' as the complete left-most label within the identifier.
o サーバー証明書のDNSドメイン名には、識別子内の完全な左端のラベルとしてワイルドカード文字「*」を含めることができます。
The certificate MAY be checked for revocation via the Online Certificate Status Protocol (OCSP) [RFC6960], certificate revocation lists (CRLs), or some other mechanism.
証明書は、オンライン証明書ステータスプロトコル（OCSP）[RFC6960]、証明書失効リスト（CRL）、またはその他のメカニズムを介して失効をチェックされる場合があります。
Policies fetched via HTTPS are only valid if the HTTP response code is 200 (OK). HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified in [RFC7234]) MUST NOT be used.
HTTPS経由でフェッチされたポリシーは、HTTP応答コードが200（OK）の場合にのみ有効です。 HTTP 3xxリダイレクトには従わず、HTTPキャッシング（[RFC7234]で指定）を使用してはなりません（MUST NOT）。
Senders may wish to rate-limit the frequency of attempts to fetch the HTTPS endpoint even if a valid TXT record for the recipient domain exists. In the case where the HTTPS GET fails, implementers SHOULD limit further attempts to a period of five minutes or longer per version ID, to avoid overwhelming resource-constrained recipients with cascading failures.
送信者は、受信者ドメインの有効なTXTレコードが存在する場合でも、HTTPSエンドポイントをフェッチする試行の頻度をレート制限したい場合があります。 HTTPS GETが失敗した場合、実装者はバージョンIDごとに5分以上の期間にそれ以上の試行を制限して、連鎖的に失敗してリソースに制約のある受信者を圧倒しないようにする必要があります。
Senders MAY impose a timeout on the HTTPS GET and/or a limit on the maximum size of the response body to avoid long delays or resource exhaustion during attempted policy updates. A suggested timeout is one minute, and a suggested maximum policy size is 64 kilobytes; Policy Hosts SHOULD respond to requests with a complete policy body within that timeout and size limit.
送信者は、HTTPS GETにタイムアウトを課したり、ポリシー本文の更新中に長時間の遅延やリソースの枯渇を回避するために、応答本文の最大サイズに制限を課したりする場合があります。推奨されるタイムアウトは1分で、推奨される最大ポリシーサイズは64キロバイトです。ポリシーホストは、そのタイムアウトとサイズ制限内で完全なポリシー本文を使用してリクエストに応答する必要があります（SHOULD）。
If a valid TXT record is found but no policy can be fetched via HTTPS (for any reason), and there is no valid (non-expired) previously cached policy, senders MUST continue with delivery as though the domain has not implemented MTA-STS.
有効なTXTレコードは見つかったが、何らかの理由でHTTPSを介してポリシーをフェッチできず、以前にキャッシュされた有効な（期限切れでない）ポリシーがない場合、送信者はドメインがMTA-STSを実装していないかのように配信を継続する必要があります。
Conversely, if no "live" policy can be discovered via DNS or fetched via HTTPS, but a valid (non-expired) policy exists in the sender's cache, the sender MUST apply that cached policy.
逆に、DNSを介して「ライブ」ポリシーを検出できない、またはHTTPSを介してフェッチできないが、有効な（期限切れでない）ポリシーが送信者のキャッシュに存在する場合、送信者はそのキャッシュされたポリシーを適用する必要があります。
Finally, to mitigate the risk of persistent interference with policy refresh, as discussed in-depth in Section 10, MTAs SHOULD proactively refresh cached policies before they expire; a suggested refresh frequency is once per day. To enable administrators to discover problems with policy refresh, MTAs SHOULD alert administrators (through the use of logs or similar) when such attempts fail, unless the cached policy mode is "none".
最後に、セクション10で詳細に説明されているように、ポリシーの更新に対する永続的な干渉のリスクを軽減するために、MTAはキャッシュされたポリシーが期限切れになる前に事前に更新する必要があります。推奨される更新頻度は1日1回です。管理者がポリシーの更新に関する問題を発見できるように、キャッシュポリシーモードが "none"でない限り、MTAはそのような試みが失敗したときに（ログなどを使用して）管理者に警告する必要があります（SHOULD）。
When sending mail via a "smart host" -- an administratively configured intermediate SMTP relay, which is different from the message recipient's server as determined from DNS -- compliant senders MUST treat the smart host domain as the Policy Domain for the purposes of policy discovery and application. This specification does not provide a means of associating policies with email addresses that employ Address Literals [RFC5321].
「スマートホスト」を介してメールを送信する場合-DNSから決定されるメッセージ受信者のサーバーとは異なる、管理上設定された中間SMTPリレー-準拠する送信者は、ポリシー検出のためにスマートホストドメインをポリシードメインとして扱う必要がありますとアプリケーション。この仕様は、アドレスリテラル[RFC5321]を使用する電子メールアドレスにポリシーを関連付ける手段を提供しません。
When sending mail to a mailbox at a subdomain, compliant senders MUST NOT attempt to fetch a policy from the parent zone. Thus, for mail sent to "user@mail.example.com", the policy can be fetched only from "mail.example.com", not "example.com".
サブドメインのメールボックスにメールを送信する場合、準拠する送信者は親ゾーンからポリシーをフェッチしてはなりません。したがって、「user@mail.example.com」に送信されたメールの場合、ポリシーは「mail.example.com」からのみフェッチでき、「example.com」からはフェッチできません。
When sending to an MX at a domain for which the sender has a valid and non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS MUST check whether:
送信者が有効で有効期限が切れていないMTA-STSポリシーを持っているドメインでMXに送信する場合、MTA-STSを尊重する送信MTAは、以下を確認する必要があります。
1. At least one of the policy's "mx" patterns matches the selected MX host, as described in Section 4.1, "MX Host Validation".
1. 4.1項「MXホストの検証」で説明されているように、ポリシーの「mx」パターンの少なくとも1つが選択されたMXホストと一致します。
2. The recipient mail server supports STARTTLS and offers a PKIX-based TLS certificate, during TLS handshake, which is valid for that host, as described in Section 4.2, "Recipient MTA Certificate Validation".
2. 受信者のメールサーバーはSTARTTLSをサポートし、TLSハンドシェイク中にPKIXベースのTLS証明書を提供します。これは、4.2項「受信者MTA証明書の検証」で説明されているように、そのホストに有効です。
When these conditions are not met, a policy is said to fail to validate. This section does not dictate the behavior of Sending MTAs when the above conditions are not met; see Section 5, "Policy Application", for a description of Sending MTA behavior when policy validation fails.
これらの条件が満たされない場合、ポリシーは検証に失敗したと言われます。このセクションでは、上記の条件が満たされていない場合のMTA送信の動作については説明しません。ポリシーの検証に失敗した場合のMTA送信動作の説明については、「ポリシーの適用」を参照してください。
A receiving candidate MX host is valid according to an applied MTA-STS Policy if the MX record name matches one or more of the "mx" fields in the applied policy. Matching is identical to the rules given in [RFC6125], with the restriction that the wildcard character '*' may only be used to match the entire left-most label in the presented identifier. Thus, the mx pattern "*.example.com" matches "mail.example.com" but not "example.com" or "foo.bar.example.com".
MXレコード名が適用されたポリシーの「mx」フィールドの1つ以上と一致する場合、適用されたMTA-STSポリシーに従って、受信候補MXホストは有効です。マッチングは、[RFC6125]で規定されているルールと同じですが、ワイルドカード文字「*」は、提示された識別子の左端のラベル全体とのマッチングにのみ使用できるという制限があります。したがって、mxパターン「* .example.com」は「mail.example.com」に一致しますが、「example.com」や「foo.bar.example.com」には一致しません。
The certificate presented by the receiving MTA MUST not be expired and MUST chain to a root CA that is trusted by the Sending MTA. The certificate MUST have a subject alternative name (SAN) [RFC5280] with a DNS-ID [RFC6125] matching the hostname, per the rules given in [RFC6125]. The MX's certificate MAY also be checked for revocation via OCSP [RFC6960], CRLs [RFC6818], or some other mechanism.
受信側MTAによって提示された証明書は期限切れになってはならず（MUST）、送信側MTAによって信頼されているルートCAにチェーンしなければなりません（MUST）。証明書には、[RFC6125]で規定されているルールに従って、ホスト名と一致するDNS-ID [RFC6125]のサブジェクト代替名（SAN）[RFC5280]が必要です。 MXの証明書は、OCSP [RFC6960]、CRL [RFC6818]、またはその他のメカニズムを介して失効をチェックされる場合があります。
When sending to an MX at a domain for which the sender has a valid, non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS applies the result of a policy validation failure in one of two ways, depending on the value of the policy "mode" field:
送信者が有効で有効期限が切れていないMTA-STSポリシーを持っているドメインでMXに送信する場合、MTA-STSを尊重する送信MTAは、ポリシー検証エラーの結果を、次のいずれかの方法で適用します。ポリシーの「モード」フィールド：
1. "enforce": In this mode, Sending MTAs MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS.
1. "enforce"：このモードでは、MTAの送信は、MXマッチングまたは証明書の検証に失敗した、またはSTARTTLSをサポートしていないホストにメッセージを配信してはなりません（MUST NOT）。
2. "testing": In this mode, Sending MTAs that also implement the TLSRPT (TLS Reporting) specification [RFC8460] send a report indicating policy application failures (as long as TLSRPT is also implemented by the recipient domain); in any case, messages may be delivered as though there were no MTA-STS validation failure.
2. 「テスト」：このモードでは、TLSRPT（TLSレポート）仕様[RFC8460]も実装するMTAを送信すると、ポリシーアプリケーションの失敗を示すレポートが送信されます（TLSRPTも受信者ドメインによって実装されている限り）。いずれの場合も、MTA-STS検証エラーがなかったかのようにメッセージが配信されます。
3. "none": In this mode, Sending MTAs should treat the Policy Domain as though it does not have any active policy; see Section 8.3, "Removing MTA-STS", for use of this mode value.
3. "none"：このモードでは、MTAを送信すると、ポリシードメインはアクティブなポリシーがないかのように扱われます。このモードの値の使用については、8.3項「MTA-STSの削除」を参照してください。
When a message fails to deliver due to an "enforce" policy, a compliant MTA MUST NOT permanently fail to deliver messages before checking, via DNS, for the presence of an updated policy at the Policy Domain. (In all cases, MTAs SHOULD treat such failures as transient errors and retry delivery later.) This allows implementing domains to update long-lived policies on the fly.
「強制」ポリシーが原因でメッセージの配信に失敗した場合、準拠するMTAは、ポリシードメインで更新されたポリシーの存在をDNS経由で確認する前に、メッセージの配信に永続的に失敗してはなりません。 （すべての場合において、MTAはそのような障害を一時的なエラーとして扱い、後で配信を再試行する必要があります。）これにより、ドメインを実装して、長期間有効なポリシーをその場で更新できます。
An example control flow for a compliant sender consists of the following steps:
準拠する送信者の制御フローの例は、次のステップで構成されています。
1. Check for a cached policy whose time-since-fetch has not exceeded its "max_age". If none exists, attempt to fetch a new policy (perhaps asynchronously, so as not to block message delivery). Optionally, Sending MTAs may unconditionally check for a new policy at this step.
1. フェッチ以降の時間が「max_age」を超えていないキャッシュされたポリシーを確認します。存在しない場合は、新しいポリシーのフェッチを試みます（メッセージの配信をブロックしないように、おそらく非同期に）。オプションで、MTAを送信すると、このステップで新しいポリシーが無条件にチェックされる場合があります。
2. For each candidate MX, in order of MX priority, attempt to deliver the message. If a policy is present with an "enforce" mode, when attempting to deliver to each candidate MX, ensure STARTTLS support and host identity validity as described in Section 4, "Policy Validation". If a candidate fails validation, continue to the next candidate (if there is one).
2. 各候補MXについて、MX優先順位の順に、メッセージの配信を試みます。ポリシーが「強制」モードで存在する場合、各候補MXに配信しようとするときに、セクション4「ポリシーの検証」で説明されているように、STARTTLSサポートとホストIDの妥当性を確認します。候補が検証に失敗した場合は、次の候補（存在する場合）に進みます。
3. A message delivery attempt MUST NOT be permanently failed until the sender has first checked for the presence of a new policy (as indicated by the "id" field in the "_mta-sts" TXT record). If a new policy is not found, existing rules for the case of temporary message delivery failures apply (as discussed in [RFC5321], Section 4.5.4.1).
3. 送信者が新しいポリシーの存在を最初に確認するまで（ "_mta-sts" TXTレコードの "id"フィールドで示されるように）、メッセージ配信の試みは永久に失敗してはなりません（MUST NOT）。新しいポリシーが見つからない場合は、一時的なメッセージ配信の失敗に関する既存のルールが適用されます（[RFC5321]のセクション4.5.4.1で説明）。
MTA-STS is intended to be used along with TLSRPT [RFC8460] in order to ensure that implementing domains can detect cases of both benign and malicious failures and to ensure that failures that indicate an active attack are discoverable. As such, senders that also implement TLSRPT SHOULD treat the following events as reportable failures:
MTA-STSはTLSRPT [RFC8460]とともに使用することを目的としており、実装ドメインが良性と悪意の両方の障害のケースを確実に検出し、アクティブな攻撃を示す障害を検出できるようにします。そのため、TLSRPTも実装する送信者は、以下のイベントを報告可能な障害として扱う必要があります（SHOULD）。
o HTTPS policy fetch failures when a valid TXT record is present.
o 有効なTXTレコードが存在する場合のHTTPSポリシーフェッチの失敗。
o Policy fetch failures of any kind when a valid policy exists in the policy cache, except if that policy's mode is "none".
o 有効なポリシーがポリシーキャッシュに存在する場合、そのポリシーのモードが「なし」の場合を除き、あらゆる種類のポリシーフェッチエラー。
o Delivery attempts in which a contacted MX does not support STARTTLS or does not present a certificate that validates according to the applied policy, except if that policy's mode is "none".
o 連絡されたMXがSTARTTLSをサポートしていないか、適用されたポリシーに従って検証する証明書を提示しない配信の試み（そのポリシーのモードが「なし」の場合を除く）。
To ensure that the server sends the right certificate chain, the SMTP client MUST have support for the TLS Server Name Indication (SNI) extension [RFC6066]. When connecting to an HTTP server to retrieve the MTA-STS Policy, the SNI extension MUST contain the name of the Policy Host (e.g., "mta-sts.example.com"). When connecting to an SMTP server, the SNI extension MUST contain the MX hostname.
サーバーが正しい証明書チェーンを送信するようにするには、SMTPクライアントがTLSサーバー名表示（SNI）拡張[RFC6066]をサポートしている必要があります。 MTA-STSポリシーを取得するためにHTTPサーバーに接続する場合、SNI拡張にはポリシーホストの名前（たとえば、「mta-sts.example.com」）が含まれている必要があります。 SMTPサーバーに接続する場合、SNI拡張にはMXホスト名が含まれている必要があります。
HTTP servers used to deliver MTA-STS policies MAY rely on SNI to determine which certificate chain to present to the client. HTTP servers MUST respond with a certificate chain that matches the policy hostname or abort the TLS handshake if unable to do so. Clients that do not send SNI information may not see the expected certificate chain.
MTA-STSポリシーの配信に使用されるHTTPサーバーは、クライアントに提示する証明書チェーンを決定するためにSNIに依存する場合があります。 HTTPサーバーは、ポリシーのホスト名と一致する証明書チェーンで応答するか、応答できない場合はTLSハンドシェイクを中止する必要があります。 SNI情報を送信しないクライアントは、期待される証明書チェーンを表示しない場合があります。
SMTP servers MAY rely on SNI to determine which certificate chain to present to the client. However, servers that have one identity and a single matching certificate do not require SNI support. Servers MUST NOT enforce the use of SNI by clients, as the client may be using unauthenticated opportunistic TLS and may not expect any particular certificate from the server. If the client sends no SNI extension or sends an SNI extension for an unsupported server name, the server MUST simply send a fallback certificate chain of its choice. The reason for not enforcing strict matching of the requested SNI hostname is that MTA-STS TLS clients may be typically willing to accept multiple server names but can only send one name in the SNI extension. The server's fallback certificate may match a different name that is acceptable to the client, e.g., the original next-hop domain.
SMTPサーバーは、クライアントに提示する証明書チェーンを決定するためにSNIに依存する場合があります。ただし、1つのIDと1つの一致する証明書を持つサーバーは、SNIサポートを必要としません。クライアントは認証されていない便宜的なTLSを使用している可能性があり、サーバーからの特定の証明書を期待できないため、サーバーはクライアントによるSNIの使用を強制してはなりません。クライアントがSNI拡張を送信しない場合、またはサポートされていないサーバー名のSNI拡張を送信する場合、サーバーは選択したフォールバック証明書チェーンを送信する必要があります。要求されたSNIホスト名の厳密な一致を強制しない理由は、MTA-STS TLSクライアントは通常、複数のサーバー名を受け入れても、SNI拡張で1つの名前しか送信できないためです。サーバーのフォールバック証明書は、元のネクストホップドメインなど、クライアントが受け入れ可能な別の名前と一致する場合があります。
MTAs supporting MTA-STS MUST have support for TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] or higher. The general TLS usage guidance in [RFC7525] SHOULD be followed.
MTA-STSをサポートするMTAは、TLS 1.2 [RFC5246]またはTLS 1.3 [RFC8446]以降をサポートする必要があります。 [RFC7525]の一般的なTLSの使用ガイダンスに従う必要があります。
Updating the policy requires that the owner make changes in two places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and at the corresponding HTTPS endpoint. As a result, recipients should expect that a policy will continue to be used by senders until both the HTTPS and TXT endpoints are updated and the TXT record's TTL has passed.
ポリシーを更新するには、所有者が2つの場所で変更を行う必要があります。ポリシードメインのDNSゾーンと対応するHTTPSエンドポイントの "_mta-sts" TXTレコードです。その結果、受信者は、HTTPSとTXTの両方のエンドポイントが更新され、TXTレコードのTTLが経過するまで、ポリシーが送信者によって引き続き使用されることを期待する必要があります。
In other words, a sender who is unable to successfully deliver a message while applying a cache of the recipient's now-outdated policy may be unable to discover that a new policy exists until the DNS TTL has passed. Recipients SHOULD therefore ensure that old policies continue to work for message delivery during this period of time, or risk message delays.
つまり、受信者の現在古いポリシーのキャッシュを適用しているときにメッセージを正常に配信できない送信者は、DNS TTLが経過するまで新しいポリシーが存在することを発見できない場合があります。したがって、受信者は、この期間中、古いポリシーがメッセージ配信に対して引き続き機能することを確認してください。そうしないと、メッセージの遅延が発生する可能性があります。
Recipients SHOULD also update the HTTPS policy body before updating the TXT record; this ordering avoids the risk that senders, seeing a new TXT record, mistakenly cache the old policy from HTTPS.
受信者は、TXTレコードを更新する前にHTTPSポリシー本体も更新する必要があります（SHOULD）。この順序により、送信者が新しいTXTレコードを見て、誤って古いポリシーをHTTPSからキャッシュするリスクを回避できます。
Domain owners commonly delegate SMTP hosting to a different organization, such as an ISP or a web host. In such a case, they may wish to also delegate the MTA-STS Policy to the same organization, which can be accomplished with two changes.
ドメイン所有者は、通常、SMTPホスティングをISPやWebホストなどの別の組織に委任します。そのような場合、MTA-STSポリシーを同じ組織に委任することもできます。これは、2つの変更で実現できます。
First, the Policy Domain must point the "_mta-sts" record, via CNAME, to the "_mta-sts" record maintained by the provider. This allows the provider to control update signaling.
まず、ポリシードメインは、CNAMEを介して「_mta-sts」レコードを、プロバイダーが保持する「_mta-sts」レコードにポイントする必要があります。これにより、プロバイダーは更新シグナリングを制御できます。
Second, the Policy Domain must point the "well-known" policy location to the provider. This can be done either by setting the "mta-sts" record to an IP address or CNAME specified by the provider and by giving the provider a TLS certificate that is valid for that host or by setting up a "reverse proxy" (also known as a "gateway") server for the Policy Domain's Policy Host, configured to serve proxied responses from the Policy Host of the provider.
次に、ポリシードメインは、「既知の」ポリシーの場所をプロバイダーにポイントする必要があります。これは、プロバイダーが指定したIPアドレスまたはCNAMEに「mta-sts」レコードを設定し、そのホストに有効なTLS証明書をプロバイダーに提供するか、「リバースプロキシ」（別名プロバイダーのポリシーホストからのプロキシされた応答を提供するように構成された、ポリシードメインのポリシーホスト用の「ゲートウェイ」サーバー）。
For example, given a user domain "user.example" hosted by a mail provider "provider.example", the following configuration would allow policy delegation:
たとえば、メールプロバイダー「provider.example」によってホストされるユーザードメイン「user.example」が与えられた場合、次の構成ではポリシーの委任が許可されます。
DNS:
DNS：
_mta-sts.user.example. IN CNAME _mta-sts.provider.example.
_mta-sts.user.example。 IN CNAME _mta-sts.provider.example。
Policy:
ポリシー：
> GET /.well-known/mta-sts.txt Host: mta-sts.user.example
< HTTP/1.1 200 OK # Response proxies content from
# https://mta-sts.provider.example
Note that in all such cases, the policy endpoint ("https://mta-sts.user.example/.well-known/mta-sts.txt" in this example) must still present a certificate valid for the Policy Host ("mta-sts.user.example"), and not for that host at the provider's domain ("mta-sts.provider.example").
このような場合はすべて、ポリシーエンドポイント（この例では「https：//mta-sts.user.example/.well-known/mta-sts.txt」）がポリシーホスト（ "mta-sts.user.example"）、およびプロバイダーのドメインにあるそのホスト（ "mta-sts.provider.example"）ではありません。
Note that while Sending MTAs MUST NOT use HTTP caching when fetching policies via HTTPS, such caching may nonetheless be useful to a reverse proxy configured as described in this section. An HTTPS policy endpoint expecting to be proxied for multiple hosted domains -- as with a large mail hosting provider or similar -- may wish to indicate an HTTP Cache-Control "max-age" response directive (as specified in [RFC7234]) of 60 seconds as a reasonable value to save reverse proxies an unnecessarily high-rate of proxied policy fetching.
MTAの送信では、HTTPSを介してポリシーをフェッチするときにHTTPキャッシングを使用してはならないことに注意してください。ただし、このようなキャッシングは、このセクションで説明するように構成されたリバースプロキシに役立つ場合があります。大規模なメールホスティングプロバイダーなどと同様に、複数のホステッドドメインでプロキシされることを期待しているHTTPSポリシーエンドポイントは、（[RFC7234]で指定されている）HTTP Cache-Control "max-age"応答ディレクティブを示すことができます。リバースプロキシを節約するための妥当な値として60秒。プロキシポリシーのフェッチが不必要に高速になる。
In order to facilitate clean opt-out of MTA-STS by implementing Policy Domains, and to distinguish clearly between failures that indicate attacks and those that indicate such opt-outs, MTA-STS implements the "none" mode, which allows validated policies to indicate authoritatively that the Policy Domain wishes to no longer implement MTA-STS and may, in the future, remove the MTA-STS TXT and policy endpoints entirely.
MTA-STSは、ポリシードメインを実装することでMTA-STSのクリーンなオプトアウトを容易にし、攻撃を示す障害とそのようなオプトアウトを示す障害を明確に区別するために、検証されたポリシーを許可する「なし」モードを実装します。ポリシードメインがMTA-STSを実装しないことを望んでおり、将来的にはMTA-STS TXTとポリシーエンドポイントを完全に削除する可能性があることを正式に示します。
A suggested workflow to implement such an opt out is as follows:
このようなオプトアウトを実装するための推奨ワークフローは次のとおりです。
1. Publish a new policy with "mode" equal to "none" and a small "max_age" (e.g., one day).
1. 「モード」が「なし」で、小さい「max_age」（1日など）の新しいポリシーを公開します。
2. Publish a new TXT record to trigger fetching of the new policy.
2. 新しいTXTレコードを発行して、新しいポリシーのフェッチをトリガーします。
3. When all previously served policies have expired -- normally this is the time the previously published policy was last served plus that policy's "max_age", but note that policies older than the previously published policy may have been served with a greater "max_age" than the previously published policy, allowing overlapping policy caches -- safely remove the TXT record and HTTPS endpoint.
3. 以前に提供されたすべてのポリシーの有効期限が切れた場合-通常、これは以前に公開されたポリシーが最後に提供された時間とそのポリシーの「max_age」です。ただし、以前に公開されたポリシーより古いポリシーは、以前に発行されたポリシー、重複するポリシーキャッシュを許可-TXTレコードとHTTPSエンドポイントを安全に削除します。
Implementers of send-time MTA-STS validation in mail transfer agents should take note of the risks of modifying the logic of traversing MX candidate lists. Because an MTA-STS Policy can be used to prefilter invalid MX candidates from the MX candidate list, it is tempting to implement a "two-pass" model, where MX candidates are first filtered for possible validity according to the MTA-STS Policy, and then the remaining candidates are attempted in order as without an MTA-STS Policy. This may lead to incorrect implementations, such as message loops; instead, it is recommended that implementers traverse the MX candidate list as usual, and treat invalid candidates as though they were unreachable (i.e., as though there were some transient error when trying to deliver to that candidate).
メール転送エージェントでの送信時MTA-STS検証の実装者は、MX候補リストを走査するロジックを変更するリスクに注意する必要があります。 MTA-STSポリシーを使用して、MX候補リストから無効なMX候補を事前にフィルタリングできるため、「2パス」モデルを実装するのは魅力的です。次に、MTA-STSポリシーがない場合と同様に、残りの候補者が順番に試行されます。これにより、メッセージループなどの不正な実装が発生する可能性があります。代わりに、実装者は通常どおりMX候補リストをトラバースし、無効な候補を到達不能である（つまり、その候補に配信しようとしたときに一時的なエラーが発生したかのように）処理することをお勧めします。
One consequence of validating MX hosts in order of ordinary candidate traversal is that in the event a higher-priority MX is MTA-STS valid and a lower-priority MX is not, senders may never encounter the lower-priority MX, leading to a risk that policy misconfigurations that apply only to "backup" MXes may only be discovered in the case of primary MX failure.
通常の候補トラバーサルの順序でMXホストを検証することの1つの結果は、優先度の高いMXがMTA-STSで有効で、優先度の低いMXが有効でない場合、送信者は優先度の低いMXに遭遇することがなく、リスクにつながる可能性があります。 「バックアップ」MXにのみ適用されるポリシーの誤設定は、プライマリMXに障害が発生した場合にのみ検出される可能性があります。
A new "well-known" URI as described in Section 3 has been registered in the "Well-Known URIs" registry as described below:
セクション3で説明されている新しい「既知の」URIは、以下で説明されているように「既知のURI」レジストリに登録されています。
URI Suffix: mta-sts.txt
URIサフィックス：mta-sts.txt
Change Controller: IETF
コントローラの変更：IETF
IANA has created a new registry titled "MTA-STS TXT Record Fields". The initial entries in the registry are:
IANAは、「MTA-STS TXTレコードフィールド」という新しいレジストリを作成しました。レジストリの最初のエントリは次のとおりです。
+------------+--------------------+-------------------------+
| Field Name | Description | Reference |
+------------+--------------------+-------------------------+
| v | Record version | Section 3.1 of RFC 8461 |
| id | Policy instance ID | Section 3.1 of RFC 8461 |
+------------+--------------------+-------------------------+
New fields are added to this registry using IANA's "Expert Review" policy [RFC8126].
IANAの「エキスパートレビュー」ポリシー[RFC8126]を使用して、新しいフィールドがこのレジストリに追加されます。
IANA has created a new registry titled "MTA-STS Policy Fields". The initial entries in the registry are:
IANAは、「MTA-STSポリシーフィールド」という新しいレジストリを作成しました。レジストリの最初のエントリは次のとおりです。
+------------+----------------------+-------------------------+
| Field Name | Description | Reference |
+------------+----------------------+-------------------------+
| version | Policy version | Section 3.2 of RFC 8461 |
| mode | Enforcement behavior | Section 3.2 of RFC 8461 |
| max_age | Policy lifetime | Section 3.2 of RFC 8461 |
| mx | MX identities | Section 3.2 of RFC 8461 |
+------------+----------------------+-------------------------+
New fields are added to this registry using IANA's "Expert Review" policy.
IANAの「エキスパートレビュー」ポリシーを使用して、新しいフィールドがこのレジストリに追加されます。
SMTP MTA-STS attempts to protect against an active attacker trying to intercept or tamper with mail between hosts that support STARTTLS. There are two classes of attacks considered:
SMTP MTA-STSは、STARTTLSをサポートするホスト間のメールを傍受または改ざんしようとするアクティブな攻撃者からの保護を試みます。考慮される攻撃には2つのクラスがあります。
o Foiling TLS negotiation (for example, by deleting the "250 STARTTLS" response from a server or altering TLS session negotiation). This would result in the SMTP session occurring over plaintext, despite both parties supporting TLS.
o TLSネゴシエーションの失敗（たとえば、サーバーからの「250 STARTTLS」応答の削除またはTLSセッションネゴシエーションの変更による）。これにより、両者がTLSをサポートしているにもかかわらず、SMTPセッションがプレーンテキストで発生します。
o Impersonating the destination mail server, whereby the sender might deliver the message to an impostor, who could then monitor and/or modify messages despite opportunistic TLS. This impersonation could be accomplished by spoofing the DNS MX record for the recipient domain or by redirecting client connections intended for the legitimate recipient server (for example, by altering BGP routing tables).
o 送信先メールサーバーになりすまして、送信者がメッセージを詐称者に配信し、詐欺師は日和見的なTLSにもかかわらずメッセージを監視または変更できます。このなりすましは、受信者ドメインのDNS MXレコードをスプーフィングするか、正当な受信者サーバー向けのクライアント接続をリダイレクトすることによって（たとえば、BGPルーティングテーブルを変更することによって）実現できます。
MTA-STS can thwart such attacks only if the sender is able to previously obtain and cache a policy for the recipient domain, and only if the attacker is unable to obtain a valid certificate that complies with that policy. Below, we consider specific attacks on this model.
MTA-STSがこのような攻撃を阻止できるのは、送信者が以前に受信者ドメインのポリシーを取得してキャッシュでき、攻撃者がそのポリシーに準拠する有効な証明書を取得できない場合のみです。以下では、このモデルに対する特定の攻撃について検討します。
SMTP MTA-STS relies on certificate validation via PKIX-based TLS identity checking [RFC6125]. Attackers who are able to obtain a valid certificate for the targeted recipient mail service (e.g., by compromising a CA) are thus able to circumvent STS authentication.
SMTP MTA-STSは、PKIXベースのTLS IDチェック[RFC6125]による証明書検証に依存しています。標的となる受信者のメールサービスの有効な証明書を（たとえば、CAを侵害することによって）取得できる攻撃者は、STS認証を回避することができます。
Since MTA-STS uses DNS TXT records for policy discovery, an attacker who is able to block DNS responses can suppress the discovery of an MTA-STS Policy, making the Policy Domain appear not to have an MTA-STS Policy. The sender policy cache is designed to resist this attack by decreasing the frequency of policy discovery and thus reducing the window of vulnerability; it is nonetheless a risk that attackers who can predict or induce policy discovery -- for example, by inducing a sending domain to send mail to a never-before-contacted recipient while carrying out a man-in-the-middle attack -- may be able to foil policy discovery and effectively downgrade the security of the message delivery.
MTA-STSはポリシー検出にDNS TXTレコードを使用するため、DNS応答をブロックできる攻撃者はMTA-STSポリシーの検出を抑制し、ポリシードメインにMTA-STSポリシーがないように見せることができます。送信者ポリシーキャッシュは、ポリシー検出の頻度を減らし、脆弱性のウィンドウを減らすことにより、この攻撃に対抗するように設計されています。それでも、ポリシー検出を予測または誘導できる攻撃者は、たとえば、中間者攻撃を実行しているときに、これまで連絡されたことのない受信者にメールを送信するように送信ドメインを誘導することにより、リスクを冒す可能性があります。ポリシー検出を無効にし、メッセージ配信のセキュリティを効果的にダウングレードできます。
Since this attack depends upon intercepting initial policy discovery, implementers SHOULD prefer policy "max_age" values to be as long as is practical.
この攻撃は最初のポリシー検出のインターセプトに依存しているため、実装者は、ポリシーの「max_age」の値を実際的な限り長くすることを推奨する必要があります。
Because this attack is also possible upon refresh of a cached policy, implementers SHOULD NOT wait until a cached policy has expired before checking for an update; if senders attempt to refresh the cache regularly (for example, by fetching the current live policy in a background task that runs daily or weekly, regardless of the state of the "_mta-sts" TXT record, and updating their cache's "max age" accordingly), an attacker would have to foil policy discovery consistently over the lifetime of a cached policy to prevent a successful refresh.
この攻撃はキャッシュされたポリシーの更新時にも発生する可能性があるため、実装者は、キャッシュされたポリシーが期限切れになるまで待ってから更新を確認する必要があります。送信者が定期的にキャッシュを更新しようとした場合（たとえば、「_ mta-sts」TXTレコードの状態に関係なく、毎日または毎週実行されるバックグラウンドタスクで現在のライブポリシーをフェッチし、キャッシュの「最大経過時間」を更新するしたがって、攻撃者は、キャッシュされたポリシーの存続期間中、一貫してポリシーの検出を失敗させて、正常な更新を防ぐ必要があります。
Additionally, MTAs SHOULD alert administrators to repeated policy refresh failures long before cached policies expire (through warning logs or similar applicable mechanisms), allowing administrators to detect such a persistent attack on policy refresh. (However, they should not implement such alerts if the cached policy has a "none" mode, to allow clean MTA-STS removal, as described in Section 8.3.)
さらに、MTAは、キャッシュされたポリシーの有効期限が切れるずっと前に（警告ログまたは同様の適用可能なメカニズムによって）ポリシーの更新の失敗を繰り返し管理者に警告する必要があります（SHOULD）。 （ただし、セクション8.3で説明されているように、キャッシュされたポリシーに「none」モードがあり、クリーンなMTA-STS削除を許可する場合は、このようなアラートを実装しないでください。）
Resistance to downgrade attacks of this nature -- due to the ability to authoritatively determine "lack of a record" even for non-participating recipients -- is a feature of DANE, due to its use of DNSSEC for policy discovery.
この種のダウングレード攻撃への抵抗-参加していない受信者に対しても「レコードの欠如」を正式に決定できるため-は、ポリシー検出にDNSSECを使用しているため、DANEの機能です。
We additionally consider the Denial-of-Service risk posed by an attacker who can modify the DNS records for a recipient domain. Absent MTA-STS, such an attacker can cause a Sending MTA to cache invalid MX records, but only for however long the sending resolver caches those records. With MTA-STS, the attacker can additionally advertise a new, long "max_age" MTA-STS Policy with "mx" constraints that validate the malicious MX record, causing senders to cache the policy and refuse to deliver messages once the victim has resecured the MX records.
さらに、受信者ドメインのDNSレコードを変更できる攻撃者によってもたらされるサービス拒否のリスクについても検討します。 MTA-STSが存在しない場合、このような攻撃者は送信側MTAに無効なMXレコードをキャッシュさせる可能性がありますが、送信側リゾルバがそれらのレコードをキャッシュする期間だけです。 MTA-STSを使用すると、攻撃者は悪意のあるMXレコードを検証する「mx」制約付きの新しい長い「max_age」MTA-STSポリシーをさらにアドバタイズできるため、送信者はポリシーをキャッシュし、被害者がセキュリティで保護されたらメッセージの配信を拒否します。 MXレコード。
This attack is mitigated in part by the ability of a victim domain to (at any time) publish a new policy updating the cached, malicious policy, though this does require the victim domain to both obtain a valid CA-signed certificate and to understand and properly configure MTA-STS.
この攻撃は、被害を受けたドメインが（いつでも）キャッシュされた悪意のあるポリシーを更新する新しいポリシーを公開する機能によってある程度軽減されますが、被害を受けたドメインは有効なCA署名付き証明書を取得し、理解し、 MTA-STSを適切に構成します。
Similarly, we consider the possibility of domains that deliberately allow untrusted users to serve untrusted content on user-specified subdomains. In some cases (e.g., the service "tumblr.com"), this takes the form of providing HTTPS hosting of user-registered subdomains; in other cases (e.g. dynamic DNS providers), this takes the form of allowing untrusted users to register custom DNS records at the provider's domain.
同様に、信頼できないユーザーがユーザー指定のサブドメインで信頼できないコンテンツを提供することを意図的に許可するドメインの可能性を検討します。場合によっては（サービス「tumblr.com」など）、ユーザーが登録したサブドメインのHTTPSホスティングを提供する形になります。他のケース（動的DNSプロバイダーなど）では、これは信頼できないユーザーがプロバイダーのドメインでカスタムDNSレコードを登録できるようにするという形を取ります。
In these cases, there is a risk that untrusted users would be able to serve custom content at the "mta-sts" host, including serving an illegitimate MTA-STS Policy. We believe this attack is rendered more difficult by the need for the attacker to also serve the "_mta-sts" TXT record on the same domain -- something not, to our knowledge, widely provided to untrusted users. This attack is additionally mitigated by the aforementioned ability for a victim domain to update an invalid policy at any future date.
これらの場合、信頼できないユーザーが、不正なMTA-STSポリシーの提供を含め、「mta-sts」ホストでカスタムコンテンツを提供できるリスクがあります。攻撃者が同じドメインで "_mta-sts" TXTレコードも提供する必要があるため、この攻撃はより困難になると私たちは信じています。この攻撃は、被害者のドメインが無効なポリシーを将来更新する前述の機能によってさらに緩和されます。
Even if an attacker cannot modify a served policy, the potential exists for configurations that allow attackers on the same domain to receive mail for that domain. For example, an easy configuration option when authoring an MTA-STS Policy for "example.com" is to set the "mx" equal to "*.example.com"; in this case, recipient domains must consider the risk that any user possessing a valid hostname and CA-signed certificate (for example, "dhcp-123.example.com") will, from the perspective of MTA-STS Policy validation, be a valid MX host for that domain.
攻撃者がサービスポリシーを変更できない場合でも、同じドメインの攻撃者がそのドメインのメールを受信できるようにする構成が存在する可能性があります。たとえば、「example.com」のMTA-STSポリシーを作成するときの簡単な設定オプションは、「mx」を「* .example.com」に設定することです。この場合、受信者のドメインは、MTA-STSポリシー検証の観点から、有効なホスト名とCA署名付き証明書（たとえば、「dhcp-123.example.com」）を所有するユーザーがそのドメインの有効なMXホスト。
A number of risks apply to the PKI system that is used for certificate authentication, both of the "mta-sts" HTTPS host's certificate and the SMTP servers' certificates. These risks are broadly applicable within the Web PKI ecosystem and are not specific to MTA-STS; nonetheless, they deserve some consideration in this context.
証明書認証に使用されるPKIシステムには、「mta-sts」HTTPSホストの証明書とSMTPサーバーの証明書の両方のリスクがいくつかあります。これらのリスクは、Web PKIエコシステム内で広く適用され、MTA-STSに固有のものではありません。それにもかかわらず、彼らはこの文脈でいくらかの考慮に値する。
Broadly speaking, attackers may compromise the system by obtaining certificates under fraudulent circumstances (i.e., by impersonating the legitimate owner of the victim domain), by compromising a CA or Delegate Authority's private keys, by obtaining a legitimate certificate issued to the victim domain, and similar.
大まかに言えば、攻撃者は、詐欺的な状況下で（つまり、被害者ドメインの正当な所有者になりすまして）証明書を取得し、被害者ドメインに発行された正当な証明書を入手して、システムを侵害する可能性があります。同様。
One approach commonly employed by web browsers to help mitigate against some of these attacks is to allow for revocation of compromised or fraudulent certificates via OCSP [RFC6960] or CRLs [RFC6818]. Such mechanisms themselves represent trade-offs and are not universally implemented; we nonetheless recommend implementers of MTA-STS to implement revocation mechanisms that are most applicable to their implementations.
これらの攻撃の一部を軽減するためにWebブラウザーで一般的に採用されているアプローチの1つは、OCSP [RFC6960]またはCRL [RFC6818]を介して、侵害された証明書または不正な証明書を取り消すことです。このようなメカニズム自体はトレードオフを表しており、普遍的に実装されているわけではありません。それにもかかわらず、MTA-STSの実装者には、その実装に最も適用可能な失効メカニズムを実装することをお勧めします。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3207] Hoffman、P。、「Secure SMTP over Transport Layer SecurityのSMTPサービス拡張」、RFC 3207、DOI 10.17487 / RFC3207、2002年2月、<https://www.rfc-editor.org/info/rfc3207>。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, <https://www.rfc-editor.org/info/rfc3492>.
[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、DOI 10.17487 / RFC3492、2003年3月、<https://www.rfc-editor.org / info / rfc3492>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5280] 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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<https://www.rfc-editor.org/info/rfc5321>。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.
[RFC5785]ノッティンガム、M。およびE.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、DOI 10.17487 / RFC5785、2010年4月、<https://www.rfc-editor.org / info / rfc5785>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https://www.rfc-editor.org/info/rfc6066> 。
[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, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405] Kyzivat、P。、「ABNFでの大文字と小文字を区別する文字列のサポート」、RFC 7405、DOI 10.17487 / RFC7405、2014年12月、<https://www.rfc-editor.org/info/rfc7405>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[RFC8460] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., and M. Risher, "SMTP TLS Reporting", RFC 8460, DOI 10.17487/RFC8460, September 2018, <https://www.rfc-editor.org/info/rfc8460>.
[RFC8460]マーゴリス、D。、ブロトマン、A。、ラマクリシュナン、B。、ジョーンズ、J。、およびM.リシャー、「SMTP TLSレポート」、RFC 8460、DOI 10.17487 / RFC8460、2018年9月、<https：// www.rfc-editor.org/info/rfc8460>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https： //www.rfc-editor.org/info/rfc4033>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https://www.rfc-editor.org/info/rfc5322>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<https://www.rfc-editor.org/info/rfc5891>。
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 2013, <https://www.rfc-editor.org/info/rfc6818>.
[RFC6818] Yee、P。、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profiles」の更新、RFC 6818、DOI 10.17487 / RFC6818、2013年1月、<https：//www.rfc- editor.org/info/rfc6818>。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、and C. Adams、 "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP"、RFC 6960、DOI 10.17487 / RFC6960、2013年6月、<https://www.rfc-editor.org/info/rfc6960>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<https://www.rfc-editor.org/info/rfc7234>。
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, <https://www.rfc-editor.org/info/rfc7672>.
[RFC7672] Dukhovni、V。およびW. Hardaker、「名前付きエンティティの便宜的なDNSベースの認証（DANE）トランスポート層セキュリティ（TLS）によるSMTPセキュリティ」、RFC 7672、DOI 10.17487 / RFC7672、2015年10月、<https：/ /www.rfc-editor.org/info/rfc7672>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
The owner of "example.com" wishes to begin using MTA-STS with a policy that will solicit reports from senders without affecting how the messages are processed, in order to verify the identity of MXes that handle mail for "example.com", confirm that TLS is correctly used, and ensure that certificates presented by the recipient MX validate.
「example.com」の所有者は、「example.com」のメールを処理するMXのIDを確認するために、メッセージの処理方法に影響を与えずに送信者からのレポートを求めるポリシーでMTA-STSの使用を開始したいと考えています。 TLSが正しく使用されていることを確認し、受信者MXによって提示された証明書が検証されることを確認します。
MTA-STS Policy indicator TXT RR:
MTA-STSポリシーインジケーターTXT RR：
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
MTA-STS Policy file served as the response body at "https://mta-sts.example.com/.well-known/mta-sts.txt":
「https://mta-sts.example.com/.well-known/mta-sts.txt」で応答本文として機能するMTA-STSポリシーファイル：
version: STSv1 mode: testing mx: mx1.example.com mx: mx2.example.com mx: mx.backup-example.com max_age: 1296000
バージョン：STSv1モード：テストmx：mx1.example.com mx：mx2.example.com mx：mx.backup-example.com max_age：1296000
Below is pseudocode demonstrating the logic of a compliant Sending MTA.
以下は、準拠する送信MTAのロジックを示す疑似コードです。
While this pseudocode implementation suggests synchronous policy retrieval in the delivery path, that may be undesirable in a working implementation, and we expect some implementers to instead prefer a background fetch that does not block delivery when no cached policy is present.
この疑似コードの実装は、配信パスでの同期ポリシー取得を示唆していますが、実際の実装では望ましくない場合があり、キャッシュされたポリシーが存在しない場合、配信をブロックしないバックグラウンドフェッチを代わりに使用することを実装者が期待しています。
func isEnforce(policy) {
// Return true if the policy mode is "enforce".
}
func isNonExpired(policy) {
// Return true if the policy is not expired.
}
func tryStartTls(connection) {
// Attempt to open an SMTP STARTTLS connection with the MX.
}
func certMatches(connection, host) {
func certMatches（connection、host）{
// Assume a handy function to return if the server
// certificate presented in "connection" is valid for "host".
}
func policyMatches(candidate, policy) {
for mx in policy.mx {
// Literal match.
if mx == candidate {
return true
}
// Wildcard matches only the leftmost label.
// Wildcards must always be followed by a '.'.
if mx[0] == '*' {
parts = SplitN(candidate, '.', 2) // Split on the first '.'.
if len(parts) > 1 && parts[1] == mx[2:] {
return true
}
}
}
return false
}
func tryDeliverMail(connection, message) {
// Attempt to deliver "message" via "connection".
}
func tryGetNewPolicy(domain) {
// Check for an MTA-STS TXT record for "domain" in DNS, and return
// the indicated policy.
}
func cachePolicy(domain, policy) {
// Store "policy" as the cached policy for "domain".
}
func tryGetCachedPolicy(domain) {
// Return a cached policy for "domain".
}
func reportError(error) {
// Report an error via TLSRPT.
}
func tryMxAccordingTo(message, mx, policy) {
connection := connect(mx)
if !connection {
return false // Can't connect to the MX, so it's not an MTA-STS
// error.
}
secure := true
if !policyMatches(mx, policy) {
secure = false
reportError(E_HOST_MISMATCH)
} else if !tryStartTls(connection) {
secure = false
reportError(E_NO_VALID_TLS)
} else if !certMatches(connection, policy) {
secure = false
reportError(E_CERT_MISMATCH)
}
if secure || !isEnforce(policy) {
return tryDeliverMail(connection, message)
}
return false
}
func tryWithPolicy(message, domain, policy) {
mxes := getMxForDomain(domain)
for mx in mxes {
if tryMxAccordingTo(message, mx, policy) {
return true
}
}
return false
}
func handleMessage(message) {
domain := ... // domain part after '@' from recipient
policy := tryGetNewPolicy(domain)
if policy {
cachePolicy(domain, policy)
} else {
policy = tryGetCachedPolicy(domain)
}
if policy {
return tryWithPolicy(message, domain, policy)
}
// Try to deliver the message normally (i.e., without MTA-STS).
}
Contributors
貢献者
Wei Chuang Google, Inc. weihaw@google.com
Wei C Huang Google、Inc.はHawen@Google.comです
Viktor Dukhovni ietf-dane@dukhovni.de
Victor Dukhovni itf-dane@duhovni.de
Markus Laber 1&1 Mail & Media Development & Technology GmbH markus.laber@1und1.de
Markus Laber 1＆1 Mail＆Media Development＆Technology GmbH markus.laber@1und1.de
Nicolas Lidzborski Google, Inc. nlidz@google.com
Nicolas Lidzborski Google、Inc. nlidz@google.com
Brandon Long Google, Inc. blong@google.com
Brandon Long Google、Inc. blong@google.com
Franck Martin LinkedIn, Inc. fmartin@linkedin.com
フランクマーティンLinkedIn、Inc. fmartin@linkedin.com
Klaus Umbach 1&1 Mail & Media Development & Technology GmbH klaus.umbach@1und1.de
クラウスウンバッハ1＆1 Mail＆Media Development＆Technology GmbH klaus.umbach@1und1.de
Authors' Addresses
著者のアドレス
Daniel Margolis Google, Inc.
ダニエルマーゴリスGoogle、Inc.
Email: dmargolis@google.com
Mark Risher Google, Inc.
Mark Risher Google、Inc.
Email: risher@google.com
Binu Ramakrishnan Oath, Inc.
Binu Ramakrishnan Oath、Inc.
Email: prbinu@yahoo.com
Alexander Brotman Comcast, Inc.
Alexander Brotman Comcast、Inc.
Email: alex_brotman@comcast.com
Janet Jones Microsoft, Inc.
Janet Jones Microsoft、Inc.
Email: janet.jones@microsoft.com