[要約] RFC 9422 は、SMTPおよびLMTPにおけるLIMITS拡張機能と関連する制限レジストリを定義し、サーバーがクライアントにプロトコルへの適用意図する制限を通知する手段を提供する。
Internet Engineering Task Force (IETF) N. Freed
Request for Comments: 9422
Category: Standards Track J. Klensin
ISSN: 2070-1721 February 2024
This document defines a LIMITS extension for the Simple Mail Transfer Protocol (SMTP), including submission, as well as the Local Mail Transfer Protocol (LMTP). It also defines an associated limit registry. The extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol during the current session. The client is then able to adapt its behavior in order to conform to those limits.
このドキュメントは、提出を含む単純なメール転送プロトコル（SMTP）の制限拡張機能と、ローカルメール転送プロトコル（LMTP）を定義しています。また、関連する制限レジストリも定義します。拡張機能は、SMTP、提出、またはLMTPサーバーが、現在のセッション中にサーバーがプロトコルに適用する予定の制限をクライアントに通知するための手段を提供します。その後、クライアントは、それらの制限に準拠するために動作を適応させることができます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc9422.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9422で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. The LIMITS SMTP Extension
3.1. Limits
3.2. Limit Naming Conventions
3.3. Interaction with Pipelining
3.4. Varying Limits
3.5. Interaction with SMTP Minimums
3.6. Multiple EHLO Commands
3.7. Syntax Errors in the LIMITS Parameter Value
3.8. Caching of Limit Settings between Sessions Involving the
Same Client and Server SMTP
4. Initial Limits
4.1. MAILMAX Limit
4.2. RCPTMAX Limit
4.3. RCPTDOMAINMAX Limit
5. Example
6. Security Considerations
7. IANA Considerations
7.1. SMTP Service Extension Registry
7.2. SMTP Server Limits Registry
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
The Simple Mail Transfer Protocol provides the ability to transfer [SMTP] or submit [SUBMIT] multiple email messages from one host to another, each with one or more recipients, using a single or multiple connections.
Simple Mail転送プロトコルは、1つまたは複数の接続を使用して、1つ以上の受信者を使用して、1つまたは複数の受信者を使用して、1つのホストから別のホストに複数の電子メールメッセージを転送または送信する機能を提供します。
The Local Mail Transfer Protocol [LMTP] provides the ability to deliver messages to a system without its own mail queues. Like SMTP, it allows multiple messages with multiple recipients.
ローカルメール転送プロトコル[LMTP]は、独自のメールキューなしでシステムにメッセージを配信する機能を提供します。SMTPと同様に、複数の受信者を持つ複数のメッセージが許可されます。
In order to conserve resources as well as protect themselves from malicious clients, it is necessary for servers to enforce limits on various aspects of the protocol, e.g., a limit on the number of recipients that can be specified in a single transaction.
悪意のあるクライアントからリソースを保護し、悪意のあるクライアントから身を守るためには、サーバーがプロトコルのさまざまな側面に制限を実施する必要があります。たとえば、単一のトランザクションで指定できる受信者の数の制限です。
Additionally, servers may also wish to alter the limits they apply depending on their assessment of the reputation of a particular client.
さらに、サーバーは、特定のクライアントの評判の評価に応じて、適用される制限を変更することもできます。
The variability of the limits that may be in effect creates a situation where clients may inadvertently exceed a particular server's limits, causing servers to respond with temporary (or in some cases, permanent) errors. This in turn can lead to delays or even failures in message transfer.
実際にある可能性のある制限のばらつきは、クライアントが特定のサーバーの制限を不注意に超えて、一時的な（または場合によっては永続的な）エラーで応答する可能性がある状況を作成します。これにより、メッセージ転送の遅延や障害につながる可能性があります。
The LIMITS extension provides the means for a server to inform a client about specific limits in effect for a particular SMTP or LMTP session in the EHLO or LHLO command response. This information, combined with the inherent flexibility of these protocols, makes it possible for clients to avoid server errors and the problems they cause.
制限拡張機能は、EHLOまたはLHLOコマンド応答の特定のSMTPまたはLMTPセッションの有効な特定の制限について、クライアントにクライアントに通知する手段を提供します。この情報は、これらのプロトコルの固有の柔軟性と相まって、クライアントがサーバーエラーやそれらが引き起こす問題を回避することを可能にします。
SMTP and LMTP servers have always been able to announce a limit using distinguished syntax in a reply, but this approach requires that the client first needs to issue a command. The mechanism specified here avoids the overhead of that approach by announcing limits prior to any substantive interaction.
SMTPおよびLMTPサーバーは、常に返信で著名な構文を使用して制限を発表することができましたが、このアプローチでは、クライアントが最初にコマンドを発行する必要があります。ここで指定されたメカニズムは、実質的な相互作用の前に制限を発表することにより、そのアプローチのオーバーヘッドを回避します。
Limits are registered with the IANA. Each registration includes the limit name, value syntax, and a description of its semantics.
制限はIANAに登録されています。各登録には、制限名、値の構文、およびそのセマンティクスの説明が含まれます。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This specification uses the Augmented Backus-Naur Form [ABNF] notation and its core rules to define the formal syntax of the LIMITS extension.
この仕様では、拡張されたBackus-Naurフォーム[ABNF]表記とそのコアルールを使用して、制限拡張の正式な構文を定義します。
This specification makes extensive use of the terminology specified and used in [SMTP].
この仕様により、[SMTP]で指定および使用される用語を広く使用します。
The extension mechanism for SMTP is defined in Section 2.2 of the current SMTP specification [RFC5321a]. LMTP [LMTP] inherits SMTP's extension mechanism.
SMTPの拡張メカニズムは、現在のSMTP仕様[RFC5321A]のセクション2.2で定義されています。LMTP [LMTP]はSMTPの拡張メカニズムを継承します。
The name of the extension is LIMITS. Servers implementing this extension advertise a LIMITS as a keyword in the response to EHLO (LHLO for LMTP). The associated parameter is used by the server to communicate one or more limits, each with an optional value, to the client. The syntax of the parameter is:
拡張機能の名前は制限です。この拡張機能を実装するサーバーは、Ehlo（LMTPのLHLO）への応答のキーワードとして制限を宣伝します。関連するパラメーターは、サーバーによって、それぞれがオプションの値を持つ1つ以上の制限をクライアントに通知するために使用されます。パラメーターの構文は次のとおりです。
limits-param = limit-name-value 0*[SP limit-name-value]
limit-name-value = limit-name ["=" limit-value]
limit-name = 1*(ALPHA / DIGIT / "-" / "_")
limit-value = 1*(%x21-3A / %x3C-7E) ; Any VCHAR except ";"
This extension introduces no new SMTP commands and does not alter any existing command. However, it is possible for a LIMITS parameter to be associated with another SMTP extension that does these things.
この拡張機能は、新しいSMTPコマンドを導入せず、既存のコマンドを変更しません。ただし、制限パラメーターがこれらのことを行う別のSMTP拡張機能に関連付けられる可能性があります。
In order to achieve consistent behavior, all limits MUST be registered with the IANA, as described below.
一貫した動作を達成するには、以下で説明するように、すべての制限をIANAに登録する必要があります。
Limit names MUST be comprehensible, but also should be kept as short as possible. The use of commonly understood abbreviations, e.g., "MAX" for "maximum", is encouraged.
制限名は理解できる必要がありますが、可能な限り短くする必要があります。一般的に理解されている略語、たとえば「最大」の「最大」の使用が奨励されています。
When a limit is associated with a particular command, its name SHOULD begin with the name of that command.
制限が特定のコマンドに関連付けられている場合、その名前はそのコマンドの名前から始める必要があります。
Limit names SHOULD end with one or more terms that describe the type of limit.
制限名は、制限の種類を説明する1つ以上の用語で終了する必要があります。
The "Pipelining" extension [PIPELINING] is commonly used to improve performance, especially over high latency connections. Pipelining allows an entire transaction to be sent without checking responses, and in some cases it may be possible to send multiple transactions.
「パイプライン」拡張[パイプライン]は、特に高レイテンシ接続を超えるパフォーマンスを改善するために一般的に使用されます。パイプラインは、回答をチェックせずにトランザクション全体を送信できるようになり、場合によっては複数のトランザクションを送信することが可能になる場合があります。
The use of pipelining affects the LIMITS extension in an important way: Since a pipelining client cannot check intermediate command responses without stalling the pipeline, it cannot count the number of successful versus failed responses and adjust its behavior accordingly. Limit designers need to take this into account.
パイプライニングの使用は、重要な方法で制限拡張に影響します。パイプラインクライアントは、パイプラインを停止せずに中間コマンド応答をチェックできないため、成功した対応と失敗した応答の数をカウントし、それに応じて動作を調整することはできません。制限デザイナーはこれを考慮する必要があります。
For example, it may seem like it would be better to impose a limit on the number of successful RCPT TO commands as opposed to the way the RCPTMAX limit is specified in Section 4.2 below. But counting the total number of RCPT TOs is simple, whereas counting the number of successful RCPT TO stalls the pipeline.
たとえば、RCPTMAXの制限が以下のセクション4.2で指定されている方法とは対照的に、コマンドに成功したRCPTの数に制限を課す方が良いと思われるかもしれません。しかし、RCPT TOSの総数をカウントするのは簡単ですが、成功したRCPTの数をカウントしてパイプラインを停止します。
This extension provides an announcement as part of the reply to an EHLO command.
この拡張機能は、EHLOコマンドへの返信の一部として発表を提供します。
Some servers vary their limits, as a session progresses, based on their obtaining more information. This extension does not attempt to handle in-session limit changes.
一部のサーバーは、より多くの情報を取得することに基づいて、セッションが進行するにつれて制限が異なります。この拡張機能は、セッション内の制限変更を処理しようとはしません。
SMTP specifies minimum values for various server sizes, limits, and timeouts [RFC5321b], e.g., servers must accept a minimum of 100 RCPT TO commands [RFC5321c]). Unfortunately, the reality is that servers routinely impose smaller limits than what SMTP requires, and when this is done it is especially important for clients to be aware that this is happening.
SMTPは、さまざまなサーバーサイズ、制限、およびタイムアウト[RFC5321B]の最小値を指定します。たとえば、サーバーはコマンド[RFC5321C]に最小100 RCPTを受け入れる必要があります。残念ながら、現実には、サーバーはSMTPが必要とするものよりも定期的に小さな制限を課しています。これが行われると、クライアントがこれが起こっていることを認識することが特に重要です。
For this reason there is no requirement that the limits advertised by this extension comply with the minimums imposed by SMTP.
このため、この延長によって宣伝されている制限がSMTPによって課される最小値に準拠するという要件はありません。
These protocols require that the EHLO command (LHLO in LMTP) be reissued under certain circumstances, e.g., after successful authentication [AUTH] or negotiation of a security layer [STARTTLS].
これらのプロトコルでは、Ehloコマンド（LHLO in LMTP）を特定の状況下で再発行する必要があります。
Servers MAY return updated limits any time the protocol requires clients to reissue the EHLO command.
サーバーは、プロトコルがクライアントにEhloコマンドの再発行を要求する場合でも、更新された制限を返す場合があります。
Clients MUST discard any previous limits in favor of those provided by the most recent EHLO. This includes the case where the original EHLO provided a set of limits but the subsequent EHLO did not; in this case, the client MUST act as if no limits were communicated.
クライアントは、最新のEHLOが提供するものを支持して、以前の制限を破棄する必要があります。これには、元のEhloが一連の制限を提供したが、その後のEhloはそうではなかった場合が含まれます。この場合、クライアントは制限が通信されないかのように行動する必要があります。
Syntax errors in the basic parameter syntax are best handled by ignoring the value in its entirety; in this case, clients SHOULD proceed as if the LIMITS extension had not been used.
基本パラメーターの構文エラーは、値全体を無視することで最適に処理されます。この場合、クライアントは制限拡張機能が使用されていないかのように進める必要があります。
Syntax or other errors in the value syntax of a specific limit, including unrecognized value keywords, are best handled by ignoring that limit; in this case, the client MUST proceed as if that limit had not been specified.
認識されていない値キーワードを含む特定の制限の値の構文またはその他のエラーは、その制限を無視することで最適に処理されます。この場合、クライアントはその制限が指定されていないかのように進む必要があります。
It is possible that a future specification may create multiple limits that are interrelated in some way; in this case, that specification MUST specify how an error in the value syntax of one limit affects the other limits.
将来の仕様により、何らかの形で相互に関連する複数の制限が作成される可能性があります。この場合、その仕様は、1つの制限の値の構文のエラーが他の制限にどのように影響するかを指定する必要があります。
Clients MAY cache limits determined during one session and use them to optimize their behavior for subsequent sessions. However, since servers are free to adjust their limits at any time, clients MUST be able to accommodate any limit changes that occur between sessions.
クライアントは、1つのセッション中に決定された制限をキャッシュし、それらを使用してその後のセッションのために動作を最適化する場合があります。ただし、サーバーはいつでも制限を自由に調整できるため、クライアントはセッション間で発生する制限変更に対応できる必要があります。
An initial set of limits is specified in the following sections.
以下のセクションでは、初期の制限セットが指定されています。
Name:
名前：
MAILMAX
MailMax
Value syntax:
値構文：
%x31-39 0*5DIGIT ; "0" not allowed, six-digit maximum
％x31-39 0*5digit;「0」は許可されておらず、最大6桁
Description:
説明：
MAILMAX specifies the maximum number of transactions (MAIL FROM commands) the server will accept in a single session. The count includes all MAIL FROM commands, regardless of whether they succeed or fail.
MailMaxは、サーバーが1回のセッションで受け入れるトランザクションの最大数（コマンドからのメール）を指定します。カウントには、コマンドからのすべてのメールが含まれます。
Restrictions:
制限：
None.
なし。
Security Considerations:
セキュリティ上の考慮事項：
See Section 6
セクション6を参照してください
Name:
名前：
RCPTMAX
rcptmax
Value syntax:
値構文：
%x31-39 0*5DIGIT ; "0" not allowed, six-digit maximum
％x31-39 0*5digit;「0」は許可されておらず、最大6桁
Description:
説明：
RCPTMAX specifies the maximum number of RCPT TO commands the server will accept in a single transaction. It is not a limit on the actual number of recipients the message ends up being sent to; a single RCPT TO command may produce multiple recipients or, in the event of an error, none.
RCPTMAXは、サーバーが単一のトランザクションで受け入れるコマンドにコマンドするRCPTの最大数を指定します。メッセージが送信されることになっている実際の受信者の数の制限ではありません。コマンドする単一のRCPTは、複数の受信者を生成する場合、またはエラーが発生した場合、なし。
Restrictions:
制限：
None.
なし。
Security Considerations:
セキュリティ上の考慮事項：
See Section 6
セクション6を参照してください
Name:
名前：
RCPTDOMAINMAX
rcptdomainmax
Value syntax:
値構文：
%x31-39 0*5DIGIT ; "0" not allowed, six-digit maximum
％x31-39 0*5digit;「0」は許可されておらず、最大6桁
Description:
説明：
RCPTDOMAINMAX specifies the maximum number of different domains that can appear in a recipient (RCPT TO) address within a single session. This limit is imposed by some servers that bind to a specific internal delivery mechanism on receipt of the first RCPT TO command.
RCPTDOMAINMAX単一セッション内で受信者（RCPTからアドレス）に表示される可能性のある異なるドメインの最大数を指定します。この制限は、コマンドする最初のRCPTを受け取ったときに特定の内部配信メカニズムにバインドするいくつかのサーバーによって課されます。
Restrictions:
制限：
None.
なし。
Security Considerations:
セキュリティ上の考慮事項：
See Section 6
セクション6を参照してください
A server announces two limits it implements to the client, along with various other supported extensions, as follows:
サーバーは、次のように、他のさまざまなサポートされている拡張機能とともに、クライアントに実装する2つの制限を発表します。
S: [wait for open connection]
C: [open connection to server]
S: 220 mail.example.com ESMTP service ready
C: EHLO example.org
S: 250-mail.example.com
S: 250-SMTPUTF8
S: 250-LIMITS RCPTMAX=20 MAILMAX=5
S: 250-SIZE 100000000
S: 250-8BITMIME
S: 250-ENHANCEDSTATUSCODES
S: 250-PIPELINING
S: 250-CHUNKING
S: 250 STARTTLS
The client now knows to limit the number of recipients in a transaction to twenty and the number of transactions in a session to five.
クライアントは現在、トランザクションの受信者の数を20に制限し、セッションのトランザクション数を5に制限することを知っています。
A malicious server can use limits to overly constrain client behavior, causing excessive use of client resources.
悪意のあるサーバーは、制限を使用してクライアントの動作を過度に制約し、クライアントリソースを過度に使用することができます。
A malicious client may use the limits a server advertises to optimize the delivery of unwanted messages.
悪意のあるクライアントは、サーバーが広告する制限を使用して、不要なメッセージの配信を最適化する場合があります。
A man-in-the-middle attack on unprotected SMTP connections can be used to cause clients to misbehave, which in turn could result in delivery delays or failures. Loss of reputation for the client could also occur.
保護されていないSMTP接続に対する中間の攻撃を使用して、クライアントを誤解させ、その結果、配信の遅延や障害を引き起こす可能性があります。クライアントの評判の喪失も発生する可能性があります。
All that said, decades of operational experience with the SMTP "SIZE" extension [SIZE], which provides servers with the ability to indicate message size, indicates that such abuse is rare and unlikely to be a significant problem.
とはいえ、SMTPの「サイズ」拡張[サイズ]での数十年の運用経験は、メッセージサイズを示す機能をサーバーに提供しますが、そのような乱用はまれであり、重大な問題である可能性が低いことを示しています。
Use of the LIMITS extension to provide client-specific information - as opposed to general server limits - unavoidably provides senders with feedback about their reputation. Malicious senders can exploit this in various ways, e.g., start by sending good email and then, once their reputation is established, sending bad email.
クライアント固有の情報を提供するための制限拡張機能の使用 - 一般的なサーバーの制限とは対照的に - は、その評判に関するフィードバックを送信者に避けられないほどに提供します。悪意のある送信者は、これをさまざまな方法で悪用できます。たとえば、良いメールを送信し、評判が確立されたら悪いメールを送信することから始めます。
The IANA has added "LIMITS" to the "SMTP Service Extensions" registry:
IANAは、「SMTPサービス拡張機能」レジストリに「制限」を追加しました。
EHLO Keyword:
ehloキーワード：
LIMITS
制限
Description:
説明：
Server limits
サーバー制限
Reference:
参照：
RFC 9422
RFC 9422
Note:
注記：
See "SMTP Server Limits" registry.
「SMTPサーバー制限」レジストリを参照してください。
The IANA has created a new registry in the "MAIL Parameters" group for SMTP server limits. The policy for this registry is "Specification Required". Registry entries consist of these required values:
IANAは、SMTPサーバー制限の「メールパラメーター」グループに新しいレジストリを作成しました。このレジストリのポリシーは「必要な仕様」です。レジストリエントリは、これらの必要な値で構成されています。
1. The name of the limit.
1. 制限の名前。
2. The syntax of the limit value, if the limit has one. This syntax MUST conform to the provisions of Section 3 above. In most cases, the syntax will consist of a keyword designating the limit type followed by a limit value, using a "name=value" form as illustrated by the registrations created by this specification in Section 4 above. Use of ABNF [ABNF] is preferred but not required. If there is no limit value, that should be explicit in the registration request and the registry.
2. 制限値の構文には、制限値が1つある場合。この構文は、上記のセクション3の規定に準拠する必要があります。ほとんどの場合、構文は、上記のセクション4にこの仕様で作成された登録によって示されるように、「name = value」フォームを使用して、制限タイプに続いて制限値を指定するキーワードで構成されます。ABNF [ABNF]の使用が推奨されますが、必要ありません。制限値がない場合、それは登録要求とレジストリで明示的である必要があります。
3. A description of the limit's semantics.
3. 制限のセマンティクスの説明。
4. Restrictions, if any, on the use of the limit. If the limit is specific to any of SMTP, message submission, or LMTP, it should be documented here.
4. 制限の使用に関する制限がある場合。制限がSMTP、メッセージの送信、またはLMTPのいずれかに固有の場合は、ここで文書化する必要があります。
5. Security considerations for the limit.
5. 制限に関するセキュリティ上の考慮事項。
The Designated Expert(s) appointed under the "Specification Required" procedure should check that registration requests are consistent with the requirements and intent of the extension mechanisms associated with SMTP [SMTP], Section 3 above, and the provision of this specification more generally and offer advice accordingly.
「必要な」手順に基づいて任命された指定された専門家は、登録要求がSMTP [SMTP]、上記のセクション3に関連する拡張メカニズムの要件と意図と一致していることを確認する必要があります。それに応じてアドバイスを提供します。
The IANA has registered the limits specified in Section 4 of this document.
IANAは、このドキュメントのセクション4で指定された制限を登録しています。
[ABNF] 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>.
[PIPELINING]
Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920,
September 2000, <https://www.rfc-editor.org/info/rfc2920>.
[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>.
[RFC5321a] Klensin, J., "Simple Mail Transfer Protocol", Section 2.2,
RFC 5321, October 2008,
<https://www.rfc-editor.org/rfc/rfc5321>.
[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>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
Extension for Authentication", RFC 4954,
DOI 10.17487/RFC4954, July 2007,
<https://www.rfc-editor.org/info/rfc4954>.
[LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
DOI 10.17487/RFC2033, October 1996,
<https://www.rfc-editor.org/info/rfc2033>.
[RFC5321b] Klensin, J., "Simple Mail Transfer Protocol",
Section 4.5.3.1, RFC 5321, October 2008,
<https://www.rfc-editor.org/rfc/rfc5321>.
[RFC5321c] Klensin, J., "Simple Mail Transfer Protocol",
Section 4.5.3.1.8, RFC 5321, October 2008,
<https://www.rfc-editor.org/rfc/rfc5321>.
[SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10, RFC 1870,
DOI 10.17487/RFC1870, November 1995,
<https://www.rfc-editor.org/info/rfc1870>.
[STARTTLS] 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>.
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>.
The concept for this extension came from, and was developed by, Ned Freed and most of this specification, including substantially all of the technical details, was written by him. Unfortunately, he became ill and eventually passed away in May 2022 without being able to complete the document and manage it through IETF Last Call. His contributions to the Internet, work in the IETF, and the personal style that made both possible are irreplaceable and greatly missed. With the support of the community, John Klensin picked the document up, responded to some additional feedback, and got the document into what is believed to be a finished state. In the interest of preserving this as Ned's document, a few comments that proposed additional features and options were set aside for future work rather than our having to guess at whether Ned would have approved of them.
この拡張の概念は、Ned Freedによって生まれ、開発され、この仕様のほとんどは、実質的にすべての技術的詳細を含めて、彼によって書かれました。残念ながら、彼は病気になり、最終的には2022年5月に亡くなりました。これは、文書を完成させてIETFの最後の呼び出しを通じて管理することができませんでした。インターネットへの彼の貢献、IETFでの仕事、そして両方を可能にした個人的なスタイルはかけがえのないものであり、非常に見逃されています。コミュニティのサポートにより、ジョン・クレンシンは文書を取り上げ、いくつかの追加のフィードバックに応答し、完成した状態と思われるものに文書を入力しました。これをNEDの文書として保存するために、追加の機能とオプションを提案したいくつかのコメントは、NEDがそれらを承認したかどうかを推測するのではなく、将来の仕事のために確保されました。
The acknowledgments below are divided into two parts, those written by Ned and those associated with input to the document after his passing.
以下の謝辞は、NEDによって書かれたものと、彼が亡くなった後にドキュメントへの入力に関連する2つの部分に分けられます。
* Acknowledgments from the Last Version Prepared by Ned Freed
* Ned Freedが作成した最後のバージョンの謝辞
* A lot of people have helped make this specification possible. The author wishes to thank Claus Assmann, Laura Atkins, Alex Brotman, Richard Clayton, Dave Crocker, Viktor Dukhovni, Arnt Gulbrandsen, Jeremy Harris, Todd Herr, Mike Hillyer, Matthias Leisi, John Klensin, Valdis Klētnieks, John Levine, Alexey Melnikov, Keith Moore, Michael Peddemors, Hector Santos, George Schlossnagle, Rolf E. Sonneveld, and Alessandro Vesely for their contributions and reviews.
* 多くの人々がこの仕様を可能にするのを助けてきました。著者は、Claus Assmann、Laura Atkins、Alex Brotman、Richard Clocker、Dave Crocker、Viktor Dukhovni、Arnt Gulbrandsen、Jeremy Harris、Todd Herr、Mike Hillyer、Matthias Leisi、John Klensin、ValdisKlētnieks、John leabine、Johtキース・ムーア、マイケル・ペデマーズ、ヘクター・サントス、ジョージ・シュロスナグル、ロルフ・E・ソンネヴェルド、アレッサンドロ・ヴェスリーの貢献とレビュー。
* Acknowledgments from Versions Subsequent to Ned Freed's Passing
* Ned Freedが亡くなった後のバージョンからの謝辞
* Additional helpful suggestions were received when the draft was requeued in the last part of 2022 and thereafter. Reviews and suggestions from Alex Brotman, Dave Crocker, Gene Hightower, Murray S. Kucherawy, Barry Leiba, John Levine, and Phil Pennock were especially helpful in identifying errors and suggesting clarifying some issues with the document without changing Ned's fundamental issues or very much of his text.
* 2022年の最後の部分以降、ドラフトが要求されたときに、追加の有用な提案が受けられました。アレックス・ブロットマン、デイブ・クロッカー、ジーン・ハイタワー、マレー・S・クチェラウィー、バリー・レイバ、ジョン・レバイン、フィル・ペノックからのレビューと提案は、ネッドの基本的な問題を変更せずにドキュメントでいくつかの問題を明確にするのに特に役立ちました。彼のテキスト。
* IETF Last Call comments (and comments immediately before it started) from people not listed above that resulted in document changes were received from Amanda Baber (for IANA), Linda Dunbar, and Paul Kyzivat.
* IETFの最後のコメント（および開始の直前にコメント）上記に記載されていない人々からのコメント（およびIANAの場合）、Linda Dunbar、およびPaul Kyzivatからドキュメントの変更を受けました。
Ned Freed
John C. Klensin
1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140
United States of America
Email: john-ietf@jck.com