[要約] RFC 6409は、メールのメッセージ送信のためのプロトコルであり、要約すると、メールの送信方法と手順を定義しています。このRFCの目的は、メールの送信プロセスを効率化し、信頼性を向上させることです。
Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 6409 QUALCOMM Incorporated
STD: 72 J. Klensin
Obsoletes: 4409 November 2011
Category: Standards Track
ISSN: 2070-1721
Message Submission for Mail
メールのメッセージ送信
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 is unaffected, and continues 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.
この機能の分離には、特定のセキュリティまたはポリシー要件を適用する機能など、多くの利点があります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6409.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6409で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Document Information ............................................5
2.1. Definitions of Terms Used in This Memo .....................5
2.2. Conventions Used in This Document ..........................6
3. Message Submission ..............................................6
3.1. Submission Identification ..................................6
3.2. Message Rejection and Bouncing .............................6
3.3. Authorized Submission ......................................7
4. Mandatory Actions ...............................................8
4.1. General Submission Rejection Code ..........................8
4.2. Ensure All Domains Are Fully Qualified .....................8
4.3. Require Authentication .....................................8
5. Recommended Actions .............................................9
5.1. Enforce Address Syntax .....................................9
5.2. Log Errors .................................................9
5.3. Apply Shorter Timeouts .....................................9
6. Optional Actions ...............................................10
6.1. Enforce Submission Rights .................................10
6.2. Enforce Permissions .......................................10
6.3. Check Message Data ........................................10
6.4. Support for the Postmaster Address ........................10
6.5. Adjust Character Encodings ................................11
7. Interaction with SMTP Extensions ...............................12
8. Message Modifications ..........................................13
8.1. Add 'Sender' ..............................................14
8.2. Add 'Date' ................................................14
8.3. Add 'Message-ID' ..........................................14
8.4. Transfer Encode ...........................................14
8.5. Sign the Message ..........................................14
8.6. Encrypt the Message .......................................14
8.7. Resolve Aliases ...........................................15
8.8. Header Rewriting ..........................................15
9. Security Considerations ........................................15
10. IANA Considerations ...........................................16
11. Acknowledgments ...............................................16
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
Appendix A. Major Changes from RFC 4409 ...........................20
SMTP [SMTP-MTA] was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages.
SMTP [SMTP-MTA]は、メッセージ*転送*プロトコルとして定義されました。つまり、ルーティング（必要な場合）および完了した（完全な）メッセージを配信する手段です。
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]. 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).
メッセージ転送エージェント（MTA）は、[SMTP-MTA]で必要とされる「Received」、「Return-Path」、およびその他のヘッダーフィールドを追加する場合を除いて、メッセージテキストを変更することは想定されていません。ただし、SMTPは現在、メッセージ*送信*プロトコルとして広く使用されています。つまり、メッセージユーザーエージェント（MUA）がMTAルーティングネットワークに新しいメッセージを導入する手段です。 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 the Message Format specification [MESSAGE-FORMAT] and related 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 do the following more easily:
メッセージを送信と転送に分離することにより、開発者とネットワーク管理者は次のことをより簡単に行うことができます。
o Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail.
o セキュリティポリシーを実装し、不正なメールの中継や迷惑なバルクメールの挿入から保護します。
o Implement authenticated submission, including off-site submission by authorized users such as travelers.
o 旅行者などの許可されたユーザーによるオフサイト提出を含む、認証された提出を実装します。
o Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission.
o 関連するソフトウェアコードの違いを分離することにより、各コードベースをより簡単にし、リレーとサブミット用のさまざまなプログラムを可能にします。
o Detect configuration problems with a site's mail clients.
o サイトのメールクライアントの構成の問題を検出します。
o Provide a basis for adding enhanced submission services.
o 強化された提出サービスを追加するための基礎を提供します。
This memo describes a low-cost, deterministic means for messages to be identified as submissions, and it 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 it either delivers them or acts as an SMTP client to relay them to an MTA.
この仕様に準拠するプロセス。 MSAはMUAからのメッセージを受け入れる送信サーバーとして機能し、MSAを配信するか、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 it either delivers them or acts as an SMTP client to relay them to another MTA.
[SMTP-MTA]に準拠したプロセス。 MTAは、MSAまたは別のMTAからのメッセージを受け入れるSMTPサーバーとして機能し、メッセージを配信するか、SMTPクライアントとして機能して、別のMTAにメッセージを中継します。
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 to 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モデルと呼ばれるものでは、Post Office Protocol [POP3]またはIMAP [IMAP4]を使用して配信されたメッセージにアクセスします。一方、ここで定義されたプロトコル（またはSMTP）は、メッセージの送信に使用されます。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」は、[KEYWORDS]で定義されているとおりに解釈されます。
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], with additional restrictions or allowances as specified here.
このドキュメントで指定されているとおり、ポート587は電子メールメッセージの送信用に予約されています。このポートで受信されたメッセージは発信と定義されています。使用されるプロトコルはESMTP [SMTP-MTA]であり、ここで指定されている追加の制限または許容値があります。
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.
ほとんどの電子メールクライアントとサーバーは、25ではなくポート587を使用するように構成できますが、これが不可能または不便な場合があります。サイトは、一部のホストをMSAに指定し、他のホストをMTAに指定することにより、メッセージ送信にポート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 they might configure their MSA to reject all message submissions that do not come from authorized users, with authorization based on either the authenticated identity or the submitting endpoint being within a protected IP environment.
たとえば、一部のサイトでは、ローカルユーザーを参照しないメッセージに対するすべてのRCPTコマンドを拒否するようにMTAを構成し、認証されたIDに基づいて承認された、承認されたユーザーからのものではないすべてのメッセージ送信を拒否するようにMSAを構成する場合があります。または、送信するエンドポイントが保護された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.
注：破損したメッセージを送信するリスクよりも、メッセージを拒否することをお勧めします。これは、MUAによって修正可能な問題、たとえば、無効な「From」フィールドに特に当てはまります。
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 FROM、有効な送信元IPアドレスから、または認証されたIDに基づいて、送信ユーザーへのリターンパスを決定できない場合、MSAは直ちにメッセージを拒否する必要があります（SHOULD）。 550コードをMAILコマンドに返すことにより、メッセージをすぐに拒否できます。
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.)
NULLの戻りパス、つまりMAIL FROM：<>は許可されており、それ自体がメッセージを拒否する原因となってはならないことに注意してください。 （MUAは、廃棄通知を含むさまざまな理由でnullの戻りパスメッセージを生成する必要があります。）
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.
Authenticated SMTP [SMTP-AUTH]は広く普及しています。これにより、MSAは他のプロトコルに関連付けられていない、メッセージ送信の承認IDを決定できます。
IP address restrictions are very widely implemented, but they do not allow for travelers and similar situations, and they 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分）にPOP [POP3]認証を要求する（同じIPアドレスから）ことも使用されていますが、これによりクライアントとサーバーに制限が課されます、問題が発生する可能性があります。具体的には、クライアントは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」など）を受け入れ、ドメイン名の残りの部分（「sales.example.net」など）を追加して参照を拡張することです。シングルレベルドメインを許可するローカル規約は、拡張が特に危険であるため、不完全なマルチレベルドメイン（「squeaky.sales」など）を拡張するのではなく、拒否する必要があります（SHOULD）。
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は、セッションが[SMTP-AUTH]を使用して認証されていない場合（認証されたサブネットワーク内など）に独立して認証または承認を確立していない限り、デフォルトでMAILコマンドにエラー応答を発行する必要があります。
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は以下のすべてを行う必要があります（SHOULD）。
An MSA SHOULD reject messages with illegal syntax in a sender or recipient SMTP envelope address.
MSAは、送信者または受信者のSMTPエンベロープアドレスで不正な構文のメッセージを拒否する必要があります（SHOULD）。
If the MSA examines or alters the message text in any way, except to add trace header fields, it SHOULD reject messages with illegal address syntax in address header fields.
MSAがトレースヘッダーフィールドを追加する以外の方法でメッセージテキストを検査または変更する場合、アドレスヘッダーフィールドに不正なアドレス構文を持つメッセージを拒否する必要があります（SHOULD）。
Reply code 501 is to be used to reject a MAIL or RCPT command that contains a detectably improper address.
応答コード501は、検出可能な不適切なアドレスを含むMAILまたは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 SHOULDは、メッセージエラー、特にクライアントソフトウェアの明らかな設定ミスをログに記録する必要があります（SHOULD）。
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 timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are designed to deal with the many types of situations that can be encountered on the public Internet. The relationship among clients and servers corresponding to this specification is typically much closer and more predictable. Submission clients behave differently from relay client in some areas, especially tolerance for timeouts. In practice, message submission clients tend to have short timeouts (perhaps 2-5 minutes for a reply to any command). Submission servers SHOULD respond to any command (even DATA) in fewer than 2 minutes.
RFC 5321 [SMTP-MTA]のセクション4.5.3.2で指定されているタイムアウトは、公衆インターネットで発生する可能性があるさまざまな状況に対処するように設計されています。この仕様に対応するクライアントとサーバー間の関係は、通常、より密接で予測可能です。送信クライアントは、一部の領域、特にタイムアウトの許容度において、リレークライアントとは異なる動作をします。実際には、メッセージ送信クライアントのタイムアウトは短い傾向があります（コマンドへの応答には、おそらく2〜5分です）。送信サーバーは、2分未満でコマンド（DATAを含む）に応答する必要があります（SHOULD）。
When the submission server has a close administrative and/or network relationship with the submission client(s) -- e.g., with a webmail interface calling on a tightly bound submission server -- mutual agreement on much shorter timeouts MAY be appropriate.
送信サーバーが送信クライアントと管理上またはネットワーク上で密接な関係を持っている場合（たとえば、緊密にバインドされた送信サーバーを呼び出すWebメールインターフェースを使用している場合）タイムアウトの大幅な短縮に関する相互の合意が適切な場合があります。
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).
MSAは、MAIL FROMのアドレスに送信権限が不十分であるか、使用されている認証で認証されていない場合（セッションが認証されている場合）、MAILコマンドにエラー応答を発行する場合があります。
Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.
この目的には、[SMTP-CODES]ごとの適切な拡張ステータスコード（5.7.1など）を含む応答コード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コマンドにエラー応答を発行する場合があります（MAY）。
Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.
この目的には、[SMTP-CODES]ごとの適切な拡張ステータスコード（5.7.1など）を含む応答コード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, 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]ごとに適切な拡張ステータスコードを含む応答コード550（5.7.1など）を使用して、送信ユーザーに基づいて拒否します。メッセージがサイトポリシーに違反している場合は、適切な拡張ステータスコード（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]の「ポストマスター」要件への適合を促進するために、MSAは、「ポストマスター」（またはその代替スペルフォームの1つ、
[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]）。1つ以上のドメインで、他のアドレスに適用される要件と比較して。他の利点の中でも特に、これは、許可されたユーザーがメールの送信を妨げる問題を報告するために使用できる最後の手段のアドレスを提供します。
Subject to limits imposed by other protocols and specifications, the MSA MAY convert among character sets or string encodings to improve message usefulness, likelihood of delivery, or conformance with other specifications or recommendations. Such conversions MAY include, when necessary, replacement of addresses whose encoding does not conform to RFC 5321 with ones that do, using information available out of band.
MSAは、他のプロトコルや仕様によって課せられる制限に従い、文字セットまたは文字列エンコーディング間で変換して、メッセージの有用性、配信の可能性、または他の仕様や推奨事項への適合性を向上させることができます。そのような変換は、必要に応じて、帯域外で利用可能な情報を使用して、エンコーディングがRFC 5321に準拠していないアドレスの置換を含む場合があります。
The following table lists Standards Track and Experimental SMTP extensions whose documents do not explicitly specify their applicability to this protocol. 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 |Sub- | Reference |
| | |mission | |
+--------------------+----------------------+--------+-----------------+
|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 |SHOULD |[DSN] |
| | Notification | | |
|SIZE |Message size |MAY |[SIZE] |
| ... |521 reply code |MUST NOT|[REPLY-521] |
|CHECKPOINT |Checkpoint/Restart |MAY |[CHECKPOINT] |
|BINARYMIME |Binary MIME |MAY |[CHUNKING] |
|CHUNKING |Chunking |MAY |[CHUNKING] |
|8BITMIME |Use 8-bit data |SHOULD |[RFC6152] |
|AUTH |Authentication |MUST |[SMTP-AUTH] |
|STARTTLS |Start TLS |MAY |[START-TLS] |
|NO-SOLICITING |Notification of |MAY |[RFC3865] |
| | no soliciting | | |
|MTRK |Message Tracking |MAY |[MSG-TRACK] |
|ATRN |On-Demand Relay |MUST NOT|[RFC2645] |
|DELIVERBY |Deliver By |MAY |[RFC2852] |
|CONPERM |Content Conversion |MAY |[RFC4141] |
| | Permission | | |
|CONNEG |Content Conversion |MAY |[RFC4141] |
| | Negotiation | | |
+--------------------+----------------------+--------+-----------------+
Table 1
Future SMTP extensions SHOULD explicitly specify if they are valid on the Submission port.
今後のSMTP拡張機能は、送信ポートで有効かどうかを明示的に指定する必要があります（SHOULD）。
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]に従ってサポートおよび使用する必要があります（SHOULD）。これにより、MSAは特定の構成やその他の問題について、このメモにリストされている応答コードよりも詳細にクライアントに通知できます。一部の拒否はサイトのセキュリティポリシーに関連しているため、認証されていない送信者に必要以上の詳細を公開しないように注意する必要があります。
[PIPELINING] SHOULD be supported by the MSA.
[パイプライン] 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が権限を検証し、送信ユーザーのIDを決定できるようにし、MSAによってサポートされる必要があります。
[START-TLS] is the most widely used mechanism, at the time this document was written, that allows the MUA and MSA to protect message submission integrity and privacy.
[START-TLS]は、このドキュメントが作成された時点で最も広く使用されているメカニズムであり、MUAと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コマンドなど、DATAの代替も参照します。
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.
注：メッセージの変更を実装するためのローカル決定のガイダンスの問題として、最も重要なルールは、明確な解決策がある特定の問題の解決策にそのようなアクションを制限することです。これは、特に住所要素に当てはまります。たとえば、ドメインを無差別にアドレスまたは要素に無差別に追加すると、通常はアドレスが壊れます。非修飾アドレスは、ドメインを安全に追加する前に、ドメイン内の有効なローカルパーツであることを確認する必要があります。
Any message forwarded or delivered by the MSA MUST conform to the requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements permitted by extensions that are supported by the MSA and accepted by the next-hop server.
MSAによって転送または配信されるメッセージは、[SMTP-MTA]および[MESSAGE-FORMAT]の要件、またはMSAによってサポートされ、ネクストホップサーバーによって受け入れられる拡張機能によって許可される要件に準拠する必要があります。
Message modification can affect the validity of an existing message signature, such as by DomainKeys Identified Mail (DKIM) [DKIM], Pretty Good Privacy (PGP) [RFC4880], or Secure MIME (S/MIME) [RFC5751], and can render the signature invalid. This, in turn, can affect message handling by later receivers, such as filtering engines that consider the presence or absence of a valid signature.
メッセージの変更は、DomainKeys Identified Mail（DKIM）[DKIM]、Pretty Good Privacy（PGP）[RFC4880]、Secure MIME（S / MIME）[RFC5751]などによる既存のメッセージ署名の有効性に影響を与え、レンダリングできる署名が無効です。これは、有効な署名の有無を考慮するフィルタリングエンジンなど、後の受信者によるメッセージ処理に影響を与える可能性があります。
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.
送信者のIDがわかっていて、これが「From」フィールドに指定されていない場合、MSAは「Sender」フィールドを追加または置換できます。
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は、「Message-ID」フィールドがないか、有効な構文（[MESSAGE-FORMAT]で定義されている）でない場合、追加または置換する必要があります（SHOULD）。多くのクライアントはまだ「メッセージID」フィールドを生成しないことに注意してください。
The MSA MAY apply transfer encoding to the message according to MIME conventions, if needed and not harmful to the MIME type.
MSAは、必要に応じてMIMEタイプに害を及ぼさない場合、MIME規則に従ってメッセージに転送エンコーディングを適用できます（MAY）。
The MSA MAY (digitally) sign or otherwise add authentication information to the message.
MSAは（デジタルで）署名するか、メッセージに認証情報を追加する場合があります。
The MSA MAY encrypt the message for transport to reflect organizational policies.
MSAは、組織のポリシーを反映するために、転送用にメッセージを暗号化できます（MAY）。
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 and rewrite aliases (e.g., Canonical Name (CNAME) records) for domain names, in the SMTP envelope and/or in address fields of the header, subject to local policy.
MSAは、ローカルポリシーに従い、SMTPエンベロープ内および/またはヘッダーのアドレスフィールド内のドメイン名のエイリアス（Canonical Name（CNAME）レコードなど）を解決して書き換えることができます（MAY）。
NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in addresses and the session-opening announcement. As with other SMTP requirements, RFC 5321 effectively prohibits an MSA from forwarding such messages into the public Internet. Nonetheless, 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.
注：SMTP [SMTP-MTA]は、アドレスおよびセッション開始アナウンスでのドメイン名エイリアスの使用を禁止します。他のSMTP要件と同様に、RFC 5321は、MSAがそのようなメッセージを公衆インターネットに転送することを事実上禁止しています。それにもかかわらず、無条件にエイリアスを解決すると有害になる可能性があります。たとえば、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）。たとえば、サイトでは、ログイン名を非表示にしたり、「squeaky.sales.example.net」を「zyx.example.net」に書き換えたりして、「JRU」を「J.Random.User」に書き換えることを好むかもしれません。マシン名を使用して、ユーザーの移動を容易にします。
However, only addresses, local-parts, or domains that 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 leftmost 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. Changes to addressing and encoding, carried out in conjunction with the action of Section 6.5, do not violate this principle if the MSA has sufficient information available to successfully and accurately apply the substitution.
MSAは、ローカルパーツの変更に関する[SMTP-MTA]の制約に違反する方法で、フォワードポインティング（宛先）アドレスを書き換えてはなりません（MUST NOT）。セクション6.5のアクションに関連して実行されるアドレッシングとエンコードの変更は、MSAが置換を正常かつ正確に適用するために利用できる十分な情報を持っている場合、この原則に違反しません。
Separation of submission and relay of messages allows a site to implement different policies for the two types of services, including requiring the use of additional security mechanisms for one or both. It can do this in a way that 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 entries in Table 1 have been corrected (reference for NO-SOLICITING) and extended (ATRN, DELIVERBY, CONPERM, and CONNEG). The "SMTP Service Extensions" registry has been updated to reflect the changed and new entries. Entries in the registry that do not appear in the table above are correct and should not be altered.
表1のエントリは修正され（NO-SOLICITINGのリファレンス）、拡張されました（ATRN、DELIVERBY、CONPERM、およびCONNEG）。 「SMTP Service Extensions」レジストリが更新され、変更されたエントリと新しいエントリが反映されました。上記の表に記載されていないレジストリのエントリは正しいため、変更しないでください。
The entry in the "SMTP Service Extensions" registry for RFC 4409 has been updated to reference this document. The original reference for Submit (RFC 2476), which should have been corrected earlier, has also been updated to point to this document.
RFC 4409の「SMTPサービス拡張」レジストリのエントリは、このドキュメントを参照するように更新されました。以前に修正されていた送信（RFC 2476）の元の参照も、このドキュメントを指すように更新されました。
The entry in the "Service Name and Transport Protocol Port Number Registry" for port 587 has been updated to point to this document.
ポート587の「サービス名とトランスポートプロトコルのポート番号レジストリ」のエントリは、このドキュメントを指すように更新されました。
The preparation and development of the current version of this specification was stimulated by discussions in the IETF YAM and EAI Working Groups. Dave Crocker, Subramanian Moonesamy, Barry Leiba, John Levine, and others provided text that appeared in this document or versions leading up to it.
この仕様の現在のバージョンの準備と開発は、IETF YAMおよびEAIワーキンググループでの議論に刺激されました。 Dave Crocker、Subramanian Moonesamy、Barry Leiba、John Levineなどが、このドキュメントに登場するテキスト、またはそれ以前のバージョンを提供しました。
Nathaniel Borenstein and Barry Leiba were instrumental in the development of RFC 4409, the update to RFC 2476.
ナサニエルボレンシュタインとバリーレイバは、RFC 2476の更新であるRFC 4409の開発に尽力しました。
The original memo (RFC 2476) was developed, in part, based on comments and discussions that 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-Submitメーリングリストの内外で行われたコメントと議論に一部基づいて作成されました。時間をかけてそのドキュメントをレビューし、提案を行った人々、特にデイブクロッカー、ネッドフリード、キースムーア、ジョンマイヤーズ、およびクリスニューマンに感謝します。
Special thanks to Harald Alvestrand, who got this effort started.
この取り組みを始めてくれたHarald Alvestrand氏に特に感謝します。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[SMTP-AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[SMTP-AUTH] Siemborski、R。およびA. Melnikov、「認証用のSMTPサービス拡張」、RFC 4954、2007年7月。
[SMTP-MTA] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP-MTA] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[CHECKPOINT] Crocker, D. and N. Freed, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.
[チェックポイント]クロッカーD.およびN.フリード、「チェックポイント/再起動用のSMTPサービス拡張」、RFC 1845、1995年9月。
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[CHUNKING] Vaudreuil、G。、「SMTP Service Extensions for Transmission of Large and Binary MIME Messages」、RFC 3030、2000年12月。
[CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[CODES-EXTENSION] Freed、N。、「拡張エラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DKIM] Crocker、D.、Hansen、T。、およびM. Kucherawy、「DomainKeys Identified Mail（DKIM）Signatures」、RFC 6376、2011年9月。
[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status Notifications（DSNs）」、RFC 3461、2003年1月。
[ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.
[ETRN] De Winter、J。、「リモートメッセージキュー開始用のSMTPサービス拡張」、RFC 1985、1996年8月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、2003年3月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[MESSAGE-FORMAT] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[MESSAGE-FORMAT] Resnick、P。、編、「インターネットメッセージフォーマット」、RFC 5322、2008年10月。
[MSG-TRACK] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.
[MSG-TRACK] Allman、E.、T。Hansen、「SMTP Service Extension for Message Tracking」、RFC 3885、2004年9月。
[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[PIPELINING] Freed、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.ローズ、「Post Office Protocol-Version 3」、STD 53、RFC 1939、1996年5月。
[REPLY-521] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995.
[REPLY-521] Durand、A。およびF. Dupont、「SMTP 521 Reply Code」、RFC 1846、1995年9月。
[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999.
[RFC2645] Gellens、R。、「動的IPアドレスを使用したオンデマンドメールリレー（ODMR）SMTP」、RFC 2645、1999年8月。
[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[RFC2852]ニューマン、D。、「SMTPサービス拡張による配信」、RFC 2852、2000年6月。
[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004.
[RFC3865] Malamud、C。、「No Soliciting Simple Mail Transfer Protocol（SMTP）Service Extension」、RFC 3865、2004年9月。
[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion", RFC 4141, November 2005.
[RFC4141] Toyoda、K. and D. Crocker、 "SMTP and MIME Extensions for Content Conversion"、RFC 4141、2005年11月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、2007年11月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.
[RFC6152] Klensin、J.、Freed、N.、Rose、M。、およびD. Crocker、「8ビットMIMEトランスポート用のSMTPサービス拡張」、STD 71、RFC 6152、2011年3月。
[SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
[サイズ] Klensin、J.、Freed、N。、およびK. Moore、「メッセージサイズ宣言のためのSMTPサービス拡張」、STD 10、RFC 1870、1995年11月。
[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[SMTP-CODES] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
[START-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[START-TLS]ホフマン、P。、「トランスポート層セキュリティを介したセキュアなSMTPのためのSMTPサービス拡張」、RFC 3207、2002年2月。
The protocol specified by this document is not substantively different from that of RFC 4409. However, the present specification contains several clarifications and updates to reflect changes and revisions to other documents subsequent to the publication of RFC 4409. The following specific changes may be of interest to some readers.
このドキュメントで指定されているプロトコルは、RFC 4409のプロトコルと実質的に違いはありません。ただし、本仕様には、RFC 4409の公開に続く他のドキュメントの変更や改訂を反映するために、いくつかの明確化と更新が含まれています。次の特定の変更が興味深いかもしれません一部の読者に。
o Updated several references to reflect more recent versions of the various specifications. As part of this, reclassified RFC 4954 to a normative reference (SMTP AUTH is a MUST for RFC 4409 and this specification).
o さまざまな仕様のより新しいバージョンを反映するために、いくつかの参照を更新しました。この一環として、RFC 4954を規範的な参照に再分類しました（SMTP AUTHはRFC 4409とこの仕様の必須項目です）。
o Updated the text in Section 7 to reflect the existence and partial population of the registry and the included table (Table 1) to correct one entry and add others. See Section 10 for more information.
o レジストリの存在と部分的な人口を反映するためにセクション7のテキストを更新し、1つのエントリを修正して他のエントリを追加するために含まれるテーブル（表1）を反映しました。詳細については、セクション10を参照してください。
o Added new text (Section 5.3) to clarify that Submission Servers should respond quickly.
o Submission Serverが迅速に応答する必要があることを明確にするために、新しいテキスト（セクション5.3）を追加しました。
o Added text to make it explicit that character encoding changes are permitted.
o 文字エンコーディングの変更が許可されていることを明示するためにテキストを追加しました。
o Added text to make it clear that modifications to signed messages may cause problems and that they should be carefully considered.
o 署名付きメッセージに変更を加えると問題が発生する可能性があり、慎重に検討する必要があることを明確にするためにテキストを追加しました。
Authors' Addresses
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-2779 USA
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego、CA 92121-2779 USA
EMail: rg+ietf@qualcomm.com
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
John C Klensin 1770 Massachusetts Ave、＃322 Cambridge、MA 02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com