[要約] RFC 2476は、電子メールのメッセージ送信プロトコルであり、メッセージの送信方法と要件を定義しています。その目的は、電子メールの信頼性とセキュリティを向上させ、メッセージの効率的な送信を可能にすることです。
Network Working Group R. Gellens
Request for Comments: 2476 QUALCOMM
Category: Standards Track J. Klensin
MCI
December 1998
Message Submission
メッセージの提出
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Table of Contents
目次
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Information . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions of Terms Used in this Memo . . . . . . . . . 3
2.2. Conventions Used in this Document . . . . . . . . . . . 4
3. Message Submission . . . . . . . . . . . . . . . . . . . . . 4
3.1. Submission Identification . . . . . . . . . . . . . . . 4
3.2. Message Rejection and Bouncing . . . . . . . . . . . . . 4
3.3. Authorized Submission . . . . . . . . . . . . . . . . . 5
3.4. Enhanced Status Codes . . . . . . . . . . . . . . . . . 6
4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Submission Rejection Code . . . . . . . . . . . 6
4.2. Ensure All Domains are Fully-Qualified . . . . . . . . 6
5. Recommended Actions . . . . . . . . . . . . . . . . . . . . 7
5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . 7
5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 7
6. Optional Actions . . . . . . . . . . . . . . . . . . . . . 7
6.1. Enforce Submission Rights . . . . . . . . . . . . . . . 7
6.2. Require Authentication . . . . . . . . . . . . . . . . 8
6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . 8
6.4. Check Message Data . . . . . . . . . . . . . . . . . . 8
7. Interaction with SMTP Extensions . . . . . . . . . . . . . . 8
8. Message Modifications . . . . . . . . . . . . . . . . . . . 9
8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . 10
8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10
8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . 10
8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . 10
8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . 10
8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . 10
8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
13. Full Copyright Statement . . . . . . . . . . . . . . . . . 15
SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. 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）は、[SMTP-MTA]で必要とされる「Received」、「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 which accepts message submissions from MUAs is termed a Message Submission Agent (MSA).
ただし、SMTPは現在、メッセージ*送信*プロトコルとして広く使用されています。つまり、メッセージユーザーエージェント（MUA）がMTAルーティングネットワークに新しいメッセージを導入する手段です。 MUAからのメッセージ送信を受け入れるプロセスは、メッセージ送信エージェント（MSA）と呼ばれます。
Messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in some aspect or other. Unfinished messages 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 (for example, 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. 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.
送信されるメッセージは、場合によっては完了した（完全な）メッセージであり、他の場合には、いくつかの点で未完了（不完全な）メッセージです。未完成のメッセージは、[MESSAGE-FORMAT]およびそれ以降の要件に確実に準拠するように完了する必要があります。たとえば、メッセージに適切な「日付」ヘッダーフィールドがなく、ドメインが完全に修飾されていない場合があります。場合によっては、MUAが完成したメッセージを生成できないことがあります（たとえば、タイムゾーンがわからない場合があります）。送信されたメッセージが完了した場合でも、ローカルサイトのポリシーにより、メッセージテキストを調べたり、何らかの方法で変更したりする必要がある場合があります。そのような完了または変更は、ダウンストリームMTA（つまり、最初のホップのサブミッションMTA後のMTA）によって実行されると害を及ぼすことが示され、一般に、標準化されたMTA機能の範囲外であると見なされます。
Separating messages into submissions and transfers allows developers and network administrators to more easily:
メッセージを送信と転送に分離することで、開発者とネットワーク管理者は次のことがより簡単になります。
* 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.
このメモは、メッセージが送信として識別されるための低コストで決定論的な手段を説明し、送信サーバーが実行するアクションを指定します。
Public comments should be sent to the IETF Submit mailing list, <ietf-submit@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-submit-request@imc.org>. Private comments may be sent to the authors.
パブリックコメントは、IETF送信メーリングリスト<ietf-submit@imc.org>に送信する必要があります。購読するには、SUBSCRIBEを含むメッセージを<ietf-submit-request@imc.org>に送信してください。著者にプライベートコメントを送ることができます。
Fully-Qualified
完全修飾
Containing or consisting of a domain which can be globally resolved using the global Domain Name Service; that is, not a local alias or partial specification.
グローバルドメインネームサービスを使用してグローバルに解決できるドメインを含む、または構成すること。つまり、ローカルエイリアスや部分指定ではありません。
Message Submission Agent (MSA)
メッセージ発信エージェント（MSA）
A process which conforms to this specification, which 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.
この仕様に準拠するプロセス。MUAからのメッセージを受け入れる送信サーバーとして機能し、メッセージを配信するか、またはSMTPクライアントとして機能してMTAにメッセージを中継します。
Message Transfer Agent (MTA)
メッセージ転送エージェント（MTA）
A process which conforms to [SMTP-MTA], which 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]に準拠するプロセス。これは、MSAまたは別のMTAからのメッセージを受け入れるSMTPサーバーとして機能し、メッセージを配信するか、SMTPクライアントとして機能して、別のMTAにメッセージを中継します。
Message User Agent (MUA)
メッセージユーザーエージェント（MUA）
A process which acts (usually on behalf of a user) to compose and submit new messages, and process delivered messages. In the split-MUA model, POP or IMAP is used to access delivered messages.
（通常はユーザーに代わって）新しいメッセージを作成して送信し、配信されたメッセージを処理するプロセス。分割MUAモデルでは、配信されたメッセージへのアクセスにPOPまたはIMAPが使用されます。
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].
このドキュメントのキーワード「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, ESMTP], with additional restrictions as specified here.
このドキュメントで指定されているとおり、ポート587は電子メールメッセージの送信用に予約されています。このポートで受信されたメッセージは発信と定義されています。使用されるプロトコルはESMTP [SMTP-MTA、ESMTP]ですが、ここで指定されている追加の制限があります。
While 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 MTA to reject all RCPT TOs for messages that do not reference local users, and configure their MSA to reject all message submissions that do not come from authorized users, based on IP address, or authenticated identity.
たとえば、一部のサイトでは、ローカルユーザーを参照しないメッセージのすべてのRCPT TOを拒否するようにMTAを構成し、IPアドレスまたは認証済みIDに基づいて、承認されたユーザーからのものではないすべてのメッセージ送信を拒否するようにMSAを構成する場合があります。
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 FROM command.
MSAが有効なMAIL FROM、有効な送信元IPアドレスから、または認証されたIDに基づいて、送信ユーザーへのリターンパスを決定できない場合、MSAは直ちにメッセージを拒否する必要があります（SHOULD）。 550コードをMAIL FROMコマンドに返すことにより、メッセージをすぐに拒否できます。
Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST be accepted. (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 which 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 must maintain a queue of messages it has submitted, and match bounces to them.
注：通常のメッセージ送信の場合、ユーザーと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 prior POP authentication.
承認されたユーザーのみがメッセージを送信できるようにするために、多くの方法が使用されてきました。これらの方法には、認証済みSMTP、IPアドレス制限、セキュアIP、および以前のPOP認証が含まれます。
Authenticated SMTP [SMTP-AUTH] has been proposed. It allows the MSA to determine an authorization identity for the message submission, which is not tied to other protocols.
認証されたSMTP [SMTP-AUTH]が提案されました。これにより、MSAは他のプロトコルに関連付けられていないメッセージ送信の承認IDを決定できます。
IP address restrictions are very widely implemented, but do not allow for travellers and similar situations, and can be spoofed.
IPアドレスの制限は非常に広く実装されていますが、旅行者や同様の状況には対応しておらず、なりすまされる可能性があります。
Secure IP [IPSEC] can also be used, and provides 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 (for example, 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 prior authorized user.
メッセージ送信セッションの開始前の一定の時間内（たとえば、20分）にPOP [POP3]認証（同じIPアドレスから）を要求することも使用されていますが、これはクライアントにも制限を課します。問題を引き起こす可能性のあるサーバー。具体的には、クライアントはSMTP送信セッションの前にPOP認証を行う必要があり、すべてのクライアントがこれに対応して構成されているわけではありません。また、MSAはPOPサーバーと調整する必要があるため、難しい場合があります。許可されていないユーザーがメッセージを送信し、以前に許可されたユーザーのように見えるウィンドウもあります。
This memo suggests several enhanced status codes [SMTP-CODES] for submission-specific rejections. The specific codes used are:
このメモは、提出に固有の拒否のためのいくつかの拡張ステータスコード[SMTP-CODES]を提案しています。使用される特定のコードは次のとおりです。
5.6.0 Bad content. The content of the header or text is improper.
5.6.0 悪い内容。ヘッダーまたはテキストの内容が不適切です。
5.6.2 Bad domain or address. Invalid or improper domain or address in MAIL FROM, RCPT TO, or DATA.
5.6.2 不正なドメインまたはアドレス。 MAIL FROM、RCPT TO、またはDATA内の無効または不適切なドメインまたはアドレス。
5.7.1 Not allowed. The address in MAIL FROM appears to have insufficient submission rights, or is invalid, or is not authorized with the authentication used; the address in a RCPT TO command is inconsistent with the permissions given to the user; the message data is rejected based on the submitting user.
5.7.1 禁止されている。 MAIL FROMのアドレスは、送信権限が不十分であるか、無効であるか、使用されている認証で承認されていません。 RCPT TOコマンドのアドレスが、ユーザーに与えられた許可と矛盾しています。メッセージデータは送信ユーザーに基づいて拒否されます。
5.7.0 Site policy. The message appears to violate site policy in some way.
5.7.0 サイトポリシー。メッセージは何らかの形でサイトのポリシーに違反しているようです。
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 FROM, RCPT TO, or DATA command that contains something improper. Enhanced status code 5.6.0 is to be used if no other code is more specific.
より正確な応答コードでカバーされていない限り、応答コード554は、不適切な何かを含むMAIL FROM、RCPT TO、またはDATAコマンドを拒否するために使用されます。他に特定のコードがない場合は、拡張ステータスコード5.6.0を使用します。
The MSA MUST ensure that all domains in the envelope are fully-qualified.
MSAは、エンベロープ内のすべてのドメインが完全に修飾されていることを確認する必要があります。
If the MSA examines or alters the message text in 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 FROM, RCPT TO, or DATA command which contains improper domain references.
応答コード554は、不適切なドメイン参照を含むMAIL FROM、RCPT TO、またはDATAコマンドを拒否するために使用されます。
NOTE: A frequent local convention is to accept single-level domains (for example, 'sales') and then to expand the reference by adding the remaining portion of the domain name (for example, to
注：よくあるローカル規約は、単一レベルのドメイン（たとえば、「販売」）を受け入れ、次にドメイン名の残りの部分（たとえば、
'sales.example.net'). Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains, since such expansion is particularly risky.
'sales.example.net'）。シングルレベルドメインを許可するローカル規約では、不完全なマルチレベルドメインを拡張するのではなく、拒否する必要があります。そのような拡張は特にリスクが高いためです。
The MSA SHOULD do all of the following:
MSAは次のすべてを行う必要があります。
An MSA SHOULD reject messages with illegal syntax in a sender or recipient envelope address.
MSAは、送信者または受信者のエンベロープアドレスに不正な構文を持つメッセージを拒否する必要があります（SHOULD）。
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がトレースヘッダーフィールドを追加する以外の方法でメッセージテキストを検査または変更する場合は、アドレスヘッダーフィールドに不正なアドレス構文を持つメッセージを拒否する必要があります（SHOULD）。
Reply code 501 is to be used to reject a MAIL FROM or RCPT TO command that contains a detectably improper address.
応答コード501は、検出不可能なアドレスを含むMAIL FROMまたはRCPT TOコマンドを拒否するために使用されます。
When addresses are resolved after submission of the message body, reply code 554 with enhanced status code 5.6.2 is to be used after end-of-data, if the message contains invalid addresses in the header.
メッセージ本文の送信後にアドレスが解決されると、メッセージのヘッダーに無効なアドレスが含まれている場合、データの終わりの後に拡張ステータスコード5.6.2の応答コード554が使用されます。
The MSA SHOULD log message errors, especially apparent misconfigurations of client software.
MSA SHOULDは、メッセージエラー、特にクライアントソフトウェアの明らかな設定ミスをログに記録する必要があります（SHOULD）。
Note: 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つの利点です。システム管理者はローカル構成の問題に関心があるかもしれませんが、他のサイトのクライアントの問題には関心がないかもしれません。
The MSA MAY do any of the following:
MSAは次のいずれかを実行できます。
The MSA MAY issue an error response to the MAIL FROM 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 FROMコマンドにエラー応答を発行する場合があります。
Reply code 550 with enhanced status code 5.7.1 is used for this purpose.
拡張ステータスコード5.7.1の応答コード550がこの目的で使用されます。
The MSA MAY issue an error response to the MAIL FROM command if the session has not been authenticated.
セッションが認証されていない場合、MSAはMAIL FROMコマンドにエラー応答を発行する場合があります。
Section 3.3 discusses authentication mechanisms.
セクション3.3では、認証メカニズムについて説明します。
Reply code 530 [SMTP-AUTH] is used for this purpose.
この目的のために、応答コード530 [SMTP-AUTH]が使用されます。
The MSA MAY issue an error response to the RCPT TO command if inconsistent with the permissions given to the user (if the session has been authenticated).
MSAは、ユーザーに与えられた許可と矛盾する場合（セッションが認証されている場合）、RCPT TOコマンドにエラー応答を発行する場合があります（MAY）。
Reply code 550 with enhanced status code 5.7.1 is used for this purpose.
拡張ステータスコード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, 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 enhanced status code 5.7.1 is used to reject based on the submitting user. Reply code 550 with enhanced status code 5.7.0 is used if the message violates site policy.
応答コード554は、データの構文上の問題に使用されます。コマンド自体が構文的に有効でない場合は、応答コード501が使用されます。ステータスコード5.7.1が強化された返信コード550を使用して、送信したユーザーに基づいて拒否します。メッセージがサイトポリシーに違反している場合は、拡張ステータスコード5.7.0の応答コード550が使用されます。
The following table lists the current standards-track and Experimental SMTP extensions. Listed are the RFC, name, an indication as to the use of the extension on the submit port, and a reference:
次の表に、現在の標準化トラックと試験的なSMTP拡張機能を示します。リストされているのは、RFC、名前、送信ポートでの拡張機能の使用に関する指示、および参照です。
RFC Name Submission Reference
---- --------------- ---------- ------------------
2197 Pipelining SHOULD [PIPELINING]
2034 Error Codes SHOULD [CODES-EXTENSION]
1985 ETRN MUST NOT [ETRN]
1893 Extended Codes SHOULD [SMTP-CODES]
1891 DSN SHOULD [DSN]
1870 Size MAY [SIZE]
1846 521 MUST NOT [521REPLY]
1845 Checkpoint MAY [Checkpoint]
1830 Binary MAY [CHUNKING]
1652 8-bit MIME SHOULD [8BITMIME]
---- Authentication ------ [SMTP-AUTH]
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 than is needed to correct the problem.
拡張ステータスコード[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.
[SMTP-AUTH]により、MSAは権限を検証し、送信ユーザーのIDを決定できます。
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 which 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つ欠落すると、アドレスが壊れます。非修飾アドレスは、ドメインを安全に追加する前に、ドメイン内の有効なローカルパーツであることを確認する必要があります。
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 MAY add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]).
MSAは、「Message-ID」フィールドがないか、有効な構文（[MESSAGE-FORMAT]で定義されている）でない場合、追加または置換できます（MAY）。
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, e.g., 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 envelope and optionally in address fields of the header, subject to local policy.
MSAは、ローカルポリシーに従い、エンベロープ内およびオプションでヘッダーのアドレスフィールド内のドメイン名のエイリアス（CNAMEレコード）を解決できます（MAY）。
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 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 logon names, and/or to rewrite ' squeeky.sales.example.net' as 'zyx.example.net' to hide machine names and make it easier to move users.
MSAは、ローカルポリシーに従って、エンベロープ内およびオプションでヘッダーのアドレスフィールド内のローカルパーツやドメインを書き換えることができます（MAY）。たとえば、サイトでは、ログオン名を非表示にするために「JRU」を「J.Random.User」に書き換えたり、「squeeky.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 which strips the left-most element of the domain if the complete domain matches '*.foo.example.net' would be acceptable.
ただし、特定のローカルMSA構成設定に一致するアドレス、ローカルパーツ、またはドメインのみを変更する必要があります。 MSAがドメイン名の最初の要素を常に削除するなど、データに依存しない書き換えルールを適用することは非常に危険です。したがって、たとえば、完全なドメインが「* .foo.example.net」に一致する場合、ドメインの左端の要素を削除するルールは許容されます。
Separation of submission and relay of messages can allow 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つのタイプのサービスに異なるポリシーを実装できます。これには、1つまたは両方の追加のセキュリティメカニズムの使用が必要になることも含まれます。技術的にも管理的にも簡単な方法でこれを行うことができます。これにより、ポリシーが正しく適用される可能性が高くなります。
Separation also can aid in tracking and preventing unsolicited bulk email.
分離は、迷惑メールの追跡と防止にも役立ちます。
For example, a site could configure its MSA to require authentication before accepting a message, and could configure its MTA to reject all RCPT TOs for non-local users. This can be an important element in a site's total email security policy.
たとえば、サイトは、メッセージを受け入れる前に認証を要求するようにMSAを構成し、非ローカルユーザーのすべてのRCPT TOを拒否するようにMTAを構成できます。これは、サイト全体の電子メールセキュリティポリシーの重要な要素になる場合があります。
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を参照）、サイトはそのリソースと名前のオープンな使用を許可しています。迷惑メールは、その機能を使用して注入できます。
This updated memo has been revised 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 the draft and make suggestions is appreciated, especially that of Dave Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.
この更新されたメモは、IETF-Submitメーリングリスト内外で行われたコメントと議論に基づいて部分的に改訂されました。ドラフトをレビューして提案するために時間を割いた人たちの助け、特にデイブ・クロッカー、ネッド・フリード、キース・ムーア、ジョン・マイヤーズ、そしてクリス・ニューマンの助力は高く評価されています。
Special thanks to Harald Alvestrand, who got this effort started.
この取り組みを始めてくれたHarald Alvestrand氏に特に感謝します。
[521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995.
[521REPLY] Durand、A。および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月。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.
[チェックポイント]クロッカー、D。、フリード、N.、A。カーギル、「チェックポイント/再起動用のSMTPサービス拡張」、RFC 1845、1995年9月。
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995.
[CHUNKING] Vaudreuil、G。、「SMTP Service Extensions for Transmission of Large and Binary MIME Messages」、RFC 1830、1995年8月。
[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., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[DSN] Moore、K。、「SMTP Service Extension for Delivery Status Notifications」、RFC 1891、1996年1月。
[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月。
[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月。
[HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[ヘッダー] Palme、J。、「Common Internet Message Headers」、RFC 2076、1997年2月。
[IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[IPSEC] Atkinson、R。、「Security Protocol for the Internet Protocol」、RFC 1825、1995年8月。
[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月。
[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., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
Braden、R。、編集者、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[PIPELINING] Freed、N。、「コマンドパイプライン処理用のSMTPサービス拡張」、RFC 2197、1997年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月。
[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", Work in Progress.
[SMTP-AUTH]マイヤーズJ.、「認証用のSMTPサービス拡張」、作業中。
[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[SMTP-CODES] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 1893、1996年1月。
[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 14, RFC 974, January 1986.
パートリッジ、C。、「メールルーティングとドメインシステム」、STD 14、RFC 974、1986年1月。
Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
Braden、R。、編集者、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
Randall Gellens QUALCOMM Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 U.S.A.
Randall Gellens QUALCOMM Incorporated 6455 Lusk Blvd. San Diego、CA 92121-2779 U.S.A.
Phone: +1 619 651 5115
Fax: +1 619 651 5334
EMail: Randy@Qualcomm.Com
John C. Klensin MCI Telecommunications 800 Boylston St, 7th floor Boston, MA 02199 USA
John C. Klensin MCI Telecommunications 800 Boylston St、7th floor Boston、MA 02199 USA
Phone: +1 617 960 1011
EMail: klensin@mci.net
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。