Network Working Group R. Gellens
Request for Comments: 4409 QUALCOMM
Obsoletes: 2476 J. Klensin
Category: Standards Track April 2006
Message Submission for Mail
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
このメモは、各サービスは、（セキュリティ、ポリシー、などのために）独自のルールに従って動作することができ、メッセージ中継からのメッセージ送信を分割し、アクションが提出サーバが取るべきであるかを指定します。
Message relay and final delivery are unaffected, and continue to use SMTP over port 25.
メッセージリレーと最終的な配信は影響を受けませんし、ポート25上でSMTPを使用し続けています。
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
この文書に準拠する場合は、メッセージ送信は、通常はポート587を介して、ここで指定したプロトコルを使用しています。
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements.
機能のこの分離は、特定のセキュリティやポリシー要件を適用する機能など、多くの利点を提供しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Document Information ............................................4
2.1. Definitions of Terms Used in This Memo .....................4
2.2. Conventions Used in This Document ..........................5
3. Message Submission ..............................................5
3.1. Submission Identification ..................................5
3.2. Message Rejection and Bouncing .............................5
3.3. Authorized Submission ......................................6
4. Mandatory Actions ...............................................7
4.1. General Submission Rejection Code ..........................7
4.2. Ensure All Domains Are Fully-Qualified .....................7
4.3. Require Authentication .....................................8
5. Recommended Actions .............................................8
5.1. Enforce Address Syntax .....................................8
5.2. Log Errors .................................................8
6. Optional Actions ................................................9
6.1. Enforce Submission Rights ..................................9
6.2. Enforce Permissions ........................................9
6.3. Check Message Data .........................................9
6.4. Support for the Postmaster Address .........................9
7. Interaction with SMTP Extensions ...............................10
8. Message Modifications ..........................................11
8.1. Add 'Sender' ..............................................11
8.2. Add 'Date' ................................................11
8.3. Add 'Message-ID' ..........................................11
8.4. Transfer Encode ...........................................11
8.5. Sign the Message ..........................................11
8.6. Encrypt the Message .......................................12
8.7. Resolve Aliases ...........................................12
8.8. Header Rewriting ..........................................12
9. Security Considerations ........................................12
10. IANA Considerations ...........................................13
11. Acknowledgements ..............................................13
12. Normative References ..........................................14
13. Informative References ........................................14
SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages.
SMTPメッセージとして定義された*転送*プロトコル、すなわち、経路の手段（必要な場合）、完成（完了）メッセージを配信します。
Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA].
[SMTP-MTA]によって必要とされるように、メッセージ転送エージェント（MTA）は、「受信」、「リターンパス」を追加することを除いて、メッセージ・テキストを変更することになって、および他のヘッダフィールドれません。
However, SMTP is now also widely used as a message *submission* protocol, that is, a means for Message User Agents (MUAs) to introduce new messages into the MTA routing network. The process that accepts message submissions from MUAs is termed a Message Submission Agent (MSA).
ただし、SMTPは今も広くメッセージ*提出*プロトコルとして使用され、それは、MTAのルーティングネットワークに新しいメッセージを紹介するメッセージユーザエージェント（MUA）のための手段です。 MUAからのメッセージの送信を受け入れるプロセスは、メッセージ服従エージェント（MSA）と呼ばれています。
In order to permit unconstrained communications, SMTP is not often authenticated during message relay.
制約のない通信を可能にするためには、SMTPは、多くの場合、メッセージ中継中に認証されません。
Authentication and authorization of initial submissions have become increasingly important, driven by changes in security requirements and rising expectations that submission servers take responsibility for the message traffic they originate.
最初の提出の認証と承認は、セキュリティ要件の変化と服従サーバは、彼らが発信メッセージトラフィックのための責任を取るの上昇期待に牽引され、ますます重要になってきました。
For example, due to the prevalence of machines that have worms, viruses, or other malicious software that generate large amounts of spam, many sites now prohibit outbound traffic on the standard SMTP port (port 25), funneling all mail submissions through submission servers.
たとえば、スパムを大量に生成するワーム、ウイルス、またはその他の悪意のあるソフトウェアを使用しているマシンの普及のために、多くのサイトは現在、提出サーバーを介してすべてのメール送信をファネリング、標準のSMTPポート（ポート25）でアウトバウンドトラフィックを禁止しています。
In addition to authentication and authorization issues, messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in one or more aspects. Unfinished messages may need to be completed to ensure they conform to [MESSAGE-FORMAT], and later requirements. For example, the message may lack a proper 'Date' header field, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished messages (e.g., it might not know its time zone). Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way, e.g., to conceal local name or address spaces. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are in general considered to be outside the province of standardized MTA functionality.
認証と認可の問題に加えて、提出されたメッセージは、いくつかのケースでは（完全な）メッセージを終了し、それ以外の場合は、1つまたは複数の態様で（不完全）未完成です。未完成のメッセージは、彼らが[MESSAGE-FORMAT]、および以降の要件に適合を確認するために完了する必要があるかもしれません。例えば、メッセージは、適切な「日付」ヘッダフィールドを欠いて、およびドメインは、完全修飾ではないかもしれません。いくつかのケースでは、MUAは、完成したメッセージを（例えば、それはその時間帯を知らないかもしれない）を生成することができない場合があります。送信されたメッセージが完了した場合でも、ローカルサイトのポリシーは、メッセージのテキストはローカル名またはアドレススペースを隠すために、例えば、何らかの方法で検討または変更することを指示することができます。つまり、最初のホップ提出MTA後のMTA - を - と、一般的に標準化されたMTA機能の地域外であると考えられている下流のMTAによって実行されるとき、そのような補完または修正は、害を引き起こすことが示されています。
Separating messages into submissions and transfers allows developers and network administrators to more easily do the following:
提出転送にメッセージを分離することで、開発者とネットワーク管理者はより簡単に、次のことを行うことができます。
* Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail
*不正なメールリレーや迷惑メールの注入に対するセキュリティポリシーとガードを実装
* Implement authenticated submission, including off-site submission by authorized users such as travelers
*などの旅行者として許可されたユーザにより、オフサイトの提出を含め、認証済みの提出を実装
* Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission
*これにより、各コードベースがより簡単作り、リレーと服従のためのさまざまなプログラムを可能にし、関連するソフトウェアコードの違いを分離
* Detect configuration problems with a site's mail clients
*サイトのメールクライアントで構成の問題を検出
* Provide a basis for adding enhanced submission services in the future
*将来的に強化提出サービスを追加するための基礎を提供
This memo describes a low-cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server.
このメモは提出として識別されるメッセージのための低コスト、決定論的手段を記載し、アクションが提出サーバが取るべきであるかを指定します。
Many of the concepts and terms used in this document are defined in [SMTP-MTA]; familiarity with those documents is assumed here.
本書で使用される概念および用語の多くは、[SMTP-MTA]で定義されています。それらの文書に精通しているものとします。
Fully-Qualified
完全修飾
Containing or consisting of a domain that can be globally resolved using the Domain Name Service; that is, not a local alias or partial specification.
含むまたはグローバルドメインネームサービスを使用して解決することができるドメインからなります。それは、ローカル別名または部分的な仕様ではありません。
Message Submission Agent (MSA)
メッセージ服従エージェント（MSA）
A process that conforms to this specification. An MSA acts as a submission server to accept messages from MUAs, and either delivers them or acts as an SMTP client to relay them to an MTA.
この仕様に準拠したプロセス。 MSAはのMUAからのメッセージを受け付けるように服従サーバとして機能し、いずれかのMTAにそれらを中継するようにSMTPクライアントとしてそれらまたは行為を提供します。
Message Transfer Agent (MTA)
メッセージ転送エージェント（MTA）
A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server to accept messages from an MSA or another MTA, and either delivers them or acts as an SMTP client to relay them to another MTA.
[SMTP-MTA]に準拠プロセス。 MTAは、MSAまたは別のMTAからのメッセージを受け入れるようにSMTPサーバとして機能し、いずれかの別のMTAにそれらを中継するようにSMTPクライアントとしてそれらまたは行為を提供します。
Message User Agent (MUA)
メッセージユーザエージェント（MUA）
A process that acts (often on behalf of a user and with a user interface) to compose and submit new messages, and process delivered messages.
新しいメッセージを作成し、提出する（多くの場合、ユーザーの代わりに、ユーザーインターフェイスを持つ）に作用し、プロセスがメッセージを配信プロセス。
For delivered messages, the receiving MUA may obtain and process the message according to local conventions or, in what is commonly referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP [IMAP4] is used to access delivered messages, whereas the protocol defined here (or SMTP) is used to submit messages.
配信されるメッセージのために、受信したMUAは、取得及び一般分割MUAモデルと呼ばれるもので、ポストオフィスプロトコル[POP3]またはIMAP [IMAP4]をアクセスするために使用されるローカル規則に従ってメッセージまたは、メッセージを配信し処理することができます一方（またはSMTP）ここで定義されたプロトコルは、メッセージを送信するために使用されます。
In examples, "C:" is used to indicate lines sent by the client, and "S:" indicates those sent by the server. Line breaks within a command example are for editorial purposes only.
実施例では、「C：」がクライアントによって送信されたラインを示すために使用され、そして「S：」はサーバによって送信されたものを示しています。コマンド例内の改行は編集のみを目的としています。
Examples use the 'example.net' domain.
例としては、「example.net」ドメインを使用しています。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].
[KEYWORDS]で定義されるようにキーワード "MUST" は、 "MUST NOT"、 "SHOULD NOT"、および本書で解釈されるべきである、 "MAY"、 "SHOULD"。
Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with additional restrictions or allowances as specified here.
この文書で指定されたポート587は、電子メールメッセージの提出のために予約されています。このポートで受信したメッセージは、提出になるように定義されています。ここで指定されるように使用されるプロトコルは、追加の制限又は手当と、ESMTP [SMTP-MTA、ESMTP]です。
Although most email clients and servers can be configured to use port 587 instead of 25, there are cases where this is not possible or convenient. A site MAY choose to use port 25 for message submission, by designating some hosts to be MSAs and others to be MTAs.
ほとんどの電子メールクライアントとサーバは、ポート587の代わりに25を使用するように構成することができますが、これが可能か、便利ではない場合があります。サイトでは、MTAが可能にするのMSAと他の人であることをいくつかのホストを指定することにより、メッセージ送信用のポート25を使用することもできます。
MTAs and MSAs MAY implement message rejection rules that rely in part on whether the message is a submission or a relay.
MTAとのMSAは、メッセージが提出またはリレーであるかどうかに部分的に依存しているメッセージ拒否ルールを実装するかもしれません。
For example, some sites might configure their MTAs to reject all RCPT commands for messages that do not reference local users, and configure their MSA to reject all message submissions that do not come from authorized users, with authorization based either on authenticated identity or the submitting endpoint being within a protected IP environment.
例えば、いくつかのサイトは、RCPTは、ローカルユーザーを参照し、いずれかの認証されたIDや提出に基づいて承認し、許可されたユーザーから来ていないすべてのメッセージの送信を拒否するように彼らのMSAを設定していないメッセージに対してコマンドすべてを拒否するために彼らのMTAを構成することができますエンドポイントは、保護されたIP環境内にあります。
NOTE: It is better to reject a message than to risk sending one that is damaged. This is especially true for problems that are correctable by the MUA, for example, an invalid 'From' field.
注：これは、損傷しているものを送信するリスクよりもメッセージを拒否することをお勧めします。これは、「From」フィールドに無効な、例えば、MUAによって訂正されている問題は特に顕著です。
If an MSA is not able to determine a return path to the submitting user, from a valid MAIL FROM, a valid source IP address, or based on authenticated identity, then the MSA SHOULD immediately reject the message. A message can be immediately rejected by returning a 550 code to the MAIL command.
MSAは、有効なMAILから、提出するユーザーにリターンパスを決定することができない場合には有効な送信元IPアドレス、FROM、または認証されたIDに基づいて、その後、MSAはメッセージを拒否し、すぐにすべきです。メッセージは直ちにMAILコマンドに550コードを返すことによって排除することができます。
Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST NOT in itself be cause for rejecting a message. (MUAs need to generate null return-path messages for a variety of reasons, including disposition notifications.)
ヌルリターンパスことに注意してください、それは、FROM MAILです：<>、許可されていると自分自身にメッセージを拒絶する原因にすることはできません。 （MUAを処分通知など、さまざまな理由でヌルリターンパスメッセージを生成する必要があります。）
Except in the case where the MSA is unable to determine a valid return path for the message being submitted, text in this specification that instructs an MSA to issue a rejection code MAY be complied with by accepting the message and subsequently generating a bounce message. (That is, if the MSA is going to reject a message for any reason except being unable to determine a return path, it can optionally do an immediate rejection or accept the message and then mail a bounce.)
MSAが送信されるメッセージの有効なリターンパスを決定することができない場合を除いて、拒否コードを発行するようにMSAを指示する本明細書のテキストは、メッセージを受け入れ、その後、バウンスメッセージを生成することによって遵守されるかもしれません。 （MSAがリターンパスを決定できないことを除き、いかなる理由でメッセージを拒否しようとしている場合である。すなわち、それは、必要に応じて即座に拒絶反応を行うか、メッセージを受け入れ、その後、バウンスを郵送することができます。）
NOTE: In the normal case of message submission, immediately rejecting the message is preferred, as it gives the user and MUA direct feedback. To properly handle delayed bounces, the client MUA needs to maintain a queue of messages it has submitted, and match bounces to them. Note that many contemporary MUAs do not have this capability.
注：ユーザとMUA直接フィードバックを与えるようにメッセージ送信の正常な場合には、即座にメッセージを拒否することは、好ましいです。適切な遅延バウンスを処理するには、クライアントMUAはそれが提出されたメッセージのキューを維持する必要がある、との一致はそれらに跳ね返ります。多くの現代のMUAは、この能力を持っていないことに注意してください。
Numerous methods have been used to ensure that only authorized users are able to submit messages. These methods include authenticated SMTP, IP address restrictions, secure IP and other tunnels, and prior POP authentication.
多数の方法が許可されたユーザーのみがメッセージを送信することが可能であることを保証するために使用されています。これらのメソッドは、認証されたSMTP、IPアドレス制限、セキュアなIPおよび他のトンネル、および前のPOP認証が含まれます。
Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It allows the MSA to determine an authorization identity for the message submission, one that is not tied to other protocols.
認証されたSMTP [SMTP-AUTH]は広範囲の展開を見ています。これは、MSAは、メッセージ送信、他のプロトコルに縛られていない1の承認同一性を決定することができます。
IP address restrictions are very widely implemented, but do not allow for travelers and similar situations, and can be easily spoofed unless all transport paths between the MUA and MSA are trustworthy.
IPアドレスの制限は非常に広く実装されていますが、旅行者や似たような状況のために許可されていませんし、MUAとMSAの間のすべてのトランスポートパスが信頼されている場合を除き、容易に詐称することができます。
Secure IP [IPSEC], and other encrypted and authenticated tunneling techniques, can also be used and provide additional benefits of protection against eavesdropping and traffic analysis.
セキュアIP [IPSEC]、およびその他の暗号化と認証されたトンネリング技術は、また、使用および盗聴とトラフィック解析からの保護の追加の利点を提供することができます。
Requiring a POP [POP3] authentication (from the same IP address) within some amount of time (e.g., 20 minutes) prior to the start of a message submission session has also been used, but this does impose restrictions on clients as well as servers, which may cause difficulties. Specifically, the client must do a POP authentication before an SMTP submission session, and not all clients are capable and configured for this. Also, the MSA must coordinate with the POP server, which may be difficult. There is also a window during which an unauthorized user can submit messages and appear to be a previously authorized user. Since it is dependent on the MUA's IP addresses, this technique is substantially as subject to IP address spoofing as validation based on known IP addresses alone (see above).
メッセージ送信セッションの開始前にも使用されている（例えば、20分）ある程度の時間内に（同じIPアドレスからの）POP [POP3]認証を必要とするが、これは、クライアント上の制限だけでなく、サーバを課すん、困難を起こす可能性があります。具体的には、クライアントはSMTP送信セッションの前にPOP認証を行う必要があります、そしてないすべてのクライアントが可能であり、このために設定します。また、MSAは難しいかもしれPOPサーバー、と調整しなければなりません。権限のないユーザーがメッセージを送信すると、以前に許可されたユーザであることを表示することができ、その間窓もあります。それはMUAのIPアドレスに依存するので、この技術は、（上記参照）は、実質的に単独で既知のIPアドレスに基づいて検証としてIPスプーフィングを受けるようになります。
An MSA MUST do all of the following:
MSAは、以下のすべてを行う必要があります：
Unless covered by a more precise response code, response code 554 is to be used to reject a MAIL, RCPT, or DATA command that contains something improper.
より正確な応答コードによってカバーされない限り、応答コード554が不適切なものが含まれているMAIL、RCPT、またはDATAコマンドを拒否するために使用されるべきです。
The MSA MUST ensure that all domains in the SMTP envelope are fully-qualified.
MSAは、SMTPエンベロープ内のすべてのドメインは、完全修飾されていることを確認しなければなりません。
If the MSA examines or alters the message text in any way, except to add trace header fields [SMTP-MTA], it MUST ensure that all domains in address header fields are fully-qualified.
MSAは、トレースヘッダフィールド[SMTP-MTA]を追加する場合を除き、どのような方法でメッセージ・テキストを検査または変更する場合は、アドレスヘッダフィールド内のすべてのドメインは、完全修飾されていることを確認しなければなりません。
Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command that contains improper domain references.
応答コード554は、不適切なドメイン参照を含むMAIL、RCPT、またはDATAコマンドを拒否するために使用されるべきです。
A frequent local convention is to accept single-level domains (e.g., 'sales') and then to expand the reference by adding the remaining portion of the domain name (e.g., to 'sales.example.net'). Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains (e.g., 'squeaky.sales'), since such expansion is particularly risky.
頻繁にローカル規則は、単一レベルドメイン（例えば、「売上高」）を受け入れ、次いで、（例えば、「sales.example.net」に）ドメイン名の残りの部分を追加することによって、基準を拡大することです。そのような拡張は、特に危険であるので、単一レベルドメインを可能にするローカル規則は、拒否ではなく、展開、不完全なマルチレベルのドメイン（例えば、「squeaky.sales」）すべきです。
The MSA MUST by default issue an error response to the MAIL command if the session has not been authenticated using [SMTP-AUTH], unless it has already independently established authentication or authorization (such as being within a protected subnetwork).
デフォルトの問題によってMSAのMUST MAILコマンドにエラー応答が既に独立して（例えば、保護されたサブネットワーク内にあるような）認証または認可を確立していない限り、セッションは、[SMTP-AUTH]を使用して認証されていない場合。
Section 3.3 discusses authentication mechanisms.
3.3節には、認証メカニズムについて説明します。
Reply code 530 [SMTP-AUTH] is used for this purpose.
コード530を返信[SMTP-AUTH]この目的のために使用されます。
The MSA SHOULD do all of the following:
MSAは、次のすべてを実行する必要があります。
An MSA SHOULD reject messages with illegal syntax in a sender or recipient SMTP envelope address.
MSAは、送信者または受信者のSMTPエンベロープアドレスに不正な構文を使用してメッセージを拒否すべきです。
If the MSA examines or alters the message text in way, except to add trace header fields, it SHOULD reject messages with illegal address syntax in address header fields.
MSAはある意味では、メッセージテキストを調べたり変更した場合は、トレースヘッダフィールドを追加することを除いて、それはアドレスヘッダフィールド内のアドレスが無効の構文を使用してメッセージを拒否すべきです。
Reply code 501 is to be used to reject a MAIL or RCPT command that contains a detectably improper address.
応答コード501は、検出不適切なアドレスが含まれているメールやRCPTコマンドを拒否するために使用されます。
When addresses are resolved after submission of the message body, reply code 554 (with a suitable enhanced status code from [SMTP-CODES]) is used after end-of-data, if the message contains invalid addresses in the header.
アドレスは、メッセージ本体の提出後に解決されている場合、コード554の応答メッセージは、ヘッダ内の無効なアドレスが含まれている場合（[SMTP-CODES]から適切な拡張状態コードで）、エンド・オブ・データの後に使用されます。
The MSA SHOULD log message errors, especially apparent misconfigurations of client software.
MSAはメッセージの誤り、クライアントソフトウェアの特に見かけの設定ミスがログインする必要があります。
It can be very helpful to notify the administrator when problems are detected with local mail clients. This is another advantage of distinguishing submission from relay: system administrators might be interested in local configuration problems, but not in client problems at other sites.
問題がローカルのメールクライアントで検出されたときに管理者に通知するために非常に役立ちます。ではなく、他のサイトでのクライアントの問題では、ローカル設定の問題に興味があるかもしれないシステム管理者：これはリレーから提出を区別するのもう1つの利点です。
Note that it is important to impose limits on such logging to prevent certain forms of denial of service (DoS) attacks.
サービス拒否（DoS）攻撃の拒否の特定の形態を防ぐために、このようなログに制限を課すことが重要であることに注意してください。
The MSA MAY do any of the following:
MSAは、次のいずれかの操作を行うことがあります。
The MSA MAY issue an error response to a MAIL command if the address in MAIL FROM appears to have insufficient submission rights, or is not authorized with the authentication used (if the session has been authenticated).
FROM MAILのアドレスが不足提出権を持っているように見えます、または（セッションが認証されている場合）を使用した認証と認可されていない場合、MSAは、MAILコマンドにエラー応答を発行することができます。
Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.
例えば5.7.1ようSMTP-CODES]当たりの適切な拡張状態コードとコード550を返信、この目的のために使用されます。
The MSA MAY issue an error response to a RCPT command if inconsistent with the permissions given to the user (if the session has been authenticated).
ユーザーに与えられた権限と矛盾している場合（セッションが認証されている場合）MSAはRCPTコマンドにエラー応答を発行することができます。
Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.
例えば5.7.1ようSMTP-CODES]当たりの適切な拡張状態コードとコード550を返信、この目的のために使用されます。
The MSA MAY issue an error response to the DATA command or send a failure result after end-of-data if the submitted message is syntactically invalid, or seems inconsistent with permissions given to the user (if known), or violates site policy in some way.
MSAは、DATAコマンドにエラー応答を発行または提出したメッセージが構文的に無効である、またはユーザー（既知の場合）に与えられた権限と矛盾するようだ、または一部で、サイトのポリシーに違反している場合、エンド・オブ・データの後に失敗した結果を送信することができ仕方。
Reply code 554 is used for syntactic problems in the data. Reply code 501 is used if the command itself is not syntactically valid. Reply code 550 with an appropriate enhanced status code per [SMTP-CODES] (such as 5.7.1) is used to reject based on the submitting user. Reply code 550 with an appropriate enhanced status code (such as 5.7.0) is used if the message violates site policy.
応答コード554は、データに構文の問題のために使用されます。コマンド自体は構文的に有効でない場合、応答コード501が使用されています。 [SMTP-CODES]あたりの適切な拡張状態コード（例えば、5.7.1など）を用いてコード550を返信をサブミットするユーザに基づいて拒否するために使用されます。メッセージがサイトポリシーに違反している場合に使用される適切な拡張状態コード（例えば、5.7.0など）を用いてコード550を返信。
If appropriate under local conditions and to facilitate conformance with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit a reduced degree of authentication for mail addressed to the "postmaster" (or one of its alternate spelling forms, see [SMTP-MTA]), in one or more domains, as compared to requirements enforced for other addresses. Among other benefits, this provides an address of last resort that can be used by authorized users to report problems that otherwise prevent them from submitting mail.
ローカル条件下で[SMTP-MTA]の「ポストマスター」要件との適合を容易にするために、適切な場合、MSAは、メールが「ポストマスター」宛の認証の減少度を可能にすることができる（又はその代替スペリングの形態の一つは、[参照しますSMTP-MTA]）、1つ以上のドメインで、他のアドレスに適用要件に比べ。他の利点の中で、これは、そうでない場合は、メールを提出することを妨げる問題を報告するために許可されたユーザが使用することができ、最後のアドレスを提供します。
The following table lists the current standards-track and Experimental SMTP extensions. Listed are the EHLO keyword, name, an indication as to the use of the extension on the submit port, and a reference:
次の表は、現在の標準トラックと実験SMTP拡張を示しています。上場EHLOキーワード、名前、提出ポートに拡張の使用に関する指示、および参照されています：
Keyword Name Submission Reference
---------- -------------------------- ---------- ----------------
PIPELINING Pipelining SHOULD [PIPELINING]
ENHANCEDSTATUSCODES Enhanced Status Codes SHOULD [CODES-EXTENSION]
ETRN Extended Turn MUST NOT [ETRN]
... Extended Codes SHOULD [SMTP-CODES]
DSN Delivery Status Notification SHOULD [DSN]
SIZE Message size MAY [SIZE]
... 521 reply code MUST NOT [521REPLY]
CHECKPOINT Checkpoint/Restart MAY [CHECKPOINT]
BINARYMIME Binary MIME MAY [CHUNKING]
CHUNKING Chunking MAY [CHUNKING]
8BITMIME Use 8-bit data SHOULD [8BITMIME]
AUTH Authentication MUST [SMTP-AUTH]
STARTTLS Start TLS MAY [Start-TLS]
NO-SOLICITING Notification of no soliciting MAY [Msg-Track]
MTRK Message Tracking MAY [Msg-Track]
Future SMTP extensions SHOULD explicitly specify if they are valid on the Submission port.
彼らはサブミッションポート上で有効な場合、将来のSMTPの拡張を明示的に指定する必要があります。
Some SMTP extensions are especially useful for message submission:
一部のSMTPの拡張機能は、メッセージの送信に特に有用です：
Extended Status Codes [SMTP-CODES] SHOULD be supported and used according to [CODES-EXTENSION]. This permits the MSA to notify the client of specific configuration or other problems in more detail than the response codes listed in this memo. Because some rejections are related to a site's security policy, care should be used not to expose more detail to unauthenticated senders than is needed
拡張ステータスコード[SMTP-CODES]は[CODES-EXTENSION]に記載の支持され使用されてください。これは、このメモに記載されている応答コードよりも詳細で具体的な構成や他の問題のクライアントに通知するためにMSAを可能にします。いくつかの拒否は、サイトのセキュリティポリシーに関連しているので、注意が必要とされているよりも、未認証の送信者に詳細を公開しないように使用すべきです
[PIPELINING] SHOULD be supported by the MSA.
[PIPELINING]はMSAによってサポートされてください。
[SMTP-AUTH] allows the MSA to validate the authority and determine the identity of the submitting user and MUST be supported by the MSA.
[SMTP-AUTH]はMSAが権限を検証し、提示ユーザーの同一性を決定することを可能にし、MSAによってサポートされなければなりません。
Any references to the DATA command in this memo also refer to any substitutes for DATA, such as the BDAT command used with [CHUNKING].
このメモでDATAコマンドへの任意の言及はまた、[CHUNKING]と共に使用BDATコマンドなどのデータのための任意の代替物、を指します。
Sites MAY modify submissions to ensure compliance with standards and site policy. This section describes a number of such modifications that are often considered useful.
サイトは、基準とサイトポリシーの遵守を確保するために提出を変更することができます。このセクションでは、しばしば有用であると考えているような修飾の数を示します。
NOTE: As a matter of guidance for local decisions to implement message modification, a paramount rule is to limit such actions to remedies for specific problems that have clear solutions. This is especially true with address elements. For example, indiscriminately appending a domain to an address or element that lacks one typically results in more broken addresses. An unqualified address must be verified to be a valid local part in the domain before the domain can be safely added.
注：メッセージの変更を実装するために地元の意思決定のための指針の問題として、最優先ルールが明確な解決策を持っている特定の問題のための救済に、そのような行動を制限することです。これは、アドレス要素と特にそうです。例えば、無差別アドレス又は典型的には、1つを欠く、より壊れたアドレスになる要素にドメインを追加します。ドメインを安全に追加することができます前に、資格のないアドレスは、ドメイン内の有効なローカル部分であることが確認されなければなりません。
Any message forwarded or delivered by the MSA MUST conform to the requirements of [SMTP-MTA] and [MESSAGE-FORMAT].
MSAによって転送または配信されたメッセージは、[SMTP-MTA]と[MESSAGEフォーマット]の要件に適合しなければなりません。
The MSA MAY add or replace the 'Sender' field, if the identity of the sender is known and this is not given in the 'From' field.
送信者の身元が知られており、これは、「From」フィールドに指定されていない場合は、MSAは、「送信者」欄を追加したり、交換することができます。
The MSA MUST ensure that any address it places in a 'Sender' field is in fact a valid mail address.
MSAは、それが「送信者」欄に置く任意のアドレスが実際に有効なメールアドレスであることを保証しなければなりません。
The MSA MAY add a 'Date' field to the submitted message, if it lacks it, or correct the 'Date' field if it does not conform to [MESSAGE-FORMAT] syntax.
MSAは、それはそれが欠けている場合は、提出されたメッセージに「日付」フィールドを追加、またはそれが[MESSAGE-FORMAT]の構文に準拠していない場合は、「日付」フィールドを補正してもよいです。
The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note that a number of clients still do not generate Message-ID fields.
MSAは、追加または交換する「メッセージID」欄に、それはそれがない場合、またはそれが（[MESSAGE-FORMAT]で定義されている）有効な構文ではありませんすべきです。クライアントの数がまだメッセージIDフィールドを生成しないことに注意してください。
The MSA MAY apply transfer encoding to the message according to MIME conventions, if needed and not harmful to the MIME type.
MIMEタイプに有害で必要とされていない場合MSAは、MIMEの規則に従ってメッセージを転送エンコーディングを適用することができます。
The MSA MAY (digitally) sign or otherwise add authentication information to the message.
MSA MAYは（デジタル）署名またはそれ以外の場合は、メッセージに認証情報を追加します。
The MSA MAY encrypt the message for transport to reflect organizational policies.
MSAは、組織のポリシーを反映するために、輸送のためのメッセージを暗号化することができます。
NOTE: To be useful, the addition of a signature and/or encryption by the MSA generally implies that the connection between the MUA and MSA must itself be secured in some other way, for example, by operating inside of a secure environment, by securing the submission connection at the transport layer, or by using an [SMTP-AUTH] mechanism that provides for session integrity.
注：有用であるために、MSAによる署名及び/又は暗号化の付加は、一般に、例えば、セキュアな環境の内部で動作させることにより、固定することにより、MUAとMSAとの間の接続は、それ自体が他の方法で固定されなければならないことを意味しますトランスポート層において、またはセッション完全性を提供する[SMTP-AUTH]メカニズムを使用して提出接続。
The MSA MAY resolve aliases (CNAME records) for domain names, in the SMTP envelope and optionally in address fields of the header, subject to local policy.
MSAは、SMTPエンベロープ内および必要に応じてローカルポリシーの対象とヘッダのアドレスフィールド内のドメイン名のエイリアス（CNAMEレコード）を、解決することができます。
NOTE: Unconditionally resolving aliases could be harmful. For example, if www.example.net and ftp.example.net are both aliases for mail.example.net, rewriting them could lose useful information.
注：無条件の解決エイリアスは、有害である可能性があります。例えば、もしwww.example.netとftp.example.netは、彼らが有用な情報を失う可能性が書き換え、両方mail.example.netの別名です。
The MSA MAY rewrite local parts and/or domains in the SMTP envelope, and optionally in address fields of the header, according to local policy. For example, a site may prefer to rewrite 'JRU' as 'J.Random.User' in order to hide login names, and/or to rewrite 'squeaky.sales.example.net' as 'zyx.example.net' to hide machine names and make it easier to move users.
MSAは、ローカルポリシーに従って、SMTPエンベロープ内、および必要に応じてヘッダのアドレスフィールドにローカル部分及び/又はドメインを書き換えるMAY。たとえば、サイトには、ログイン名を隠すために「J.Random.User」として「JRU」を書き換えることを好むこと、および/またはそれに「zyx.example.net」として「squeaky.sales.example.net」を書き換えるためにマシン名を隠し、それが簡単にユーザーを移動するために作ります。
However, only addresses, local-parts, or domains which match specific local MSA configuration settings should be altered. It would be very dangerous for the MSA to apply data-independent rewriting rules, such as always deleting the first element of a domain name. So, for example, a rule that strips the left-most element of the domain, if the complete domain matches '*.foo.example.net', would be acceptable.
ただし、アドレスのみ、ローカル部品、又は特定のローカルMSA構成設定と一致するドメインが変更されるべきです。 MSAは、常にドメイン名の最初の要素の削除など、データに依存しない書き換えルールを適用することは非常に危険です。したがって、たとえば、完全なドメインが一致した場合、ドメインの一番左の要素を取り除きルールは「* .foo.example.net」、許容可能です。
The MSA MUST NOT rewrite a forward-pointing (destination) address in a way that violates the constraints of [SMTP-MTA] on modifications of local-parts.
MSAは、ローカル部品の変形の[SMTP-MTA]の制約に違反するように前方を向い（宛先）アドレスを書き換えてはいけません。
Separation of submission and relay of messages allows a site to implement different policies for the two types of services, including requiring use of additional security mechanisms for one or both. It can do this in a way which is simpler, both technically and administratively. This increases the likelihood that policies will be applied correctly.
メッセージの投稿やリレーの分離は、サイトが一方または両方のための追加のセキュリティメカニズムの使用を必要とするなど、2種類のサービスのために異なるポリシーを実装することができます。これは、両方の技術的、管理上、単純な方法でこれを行うことができます。これは、ポリシーが正しく適用される可能性が高くなります。
Separation also can aid in tracking and preventing unsolicited bulk email.
分離はまた、追跡し、迷惑メールを防止するのを助けることができます。
For example, a site could configure its mail servers such that the MSA requires authentication before accepting a message, and the MTA rejects all RCPT commands for non-local users. This can be an important element in a site's total email security policy.
たとえば、サイトがMSAがメッセージを受け入れる前に認証を必要とするように、そのメールサーバを設定することができ、そしてMTAは非ローカルのユーザーのすべてのRCPTコマンドを拒否します。これは、サイトの総電子メールのセキュリティポリシーで重要な要素とすることができます。
If a site fails to require any form of authorization for message submissions (see section 3.3 for discussion), it is allowing open use of its resources and name; unsolicited bulk email can be injected using its facilities.
サイトには、メッセージの提出（議論のためのセクション3.3を参照）、それはそのリソースと名前の開いた使用が可能であるため、許可のいずれかの形式を必要とするために失敗した場合。迷惑メールは、その施設を利用して注入することができます。
Section 3 includes further discussion of issues with some authentication methods.
第3節では、いくつかの認証方法に問題のさらなる議論を含んでいます。
Section 5.2 includes a cautionary note that unlimited logging can enable certain forms of denial of service attacks.
5.2節では、無制限のログは、サービス拒否攻撃の特定の形態を可能にすることを警戒ノートを含んでいます。
The registration for port 587 has been updated to refer to this memo rather than RFC 2476.
ポート587の登録ではなく、RFC 2476よりも、このメモを参照するように更新されました。
Nathaniel Borenstein and Barry Leiba were instrumental in the development of this update to RFC 2476.
ナサニエル・ボレンスタインとバリー・レイバは、RFC 2476にこのアップデートの発展に尽力しました。
The original memo (RFC 2476) was developed in part based on comments and discussions which took place on and off the IETF-Submit mailing list. The help of those who took the time to review that document and make suggestions is appreciated, especially that of Dave Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.
オリジナルメモ（RFC 2476）は、IETF-提出メーリングリストのオンとオフ行われたコメントや議論に基づいて、一部で開発されました。その文書をレビューや提案をする時間を取った人たちの助けには、デイブ・クロッカー、ネッドフリード、キースムーア、ジョン・マイヤーズ、そしてクリス・ニューマンの、特にそれを高く評価しています。
Special thanks to Harald Alvestrand, who got this effort started.
この努力を得たハラルドAlvestrand、に感謝を開始しました。
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[ESMTP] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "SMTPサービス拡張"、STD 10、RFC 1869、1995年11月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP-MTA]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
Partridge, C., "Mail routing and the domain
system", STD 10, RFC 974, January 1986.
Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995.
[521REPLY]デュラン、A.およびF.デュポン、 "SMTP 521応答コード"、RFC 1846、1995年9月。
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[8BITMIME] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "8ビット・MIMEtransportためのSMTPサービス拡張"、RFC 1652、1994月。
[CHECKPOINT] Crocker, D., Freed, N., and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.
[CHECKPOINT]クロッカー、D.、フリード、N.、およびA.カーギル、 "チェックポイント/リスタートのためのSMTPサービス拡張"、RFC 1845、1995年9月。
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
、RFC 3030、2000年12月 "大規模およびバイナリMIMEメッセージを送信するためのSMTPサービス拡張" ヴォードルイユ、G.、[CHUNKING]を。
[CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[CODES-EXTENSION]、RFC 2034、1996年10月 "拡張エラーコードを返すためのSMTPサービス拡張"、N.を、フリード。
[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.
[ETRN]デ・冬、J.、 "リモートメッセージキューの開始のためのSMTPサービス拡張"、RFC 1985、1996年8月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[MESSAGE-FORMAT]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
Resnick, P., "Internet Message Format", RFC 2822, April 2001.
レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[Msg-Track] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.
[MSG-トラック]オールマン、E.とT.ハンセン、 "メッセージ追跡のためのSMTPサービス拡張"、RFC 3885、2004年9月。
[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[PIPELINING]解放され、N.、 "コマンドパイプラインのためのSMTPサービス拡張"、STD 60、RFC 2920、2000年9月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
[SIZE] Klensin、J.、フリード、N.、およびK.ムーア、 "SMTPサービス拡張メッセージのサイズ宣言"、STD 10、RFC 1870、1995年11月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-AUTH]マイヤーズ、J.、 "認証のためのSMTPサービス拡張子"、RFC 2554、1999年3月。
[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[SMTP-CODES]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月。
[Start-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[スタート-TLS]ホフマン、P.、 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"、RFC 3207、2002年2月。
Authors' Addresses
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-2779 USA
ランドールGellens QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121から2779 USA
EMail: rg+ietf@qualcomm.com
メールアドレス：rg+ietf@qualcomm.com
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンC. Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140 USA
EMail: john+ietf@jck.com
メールアドレス：john+ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。