[要約] RFC 2487は、SMTPサービス拡張の一部であり、SMTP over TLSを実装するための仕様を提供しています。目的は、SMTPセッションのセキュリティを向上させ、データの暗号化と認証を提供することです。
Network Working Group P. Hoffman
Request for Comments: 2487 Internet Mail Consortium
Category: Standards Track January 1999
SMTP Service Extension for Secure SMTP over TLS
Secure SMTP over TLSのSMTPサービス拡張
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers.
このドキュメントでは、SMTPサーバーとクライアントがトランスポート層セキュリティを使用して、インターネット上で認証されたプライベート通信を提供できるようにする、SMTPサービスの拡張について説明します。これにより、SMTPエージェントは通信の一部またはすべてを盗聴者や攻撃者から保護することができます。
SMTP [RFC-821] servers and clients normally communicate in the clear over the Internet. In many cases, this communication goes through one or more router that is not controlled or trusted by either entity. Such an untrusted router might allow a third party to monitor or alter the communications between the server and client.
SMTP [RFC-821]サーバーとクライアントは通常、インターネットを介して平文で通信します。多くの場合、この通信は、いずれかのエンティティによって制御または信頼されていない1つ以上のルーターを経由します。このような信頼できないルーターにより、第三者がサーバーとクライアント間の通信を監視または変更できる可能性があります。
Further, there is often a desire for two SMTP agents to be able to authenticate each others' identities. For example, a secure SMTP server might only allow communications from other SMTP agents it knows, or it might act differently for messages received from an agent it knows than from one it doesn't know.
さらに、2つのSMTPエージェントが互いのIDを認証できるようにしたい場合がよくあります。たとえば、セキュリティで保護されたSMTPサーバーは、知っている他のSMTPエージェントからの通信のみを許可したり、知っているエージェントから受信したメッセージに対して、知らないエージェントからのメッセージとは異なる動作をする場合があります。
TLS [TLS], more commonly known as SSL, is a popular mechanism for enhancing TCP communications with privacy and authentication. TLS is in wide use with the HTTP protocol, and is also being used for adding security to many other common protocols that run over TCP.
TLS [TLS]（より一般的にはSSLと呼ばれます）は、プライバシーと認証を使用してTCP通信を強化するための一般的なメカニズムです。 TLSはHTTPプロトコルで広く使用されており、TCPで実行される他の多くの一般的なプロトコルにセキュリティを追加するためにも使用されています。
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 [RFC-2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC-2119]で説明されているように解釈されます。
The STARTTLS extension to SMTP is laid out as follows:
SMTPのSTARTTLS拡張は、次のように配置されます。
(1) the name of the SMTP service defined here is STARTTLS;
（1）ここで定義されているSMTPサービスの名前はSTARTTLSです。
(2) the EHLO keyword value associated with the extension is STARTTLS;
（2）拡張に関連付けられたEHLOキーワード値はSTARTTLSです。
(3) the STARTTLS keyword has no parameters;
（3）STARTTLSキーワードにはパラメーターがありません。
(4) a new SMTP verb, "STARTTLS", is defined;
（4）新しいSMTP動詞「STARTTLS」が定義されています。
(5) no additional parameters are added to any SMTP command.
（5）SMTPコマンドにパラメーターが追加されない。
The STARTTLS keyword is used to tell the SMTP client that the SMTP server allows use of TLS. It takes no parameters.
STARTTLSキーワードは、SMTPサーバーがTLSの使用を許可することをSMTPクライアントに通知するために使用されます。パラメータは必要ありません。
The format for the STARTTLS command is:
STARTTLSコマンドの形式は次のとおりです。
STARTTLS
STARTTLS
with no parameters.
パラメータなし。
After the client gives the STARTTLS command, the server responds with one of the following reply codes:
クライアントがSTARTTLSコマンドを送信すると、サーバーは次のいずれかの応答コードで応答します。
220 Ready to start TLS 501 Syntax error (no parameters allowed) 454 TLS not available due to temporary reason
220 TLSを開始する準備ができました501構文エラー（パラメーターは許可されません）454一時的な理由によりTLSを使用できません
A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address.
公に参照されているSMTPサーバーは、メールをローカルに配信するためにSTARTTLS拡張の使用を要求してはなりません（MUST NOT）。このルールは、STARTTLS拡張がインターネットのSMTPインフラストラクチャの相互運用性を損なうことを防ぎます。公に参照されているSMTPサーバーは、インターネットメールアドレスの右側のドメイン名のMXレコード（またはMXレコードが存在しない場合はAレコード）にリストされているインターネットホストのポート25で実行されるSMTPサーバーです。 。
Any SMTP server may refuse to accept messages for relay based on authentication supplied during the TLS negotiation. An SMTP server that is not publicly referenced may refuse to accept any messages for relay or local delivery based on authentication supplied during the TLS negotiation.
SMTPサーバーは、TLSネゴシエーション中に提供された認証に基づいて、リレー用のメッセージの受け入れを拒否する場合があります。公に参照されていないSMTPサーバーは、TLSネゴシエーション中に提供された認証に基づいて、リレーまたはローカル配信のメッセージの受け入れを拒否する場合があります。
A SMTP server that is not publicly referenced may choose to require that the client perform a TLS negotiation before accepting any commands. In this case, the server SHOULD return the reply code:
公に参照されていないSMTPサーバーは、コマンドを受け入れる前にクライアントがTLSネゴシエーションを実行することを要求することを選択する場合があります。この場合、サーバーは応答コードを返す必要があります。
530 Must issue a STARTTLS command first
530最初にSTARTTLSコマンドを発行する必要があります
to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the client and server are using the ENHANCEDSTATUSCODES ESMTP extension [RFC-2034], the status code to be returned SHOULD be 5.7.0.
NOOP、EHLO、STARTTLS、QUIT以外のすべてのコマンド。クライアントとサーバーがENHANCEDSTATUSCODES ESMTP拡張[RFC-2034]を使用している場合、返されるステータスコードは5.7.0である必要があります（SHOULD）。
After receiving a 220 response to a STARTTLS command, the client SHOULD start the TLS negotiation before giving any other SMTP commands.
STARTTLSコマンドに対する220応答を受信した後、クライアントは他のSMTPコマンドを与える前にTLSネゴシエーションを開始する必要があります（SHOULD）。
If the SMTP client is using pipelining as defined in RFC 1854, the STARTTLS command must be the last command in a group.
SMTPクライアントがRFC 1854で定義されているパイプラインを使用している場合、STARTTLSコマンドはグループの最後のコマンドでなければなりません。
After the TLS handshake has been completed, both parties MUST immediately decide whether or not to continue based on the authentication and privacy achieved. The SMTP client and server may decide to move ahead even if the TLS negotiation ended with no authentication and/or no privacy because most SMTP services are performed with no authentication and no privacy, but some SMTP clients or servers may want to continue only if a particular level of authentication and/or privacy was achieved.
TLSハンドシェイクが完了した後、両当事者は、達成された認証とプライバシーに基づいて続行するかどうかを直ちに決定する必要があります。ほとんどのSMTPサービスは認証とプライバシーなしで実行されるため、TLSネゴシエーションが認証なしまたはプライバシーなしで終了した場合でも、SMTPクライアントとサーバーは先に進むことを決定する場合がありますが、一部のSMTPクライアントまたはサーバーは、特定のレベルの認証および/またはプライバシーが達成されました。
If the SMTP client decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD issue an SMTP QUIT command immediately after the TLS negotiation is complete. If the SMTP server decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD reply to every SMTP command from the client (other than a QUIT command) with the 554 reply code (with a possible text string such as "Command refused due to lack of security").
SMTPクライアントが認証またはプライバシーのレベルが継続するには十分でないと判断した場合、TLSネゴシエーションが完了した直後にSMTP QUITコマンドを発行する必要があります（SHOULD）。 SMTPサーバーが認証またはプライバシーのレベルが高すぎて続行できないと判断した場合は、クライアントからのすべてのSMTPコマンド（QUITコマンド以外）に554応答コード（可能なテキスト文字列など）で応答する必要があります（SHOULD） 「セキュリティの欠如のためにコマンドが拒否された」など）。
The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are:
TLSネゴシエーションで相手の信頼性を信じるかどうかの決定は、ローカルな問題です。ただし、決定に関するいくつかの一般的なルールは次のとおりです。
- A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. - A publicly-referenced SMTP server would probably want to accept any certificate from an SMTP client, and would possibly want to put distinguishing information about the certificate in the Received header of messages that were relayed or submitted from the client.
- SMTPクライアントは、クライアントが接続していると思ったドメイン名であるドメイン名がサーバー証明書に含まれているSMTPサーバーのみを認証したいと思うでしょう。 -公に参照されているSMTPサーバーは、SMTPクライアントからの証明書を受け入れ、クライアントから中継または送信されたメッセージのReceivedヘッダーに証明書に関する識別情報を含めることができます。
Upon completion of the TLS handshake, the SMTP protocol is reset to the initial state (the state in SMTP after a server issues a 220 service ready greeting). The server MUST discard any knowledge obtained from the client, such as the argument to the EHLO command, which was not obtained from the TLS negotiation itself. The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command as the first command after a successful TLS negotiation.
TLSハンドシェイクが完了すると、SMTPプロトコルは初期状態（サーバーが220サービス対応グリーティングを発行した後のSMTPの状態）にリセットされます。サーバーは、TLSネゴシエーション自体から取得されなかった、EHLOコマンドへの引数など、クライアントから取得された知識を破棄する必要があります。クライアントは、TLSネゴシエーション自体から取得されなかった、SMTPサービス拡張のリストなど、サーバーから取得した知識を破棄する必要があります。クライアントは、TLSネゴシエーションが成功した後の最初のコマンドとしてEHLOコマンドを送信する必要があります（SHOULD）。
The list of SMTP service extensions returned in response to an EHLO command received after the TLS handshake MAY be different than the list returned before the TLS handshake. For example, an SMTP server might not want to advertise support for a particular SASL mechanism [SASL] unless a client has sent an appropriate client certificate during a TLS handshake.
TLSハンドシェイクの後に受信したEHLOコマンドに応答して返されるSMTPサービス拡張のリストは、TLSハンドシェイクの前に返されるリストとは異なる場合があります。たとえば、クライアントがTLSハンドシェイク中に適切なクライアント証明書を送信しない限り、SMTPサーバーは特定のSASLメカニズム[SASL]のサポートをアドバタイズしたくない場合があります。
Both the client and the server MUST know if there is a TLS session active. A client MUST NOT attempt to start a TLS session if a TLS session is already active. A server MUST NOT return the TLS extension in response to an EHLO command received after a TLS handshake has completed.
クライアントとサーバーの両方が、アクティブなTLSセッションがあるかどうかを認識している必要があります。 TLSセッションが既にアクティブである場合、クライアントはTLSセッションの開始を試みてはなりません（MUST NOT）。サーバーは、TLSハンドシェイクの完了後に受信したEHLOコマンドに応答してTLS拡張を返してはなりません（MUST NOT）。
The following dialog illustrates how a client and server can start a TLS session:
次のダイアログは、クライアントとサーバーがTLSセッションを開始する方法を示しています。
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.ietf.org
S: 250-mail.imc.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: <continues by sending an SMTP command>
. . .
It should be noted that SMTP is not an end-to-end mechanism. Thus, if an SMTP client/server pair decide to add TLS privacy, they are not securing the transport from the originating mail user agent to the recipient. Further, because delivery of a single piece of mail may go between more than two SMTP servers, adding TLS privacy to one pair of servers does not mean that the entire SMTP chain has been made private. Further, just because an SMTP server can authenticate an SMTP client, it does not mean that the mail from the SMTP client was authenticated by the SMTP client when the client received it.
SMTPはエンドツーエンドのメカニズムではないことに注意してください。したがって、SMTPクライアント/サーバーのペアがTLSプライバシーを追加することを決定した場合、それらは送信元のメールユーザーエージェントから受信者への転送を保護しません。さらに、1つのメールの配信は3つ以上のSMTPサーバー間で行われる場合があるため、サーバーの1つのペアにTLSプライバシーを追加しても、SMTPチェーン全体が非公開になったわけではありません。さらに、SMTPサーバーがSMTPクライアントを認証できるからといって、SMTPクライアントからのメールが、クライアントが受信したときにSMTPクライアントによって認証されたという意味ではありません。
Both the STMP client and server must check the result of the TLS negotiation to see whether acceptable authentication or privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependant, and is beyond the scope of this document.
STMPクライアントとサーバーの両方がTLSネゴシエーションの結果をチェックして、受け入れ可能な認証またはプライバシーが達成されたかどうかを確認する必要があります。この手順を無視すると、セキュリティのためのTLSの使用が完全に無効になります。許容できる認証またはプライバシーが達成されたかどうかの決定はローカルで行われ、実装に依存し、このドキュメントの範囲を超えています。
The SMTP client and server should note carefully the result of the TLS negotiation. If the negotiation results in no privacy, or if it results in privacy using algorithms or key lengths that are deemed not strong enough, or if the authentication is not good enough for either party, the client may choose to end the SMTP session with an immediate QUIT command, or the server may choose to not accept any more SMTP commands.
SMTPクライアントとサーバーは、TLSネゴシエーションの結果を注意深く記録する必要があります。ネゴシエーションの結果、プライバシーが確保されない場合、またはアルゴリズムやキーの長さが不十分であると見なされる場合にプライバシーが確保される場合、またはどちらの当事者にとっても認証が不十分な場合、クライアントは即時にSMTPセッションを終了することを選択できます。 QUITコマンド、またはサーバーがこれ以上のSMTPコマンドを受け入れないことを選択する場合があります。
A server announcing in an EHLO response that it uses a particular TLS protocol should not pose any security issues, since any use of TLS will be at least as secure as no use of TLS.
EHLO応答で特定のTLSプロトコルを使用することを通知するサーバーは、TLSの使用は少なくともTLSを使用しないのと同じくらい安全であるため、セキュリティ上の問題は発生しません。
A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server. This would cause the client not to try to start a TLS session. An SMTP client can protect against this attack by recording the fact that a particular SMTP server offers TLS during one session and generating an alarm if it does not appear in the EHLO response for a later session. The lack of TLS during a session SHOULD NOT result in the bouncing of email, although it could result in delayed processing.
サーバーから "250 STARTTLS"応答を削除することにより、中間者攻撃を仕掛けることができます。これにより、クライアントはTLSセッションを開始しようとしなくなります。 SMTPクライアントは、特定のSMTPサーバーが1つのセッション中にTLSを提供するという事実を記録し、それが後のセッションのEHLO応答に表示されない場合にアラームを生成することにより、この攻撃から保護できます。セッション中にTLSがないと、処理が遅れる可能性がありますが、電子メールがバウンスされることはありません（SHOULD NOT）。
Before the TLS handshake has begun, any protocol interactions are performed in the clear and may be modified by an active attacker. For this reason, clients and servers MUST discard any knowledge obtained prior to the start of the TLS handshake upon completion of the TLS handshake.
TLSハンドシェイクが始まる前に、プロトコルの相互作用はすべてクリアテキストで実行され、アクティブな攻撃者によって変更される可能性があります。このため、クライアントとサーバーは、TLSハンドシェイクの完了時に、TLSハンドシェイクの開始前に取得した知識を破棄する必要があります。
The STARTTLS extension is not suitable for authenticating the author of an email message unless every hop in the delivery chain, including the submission to the first SMTP server, is authenticated. Another proposal [SMTP-AUTH] can be used to authenticate delivery and MIME security multiparts [MIME-SEC] can be used to authenticate the author of an email message. In addition, the [SMTP-AUTH] proposal offers simpler and more flexible options to authenticate an SMTP client and the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with the STARTTLS command to provide an authorization identity.
STARTTLS拡張は、最初のSMTPサーバーへの送信を含む配信チェーン内のすべてのホップが認証されない限り、電子メールメッセージの作成者の認証には適していません。別の提案[SMTP-AUTH]を使用して配信を認証し、MIMEセキュリティマルチパート[MIME-SEC]を使用して電子メールメッセージの作成者を認証できます。さらに、[SMTP-AUTH]プロポーザルは、SMTPクライアントを認証するためのよりシンプルで柔軟なオプションを提供し、SASL EXTERNALメカニズム[SASL]をSTARTTLSコマンドと組み合わせて使用して、認証IDを提供できます。
A. References
A.リファレンス
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982.
[RFC-821] Postel、J。、「Simple Mail Transfer Protocol」、RFC 821、1982年8月。
[RFC-1869] Klensin, J., Freed, N, Rose, M, Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[RFC-1869] Klensin、J.、Freed、N、Rose、M、Stefferud、E。およびD. Crocker、「SMTP Service Extensions」、STD 10、RFC 1869、1995年11月。
[RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC-2034] Freed、N。、「拡張エラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[SMTP-AUTH] "SMTP Service Extension for Authentication", Work in Progress.
[SMTP-AUTH]「認証用のSMTPサービス拡張」、作業中。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
B. Author's Address
B.著者のアドレス
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz、CA 95060
Phone: (831) 426-9827 EMail: phoffman@imc.org
電話：（831）426-9827メール：phoffman@imc.org
C. Full Copyright Statement
C.完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。