[要約] RFC 4409は、メールの送信を効率化するためのプロトコルであり、要約すると、メッセージの送信方法と手順を定義しています。目的は、メールの送信プロセスをスムーズにし、エラーの可能性を減らすことです。
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).
Copyright（c）The Internet Society（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].
メッセージ転送エージェント（MTA）は、[smtp-mta]で必要とされる「受信」、「return-path」、およびその他のヘッダーフィールドを追加することを除いて、メッセージテキストを変更することは想定されていません。
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はメッセージ *送信 *プロトコルとしても広く使用されています。つまり、メッセージユーザーエージェント（MUAS）がMTAルーティングネットワークに新しいメッセージを導入する手段としても広く使用されています。MUASからのメッセージ送信を受け入れるプロセスは、メッセージ提出エージェント（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つ以上の側面で未完成（不完全）です。未完成のメッセージは、[メッセージフォーマット]およびその後の要件に適合するように完了する必要がある場合があります。たとえば、メッセージには適切な「日付」ヘッダーフィールドがない場合があり、ドメインは完全に適格でない場合があります。場合によっては、MUAが完成したメッセージを生成できない場合があります（たとえば、タイムゾーンがわからない場合があります）。送信されたメッセージが完了した場合でも、ローカルサイトのポリシーは、メッセージテキストを何らかの方法で検査または変更することを決定する場合があります。このような完了または修正は、下流のMTA、つまりFirst Hop Submission 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は、MUASからのメッセージを受け入れる提出サーバーとして機能し、それらを配信するか、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サーバーとして機能し、それらを配信するか、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 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.
例「embles.net」ドメインを使用します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [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, 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.
ほとんどの電子メールクライアントとサーバーは、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 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コマンドを拒否するようにMTAを構成し、認証されたアイデンティティまたは送信に基づいて認可されたユーザーから生じるすべてのメッセージ送信を拒否するように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が修正できる問題、たとえば「フィールドからの無効な問題」に特に当てはまります。
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が送信ユーザーへのリターンパスを決定できない場合、有効なメール、有効なソースIPアドレス、または認証されたIDに基づいて、MSAはすぐにメッセージを拒否する必要があります。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.)
nullリターンパス、つまりメール、<>は許可されており、それ自体がメッセージを拒否する原因であってはなりません。（MUASは、気質通知を含むさまざまな理由で、Null Return-Pathメッセージを生成する必要があります。）
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およびその他のトンネル、および以前のポップ認証が含まれます。
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は、他のプロトコルに関連付けられていないメッセージの送信の認証IDを決定できます。
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提出セッションの前にポップ認証を行う必要があり、すべてのクライアントがこのために能力と構成されているわけではありません。また、MSAはポップサーバーと調整する必要がありますが、これは困難な場合があります。また、許可されていないユーザーがメッセージを送信し、以前に認可されたユーザーのように見えるウィンドウもあります。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は、不適切なものを含むメール、RCPT、またはデータコマンドを拒否するために使用されます。
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がTRACEヘッダーフィールド[SMTP-MTA]を追加することを除いて、メッセージテキストを何らかの方法で調べたり変更したりする場合、アドレスヘッダーフィールドのすべてのドメインが完全に適格であることを確認する必要があります。
Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command that contains improper domain references.
返信コード554は、不適切なドメイン参照を含むメール、RCPT、またはデータコマンドを拒否するために使用されます。
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 '）。シングルレベルのドメインを許可するローカル規則は、そのような拡張が特に危険であるため、不完全なマルチレベルドメイン（例：「Scheaky.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は、[SMTP-Auth]を使用してセッションが認証されていない場合、[保護されたサブネットワーク内など）を既に確立していない限り、[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がTrace Headerフィールドを追加することを除いてメッセージテキストを調べたり変更したりする場合、アドレスヘッダーフィールドに違法アドレス構文を使用してメッセージを拒否する必要があります。
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.
メッセージ本文の提出後にアドレスが解決されると、メッセージにヘッダーに無効なアドレスが含まれている場合、dataの終了後に応答コード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).
MSAは、メールのアドレスが提出権が不十分であると思われる場合、または使用された認証で許可されていない場合（セッションが認証されている場合）、メールコマンドにエラー応答を発行する場合があります。
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などの適切な強化されたステータスコードを使用したReply Code 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などの適切な強化されたステータスコードを使用したReply Code 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は、提出されたメッセージが構文的に無効である場合、またはユーザーに与えられた権限（既知の場合）と矛盾しているように見える場合、または一部の人々のサイトポリシーに違反している場合、データコマンドにエラー応答を発行したり、データの終了後に障害結果を送信したりする場合があります。道。
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など）を使用したReply Code 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は「ポストマスター」（またはその代替スペルフォームの1つを扱うメールの認証の程度が減少する可能性があります。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コード]は、[コード拡張]に従ってサポートおよび使用する必要があります。これにより、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は権限を検証し、提出ユーザーの身元を決定し、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].
このメモのデータコマンドへの参照は、[チャンキング]で使用される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.
注：メッセージの変更を実装するためのローカル決定のガイダンスの問題として、最も重要なルールは、明確な解決策を持つ特定の問題の救済にそのようなアクションを制限することです。これは、アドレス要素に特に当てはまります。たとえば、ドメインをアドレスまたは要素に不足させる要素に、通常、より壊れたアドレスをもたらすというドメインを無差別に追加します。ドメインを安全に追加する前に、ドメイン内の有効なローカル部分であることを確認していないアドレスを確認する必要があります。
Any message forwarded or delivered by the MSA MUST conform to the requirements of [SMTP-MTA] and [MESSAGE-FORMAT].
MSAによって転送または配信されたメッセージは、[SMTP-MTA]および[メッセージフォーマット]の要件に準拠する必要があります。
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.
MSAは、送信者の身元が既知であり、これが「From」フィールドに与えられていない場合、「送信者」フィールドを追加または交換する場合があります。
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は、提出されたメッセージに「日付」フィールドを不足している場合は、[メッセージフォーマット]構文に準拠していない場合は「日付」フィールドを修正する場合があります。
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」フィールドが不足している場合、または有効な構文（[メッセージフォーマット]で定義されている）を追加または交換する必要があります。多くのクライアントがまだメッセージ-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タイプに有害ではないMIME規則に従ってメッセージに転送エンコードを適用する場合があります。
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は、組織のポリシーを反映するために輸送のメッセージを暗号化する場合があります。
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エンベロープ、およびオプションでヘッダーのアドレスフィールドでローカルパーツおよび/またはドメインを書き換えることができます。たとえば、サイトはログイン名を非表示にするために「J.Random.user」として「Jru」を書き換えたり、「shales.sales.example.net 'が' zyx.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.
Nathaniel BorensteinとBarry Leibaは、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-Submitメーリングリストで行われたコメントと議論に基づいて部分的に開発されました。その文書をレビューして提案するのに時間をかけた人々の助け、特にデイブ・クロッカー、ネッド・フリード、キース・ムーア、ジョン・マイヤーズ、クリス・ニューマンの助けが高く評価されています。
Special thanks to Harald Alvestrand, who got this effort started.
この努力を始めたHarald 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.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「SMTP Service Extensions」、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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP-MTA] Postel、J。、「Simple Mail Transfer Protocol」、Std 10、RFC 821、1982年8月。
Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, January 1986.
Partridge、C。、「メールルーティングとドメインシステム」、STD 10、RFC 974、1986年1月。
Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995.
[521Reply] Durand、A。and F. Dupont、「SMTP 521 Reply Code」、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.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[CHECKPOINT] Crocker, D., Freed, N., and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.
[チェックポイント] Crocker、D.、Freed、N。、およびA. Cargille、「チェックポイント/再起動の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。、「大型およびバイナリMIMEメッセージの送信用SMTPサービス拡張」、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月。
[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN] Moore、K。、「配送ステータス通知（DSNS）のSimple Mail Transfer Protocol（SMTP）サービス拡張」、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 R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
Resnick, P., "Internet Message Format", RFC 2822, April 2001.
Resnick、P。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[Msg-Track] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.
[MSG-Track] Allman、E。およびT. Hansen、「メッセージ追跡のためのSMTPサービスエクステンション」、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] Myers、J。and M. Rose、「郵便局プロトコル - バージョン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.
[サイズ] Klensin、J.、Freed、N。、およびK. Moore、「メッセージサイズ宣言のSMTPサービス拡張」、STD 10、RFC 1870、1995年11月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-Auth] Myers、J。、「認証のためのSMTPサービス拡張」、RFC 2554、1999年3月。
[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] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
Authors' Addresses
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-2779 USA
ランドール・ゲレンズ・クアルコム・インコーポレーテッド5775モアハウス・ドライブサンディエゴ、カリフォルニア92121-2779 USA
EMail: rg+ietf@qualcomm.com
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンC.クレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
EMail: john+ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。