[要約] RFC 3207は、SMTPサービス拡張の一部であり、Transport Layer Security（TLS）を使用した安全なSMTP通信を提供するための仕様です。このRFCの目的は、SMTPセッションの暗号化と認証を強化し、セキュリティを向上させることです。
Network Working Group P. Hoffman
Request for Comments: 3207 Internet Mail Consortium
Obsoletes: 2487 February 2002
Category: Standards Track
SMTP Service Extension for Secure SMTP over Transport Layer Security
輸送層のセキュリティ上の安全なSMTPの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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (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サーバーとクライアントがTLS（Transport Layer Security）を使用して、インターネット上のプライベートで認証された通信を提供できるSMTP（Simple Mail Transfer Protocol）サービスの拡張機能について説明します。これにより、SMTPエージェントは、盗聴者や攻撃者からコミュニケーションの一部またはすべてを保護する能力を提供します。
SMTP [RFC2821] 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 [RFC2821]サーバーとクライアントは通常、インターネット上のクリアで通信します。多くの場合、この通信は、どちらのエンティティによって制御または信頼されていない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エージェントがお互いのアイデンティティを認証できることを望んでいることがよくあります。たとえば、SECURE 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.
より一般的にSSLとして知られているTLS [TLS]は、プライバシーと認証でTCP通信を強化するための一般的なメカニズムです。TLSはHTTPプロトコルで幅広く使用されており、TCPを介して実行される他の多くの一般的なプロトコルにセキュリティを追加するためにも使用されています。
This document obsoletes RFC 2487.
このドキュメントは、RFC 2487を廃止します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
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 is currently able to negotiate the 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 If the client receives the 454 response, the client must decide whether or not to continue the SMTP session. Such a decision is based on local policy. For instance, if TLS was being used for client authentication, the client might try to continue the session, in case the server allows it even with no authentication. However, if TLS was being negotiated for encryption, a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error.
220 TLS 501構文エラーを開始する準備ができています（パラメーターが許可されていません）454 TLSは、クライアントが454の応答を受信した場合、クライアントがSMTPセッションを継続するかどうかを決定する必要があります。このような決定は、ローカルポリシーに基づいています。たとえば、TLSがクライアント認証に使用されている場合、クライアントは、認証なしでサーバーが許可されている場合に備えて、セッションを続行しようとする場合があります。ただし、TLSが暗号化のためにネゴシエートされていた場合、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拡張機能を使用する必要はありません。このルールにより、StartTLS拡張機能がインターネットのSMTPインフラストラクチャの相互運用性を損なうことを防ぎます。公開されているSMTPサーバーは、インターネットメールアドレスの右側のドメイン名のMXレコードにリストされているインターネットホストのポート25（またはMXレコードが存在しない場合）で実行される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 [RFC2034], the status code to be returned SHOULD be 5.7.0.
NOOP、ehlo、starttls、またはquit以外のすべてのコマンドに。クライアントとサーバーがEnhancedStatusCodes ESMTP拡張[RFC2034]を使用している場合、返されるステータスコードは5.7.0でなければなりません。
After receiving a 220 response to a STARTTLS command, the client MUST start the TLS negotiation before giving any other SMTP commands. If, after having issued the STARTTLS command, the client finds out that some failure prevents it from actually starting a TLS handshake, then it SHOULD abort the connection.
StartTLSコマンドに対する220の応答を受け取った後、クライアントは他のSMTPコマンドを提供する前にTLS交渉を開始する必要があります。StartTLSコマンドを発行した後、クライアントが実際にTLSハンドシェイクを開始することを妨げていることをクライアントが見つけた場合、接続を中止する必要があります。
If the SMTP client is using pipelining as defined in RFC 2920, the STARTTLS command must be the last command in a group.
SMTPクライアントがRFC 2920で定義されているようにパイプライニングを使用している場合、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クライアントとサーバーは、ほとんどのSMTPサービスが認証もプライバシーもなく実行されているため、TLS交渉が認証やプライバシーなしで終了しても先に進むことを決定する場合がありますが、一部の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コマンドを発行する必要があります。SMTPサーバーが認証またはプライバシーのレベルが継続するのに十分ではないと判断した場合、554の返信コード（可能なテキスト文字列を使用して、クライアントからすべてのSMTPコマンド（QUITコマンド以外）に返信する必要があります。「セキュリティの欠如のためにコマンドが拒否された」）。
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 verifiable 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クライアントから検証可能な証明書を受け入れたいと思うでしょう。また、クライアントから中継または提出されたメッセージのヘッダーに、証明書に関する識別情報を識別することを望むでしょう。
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コマンドを送信する必要があります。
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の握手前に返されるリストとは異なる場合があります。たとえば、SMTPサーバーは、TLSの握手中にクライアントが適切なクライアント証明書を送信しない限り、特定の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 STARTTLS extension in response to an EHLO command received after a TLS handshake has completed.
クライアントとサーバーの両方が、TLSセッションがアクティブであるかどうかを知る必要があります。TLSセッションがすでにアクティブである場合、クライアントはTLSセッションを開始しようとしてはなりません。サーバーは、TLSの握手が完了した後に受信したEhloコマンドに応じてStartTLS拡張機能を返してはなりません。
STARTTLS is a valid ESMTP extension when used on the Submission port, as defined in [RFC2476]. In fact, since the submission port is by definition not a publicly referenced SMTP server, the STARTTLS extension can be particularly useful by providing security and authentication for this service.
[RFC2476]で定義されているように、StartTLSは、提出ポートで使用される場合の有効なESMTP拡張です。実際、送信ポートは定義上、公開されているSMTPサーバーではないため、StartTLS拡張機能は、このサービスにセキュリティと認証を提供することで特に役立ちます。
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.example.com
S: 250-mail.imc.org offers a warm hug of welcome
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: EHLO mail.example.com
S: 250-mail.imc.org touches your hand gently for a moment
S: 250-8BITMIME
S: 250 DSN
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つのSMTPサーバーを1つ以上のSMTPサーバー間で配信する可能性があるため、TLSプライバシーを1つのサーバーに追加しても、SMTPチェーン全体がプライベートになったことを意味しません。さらに、SMTPサーバーがSMTPクライアントを認証できるからといって、クライアントが受信したときにSMTPクライアントからのメールがSMTPクライアントによって認証されたという意味ではありません。
Both the SMTP client and server must check the result of the TLS negotiation to see whether an acceptable degree of authentication and 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-dependent, and is beyond the scope of this document.
SMTPクライアントとサーバーの両方が、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 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. Another man-in-the-middle attack is to allow the server to announce its STARTTLS capability, but to alter the client's request to start TLS and the server's response. In order to defend against such attacks both clients and servers MUST be able to be configured to require successful TLS negotiation of an appropriate cipher suite for selected hosts before messages can be successfully transferred. The additional option of using TLS when possible SHOULD also be provided. An implementation MAY provide the ability to record that TLS was used in communicating with a given peer and generating a warning if it is not used in a later session.
中間の攻撃は、サーバーから「250 StartTLS」応答を削除することで起動できます。これにより、クライアントはTLSセッションを開始しようとしないようになります。もう1つの中間攻撃は、サーバーがStartTLS機能を発表できるようにすることですが、TLSを開始するというクライアントの要求とサーバーの応答を変更することです。このような攻撃から防御するには、クライアントとサーバーの両方を構成できるように設定できる必要があります。可能な場合はTLSを使用する追加のオプションも提供する必要があります。実装は、TLSが特定のピアと通信し、後のセッションで使用されない場合に警告を生成する際に使用されたことを記録する機能を提供する場合があります。
If the TLS negotiation fails or if the client receives a 454 response, the client has to decide what to do next. There are three main choices: go ahead with the rest of the SMTP session, retry TLS at a later time, or give up and return the mail to the sender. If a failure or error occurs, the client can assume that the server may be able to negotiate TLS in the future, and should try negotiate TLS in a later session, until some locally-chosen timeout occurs, at which point, the client should return the mail to the sender. However, if the client and server were only using TLS for authentication, the client may want to proceed with the SMTP session, in case some of the operations the client wanted to perform are accepted by the server even if the client is unauthenticated.
TLS交渉が失敗した場合、またはクライアントが454の応答を受け取った場合、クライアントは次に何をすべきかを決定する必要があります。3つの主な選択肢があります。SMTPセッションの残りの部分を進めたり、後でTLSを再試行するか、あきらめて送信者にメールを返します。障害またはエラーが発生した場合、クライアントは、サーバーが将来TLSを交渉できる可能性があると想定し、地元で選択されたタイムアウトが発生するまで、後のセッションでTLSを交渉してみる必要があります。送信者へのメール。ただし、クライアントとサーバーが認証にTLSのみを使用している場合、クライアントが実行したい操作の一部が、クライアントが認識されていなくてもサーバーによって受け入れられている場合、クライアントはSMTPセッションを続行したい場合があります。
Before the TLS handshake has begun, any protocol interactions are performed in the clear and may be modified by an active attacker.
TLSの握手が始まる前に、プロトコルの相互作用はクリアで実行され、アクティブな攻撃者によって変更される場合があります。
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の握手が開始される前に得られた知識を破棄する必要があります。
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外部メカニズム[SASL]をstartTLSコマンドと組み合わせて、認証アイデンティティを提供することができます。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC2034] Freed、N。、「拡張エラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[RFC2476] Gellens、R。およびJ. Klensin、「Message Submission」、RFC 2476、1998年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-Auth] Myers、J。、「認証のためのSMTPサービス拡張」、RFC 2554、1999年3月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
Appendix
付録
This document is a revision of RFC 2487, which is a Proposed Standard. The changes from that document are:
このドキュメントは、提案された標準であるRFC 2487の改訂です。そのドキュメントからの変更は次のとおりです。
- Section 5 and 7: More discussion of the man-in-the-middle attacks - Section 5: Additional discussion of when a server should and should not advertise the STARTTLS extension - Section 5: Changed the requirements on SMTP clients after receiving a 220 response. - Section 5.1: Clarified description of verifying certificates. - Section 5.3: Added the section on "STARTTLS on the Submission Port" - Section 6: Bug fix in the example to indicate that the client needs to issue a new EHLO command, as already is described in section 5.2. - Section 7: Clarification of the paragraph on acceptable degree of privacy. Significant change to the discussion of how to avoid a man-in-the-middle attack. - Section A: Update reference from RFC 821 to RFC 2821.
- セクション5および7：中間者攻撃の詳細 - セクション5：サーバーがStartTLS拡張機能を宣伝すべきではない時期の追加ディスカッション - セクション5：220の応答を受信した後、SMTPクライアントの要件を変更しました。 - セクション5.1：証明書の検証の明確な説明。 - セクション5.3：「提出ポートのStartTLS」のセクションを追加しました - セクション6：バグ修正クライアントは、セクション5.2ですでに説明されているように、クライアントが新しいEHLOコマンドを発行する必要があることを示します。 - セクション7：許容されるプライバシーの程度に関する段落の明確化。中間の攻撃を避ける方法の議論への大きな変化。 - セクションA：RFC 821からRFC 2821に参照を更新します。
Author's Address
著者の連絡先
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060
ポールホフマンインターネットメールコンソーシアム127セグレプレイスサンタクルス、カリフォルニア95060
Phone: (831) 426-9827 EMail: phoffman@imc.org
電話：（831）426-9827メール：phoffman@imc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。