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. このメモの状態 この文書はインターネット共同体に対し、Internet standards track protocol (標準化過程にあるプロトコル)を規定し、改善への議論や提案を 求める。このプロトコルが標準化の過程において、どのような位置にあるかに ついては、「Internet Official Protocol Standards」の現在の版を参照して ほしい。このメモの配布は無制限である。 Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. 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 Gellens & Klensin Standards Track [Page 1] RFC 2476 Message Submission December 1998 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 1. Abstract 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は、「Received」「Return-Path」や他の[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 which accepts message submissions from MUAs is termed a Message Submission Agent (MSA). にもかかわらず、SMTPは今やメッセージの「サブミッション」プロトコルとし ても広く使われており、即ちMUAにとって、MTAのルーティングネットワークへ 新しいメッセージを導入することを意味する。MUAからメッセージサブミッショ ンを受け入れるプロセスは、メッセージサブミッションエージェント(Message Submission Agent; 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]やそれ以降の要求に適合することを保 証するように完成させられる必要がある。例えば、メッセージは適切な「Date」 ヘッダフィールドを欠いているかもしれないし、ドメインが完全に修飾されて いないかもしれない。いくつかの場合、MUAは完全なメッセージを生成するこ とができないかもしれない(例えば、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 * セキュリティポリシーの実装、権限のないメールのリレーや求められていな い大量のメール(UBE)の注入に対する防御 * Implement authenticated submission, including off-site submission by authorized users such as travelers * 旅行者のような許可されたユーザによるオフサイトなサブミッションを含む、 認証されたサブミッションの実装 Gellens & Klensin Standards Track [Page 2] RFC 2476 Message Submission December 1998 * 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, . To subscribe, send a message containing SUBSCRIBE to . Private comments may be sent to the authors. 公からのコメントはIETF submitメーリングリストに送 られるべきである。登録するには、SUBSCRIBEを含むメッセージを あてに送りなさい。私的なコメントは著者た ちに送ってもよい。 2. Document Information 文書の情報 2.1. Definitions of Terms Used in this Memo このメモで使われている用語の定義 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. 完全に修飾された グローバルなドメインネームサービス(DNS)を使ってグローバルに解決可能なドメインから成る。つまり、ローカルな別名や部分的な規定ではない。 Message Submission Agent (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. メッセージサブミッションエージェント(MSA) この仕様書で確立されるプロセスで、MUAからのメッセージを受理し、それを 配送するか、SMTPクライアントとしてMTAへとリレーするようなサブミッショ ンサーバとして振る舞う。 Message Transfer Agent (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. メッセージ伝達エージェント(MTA) [SMTP-MTA]で確立されるプロセスで、MSAや別のMTAからメッセージを受け取り、 それを配送したり、SMTPクライアントとして別のMTAにリレーしたりするSMTP サーバとして振る舞う。 Message User Agent (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) (普通ユーザに変わって)新しいメッセージを作ったり提出したりするプロセ スで、またメッセージが配送されるプロセスである。分離したMUAモデルにお いて、POPやIMAPが配送されたメッセージへのアクセスに利用される。 Gellens & Klensin Standards Track [Page 3] RFC 2476 Message Submission December 1998 2.2. Conventions Used in this Document 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. 2.2 この文書中で使われる慣例 例中、「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]に定義されているように解釈されるべきである。 3. Message Submission 3 メッセージサブミッション 3.1. Submission Identification 3.1 サブミッションの識別 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が、この文書で規定されるE-mailメッセージサブミッションのため に予約される。このポートで受信したメッセージはサブミッションであると定 義する。使われるプロトコルは、ここで規定される追加の制限付きの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. ほとんどのE-mailクライアントやサーバはポート25のかわりに587を利用する ように設定可能ではあるが、これが不可能だったり不便だったりする場合もあ る。サイトは、いくつかのホストがMSA、他がMTAであると示すことで、メッセー ジサブミッションのためにポート25を利用することを選択してもよい(MAY)。 3.2. Message Rejection and Bouncing 3.2 メッセージの拒絶とバウンス MTAs and MSAs MAY implement message rejection rules that rely in part on whether the message is a submission or a relay. MTAとMSAは、あるメッセージについて、サブミッションまたはリレーいずれか について、部分的に信頼するようなメッセージの拒絶ルールを実装してもよい (MAY)。 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 addressやユーザ認証で認証されたユーザ以外からのメッセージサブミッショ ンをすべて拒否するように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. 注意:ダメージを受けたメッセージを送ることを危険覚悟で行うよりも、メッ セージを拒否する方がよい。これは特に、例えば不正な「From」フィールドの ような、MUAによて修正可能な問題について言える。 If an MSA is not able to determine a return path to the submitting user, from a valid MAIL FROM, a valid source IP address, or based on authenticated identity, then the MSA SHOULD immediately reject the message. A message can be immediately rejected by returning a 550 code to the MAIL FROM command. もしMSAが正当なMAIL FROM, 正当なソースIP address, あるいはユーザ認証に よってサブミットしたユーザにリターンパスを決定できなかったなら、MSAは、 そのメッセージを即時拒否すべきである(SHOULD)。メッセージは、MAIL FROM コマンドに対して550のエラーコードが返ることで、すぐに拒否されるだろう。 Gellens & Klensin Standards Track [Page 4] RFC 2476 Message Submission December 1998 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.) なにもないリターンパス、つまり MAIL FROM:<> は許可され、受けとられねば ならない(MUST)ことに注意(MUAは、廃棄の通知を含めた様々な理由で、からっ ぽの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 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が拒否コードを発行するような指示になっているこの仕様 書中のテキストは、メッセージを受け取り、続いてバウンスメッセージを生成 するように解釈されるかもしれない(MAY)(それは、もし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による確かな取り扱いには、サブミットされ たメッセージキューの保守が必要であり、それへのバウンスに一致する。 3.3. Authorized Submission 認証されたサブミッション 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 AUTH, IP addressによる制限、secure 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に対してメッセー ジサブミッションのための認証に決着をつけ、他のプロトコルと結びついてい ない。 IP address restrictions are very widely implemented, but do not allow for travellers and similar situations, and can be spoofed. IP addressによる制限は非常に広く実装されているが、旅行者やそれに近い状 況では許可されず、また詐称され得る。 Secure IP [IPSEC] can also be used, and provides additional benefits of protection against eavesdropping and traffic analysis. Secure 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分)以 内に(同じIP addressからの)POP [POP3] 認証を要求することもまた、利用 されているが、これは、クライアントと同様、サーバにも困難を引き起こすか もしれない制限を強要する。明確に、クライアントはSMTPサブミッションのセッ ションの前にPOP認証を行わなければならず、すべてのクライアントにとって これが可能で、このように設定されるとは限らない。また、MSAはPOPサーバと 整合して動作しなければならず、それは難しいかもしれない。認証されていな いユーザが先だって認証されたユーザであるように見え、メッセージをサブミッ ションできる窓口もある。 Gellens & Klensin Standards Track [Page 5] RFC 2476 Message Submission December 1998 3.4. Enhanced Status Codes 3.4 拡張されたステータスコード(enhanced status code) This memo suggests several enhanced status codes [SMTP-CODES] for submission-specific rejections. The specific codes used are: このメモは、サブミッション特有の拒絶のために、いくつかの拡張されたステー タスコード(enhanced status code) [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 サイトポリシー。メッセージはなんらかの方法で、サイトポリシーに反 しているように見える。 4. Mandatory Actions 必須のアクション An MSA MUST do all of the following: MSAは以下のすべてをなさねばならない(MUST) 4.1. General Submission Rejection Code 4.1 一般的なサブミッションの拒否コード 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. もし、より正確な応答コードでカバーされていないなら、不適切な何かを含む MAIL FROM, RCPT TO, DATAコマンドを拒絶するのに、応答コード554が使われ る。もし、他のより明確なコードがない場合には、拡張されたステータスコー ド(enhanced status code) 5.6.0が使われることになる。 4.2. Ensure All Domains are Fully-Qualified 4.2 すべてのドメインが完全修飾である保証 The MSA MUST ensure that all domains in the envelope are fully- qualified. MSAは、エンベロープ中のすべてのドメインが完全修飾であることを保証しな ければならない(MUST)。 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] の追加以外で、何かの方 法でメッセージテキストを検査、或いは変更するのであれば、アドレスヘッダ フィールド中のすべてのドメインが完全修飾であることを保証しなければなら ない(MUST)。 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 Gellens & Klensin Standards Track [Page 6] RFC 2476 Message Submission December 1998 '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」)を受け取り、そしてドメイン名の残り部分が追加拡張される(例 えば、「sales.example.net」へと)。シングルレベルドメインを許可するロー カルの便宜は、特に危険であるため、不完全なマルチレベルドメインを拡張す るより拒否するべき(SHOULD)である。 5. Recommended Actions 5 推奨アクション The MSA SHOULD do all of the following: MSAは以下のすべてを行うべきである(SHOULD) 5.1. Enforce Address Syntax 5.1 アドレス構文を守らせること 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. 検出可能な不正なアドレスを持つMAIL FROMやRCPT TOコマンドを拒絶するため に、応答コード501が使われる。 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. メッセージボディのサブミッション後、アドレスが解決されたとき、もしもメッ セージがヘッダ中、不正なアドレスを含んでいたならば、end-of-dataの後に 応答コード554 拡張コード5.6.2が使われる。 5.2. Log Errors ログエラー The MSA SHOULD log message errors, especially apparent misconfigurations of client software. MSAは、特にクライアントソフトウェアの明白な設定間違いに対し、メッセー ジエラーをログに残すべきである(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つの利点である:システム管理者は、ローカルの設定 の問題に興味を持つかもしれないが、他のサイトのクライアントの問題には興 味をもたないだろう。 6. Optional Actions 6 オプションのアクション The MSA MAY do any of the following: MSAは以下のいずれについても、なしてもよい(MAY): 6.1. Enforce Submission Rights 6.1 サブミッションの権利の強制 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). もし、MAIL FROMにあるアドレスが、不適切なサブミッションの権利を有して いるなら、或いは(セッションが認証されている場合において)認証に失敗し ている場合、MAIL FROMコマンドに対してエラーのレスポンスを発行してもよ い(MAY)。 Reply code 550 with enhanced status code 5.7.1 is used for this purpose. 応答コード550 拡張ステータスコード5.7.1 がこの目的に使われる。 Gellens & Klensin Standards Track [Page 7] RFC 2476 Message Submission December 1998 6.2. Require Authentication 6.2 認証要求 The MSA MAY issue an error response to the MAIL FROM command if the session has not been authenticated. セッションがまだ認証されていない場合、MSAはMAIL FROMコマンドに対してエ ラーの応答を発行してもよい(MAY)。 Section 3.3 discusses authentication mechanisms. 認証メカニズムについてはセクション3.3において議論される。 Reply code 530 [SMTP-AUTH] is used for this purpose. 応答コード530 [SMTP-AUTH] がこの目的に利用される。 6.3. Enforce Permissions 許可の強制 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. 応答コード550 拡張ステータスコード 5.7.1 がこの目的に使われる。 6.4. Check Message Data メッセージデータのチェック 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コマンドに対してエラーの応答を発行するか、 end-of-dataの後に失敗の結果(failure result)を送ってもよい(MAY)。 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が使われる。サブミッショ ンするユーザに基づく拒絶に対して、応答コード550 拡張ステータスコード 5.7.1が使われる。メッセージがサイトポリシーに反する場合、応答コード550 拡張ステータスコード 5.7.0 が使われる。 7. Interaction with SMTP Extensions SMTPの拡張との相互作用 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: 以下の表は、現在(1998年)におけるSMTP の拡張の標準(standard-track)と実 験(experimental)のリストである。リストしたものはRFC, 名称、submit port 上での拡張の利用に関する指示、参照名である。 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] Gellens & Klensin Standards Track [Page 8] RFC 2476 Message Submission December 1998 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の拡張は、submit port上有効になったら明記されるべきである。 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. [CODES-EXTENSION]によれば、拡張ステータスコード [SMTP-CODES]はサポート されるべきであり(SHOULD)、使われるべきである(SHOULD)。これにより、この メモで述べた応答コードより詳細な、設定あるいはそれ以外の特定の問題につ いて、MSAがクライアントに知らせることができるようになる。いくつかの拒 絶では、サイトのセキュリティポリシーによるため、問題解決に必要である以 上の詳細をさらさないよう注意が必要である。 [PIPELINING] SHOULD be supported by the MSA. [PIPELINING] はMSAによってサポートされるべきである(SHOULD)。 [SMTP-AUTH] allows the MSA to validate the authority and determine the identity of the submitting user. [SMTP-AUTH]では、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であるとみなす(DATA相当のコマンドを DATAであるとみなす)。 8. Message Modifications 8 メッセージの変更 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. サイトは、標準への準拠やサイトポリシーを保証するために、提出されたもの (メッセージ)を変更してもよい(MAY)。このセクションでは、しばしば有用 とみなされる、そのような多くの修正について記す。 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. 注意:ローカルの決定でメッセージ変更を実装するガイダンスとして、卓越し たルールは、はっきりとした解法を持つ特定の問題を治療するような行動を制 限する。これは、特にアドレスの要素において真である。例えば、アドレスや ドメインを欠いた要素への無差別なドメインの追加は、より多くの壊れたアド レスに帰着する。不適切なアドレスは、安全にドメインが追加される前に、ド メインの有効なローカルパートに照合されねばならない。 8.1. Add 'Sender' 8.1 Senderの追加 The MSA MAY add or replace the 'Sender' field, if the identity of the sender is known and this is not given in the 'From' field. もし送り主が分かっていて、かつそれが「From」フィールドで与えられるもの と異なるなら、MSAは「Sender」フィールドを追加するか、置き換えてもよい (MAY)。 The MSA MUST ensure that any address it places in a 'Sender' field is in fact a valid mail address. MSAが置いた「Sender」フィールドのアドレスが、実際に有効なメールアドレ スであることを、MSAは保証しなければならない(MUST)。 Gellens & Klensin Standards Track [Page 9] RFC 2476 Message Submission December 1998 8.2. Add 'Date' 8.2 Dateの追加 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. もしサブミッションされたメッセージが「Date」フィールドを欠いていれば、 MSAは「Date」フィールドを追加してもよく(MAY)、また、もし [MESSAGE-FORMAT]の構文に適合しないならば、「Date」フィールドを修正して もよい(MAY)。 8.3. Add 'Message-ID' 8.3 Message-IDの追加 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]). 欠けているか、正しい構文([MESSAGE-FORMAT]で定義されている)でないなら、 MSAは「Message-ID」フィールドを追加したり、置き換えたりしてもよい(MAY)。 8.4. Transfer Encode 8.4 transfer encode(伝達のためのコード化) The MSA MAY apply transfer encoding to the message according to MIME conventions, if needed and not harmful to the MIME type. もし必要かつMIME typeにとって有害でないなら、MSAは、MIMEのとりきめによっ てメッセージをtransfer encodeしてもよい(MAY)。 8.5. Sign the Message 8.5 メッセージへのサイン The MSA MAY (digitally) sign or otherwise add authentication information to the message. MSAはメッセージに対して、サインや他の認証情報の追加を(デジタルで)行っ てもよい(MAY)。 8.6. Encrypt the Message メッセージの暗号化 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]メカニズムの利用によって、が必要である。 8.7. Resolve Aliases 8.7 別名の解決 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の別名である場合、書き換えで有 用な情報が失われる可能性がある。 8.8. Header Rewriting 8.8 ヘッダの書き換え 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 ' Gellens & Klensin Standards Track [Page 10] RFC 2476 Message Submission December 1998 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」と一致するならば、ドメインの最も左側の要素を取り 除くようなルールは受け入れられるだろう。 9. Security Considerations 9 セキュリティに関する考察 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種類のサービスに対し、サイトは異なるポリシーを実装できるようになる。 サブミッションとリレーを分離することで、異なるポリシーの実装が技術、管 理両面においてより容易な方法で可能となる。これにより、ポリシーが正しく 適用される可能性が高くなる。 Separation also can aid in tracking and preventing unsolicited bulk email. 分離により、求められていない大量のE-mail(UBE)を見つけ、避ける助けにも なり得る。 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に対し、メッセージを受信する前に認証を要求するよう に設定し、MTAに対し、ローカルユーザでないすべてのRCPT TOを拒絶するよう に設定することができる。これは、サイトの全体としてのE-mailセキュリティ ポリシーにおいて、重要な要素かもしれない。 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での議論を見よ)を要求することを怠るならば、それによりサイトの資源 と名前が自由に使われる;求められていない大量のE-mail(UBE)がその施設を 用いて導入されるかもしれない。 10. Acknowledgments 謝辞 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 ML内外でのコメントや議論を元 に更新されてきている。 草稿にレビューしたり助言をくれたりするのに時間 をかけてくれた人の助け、特にDave Crocker, Ned Freed, Keith Moore, John Myers, Chris Newmanに感謝する。 Special thanks to Harald Alvestrand, who got this effort started. この努力を始めたHarald Alvestrandに特別に感謝する。 Gellens & Klensin Standards Track [Page 11] RFC 2476 Message Submission December 1998 11. References [521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995. [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit- MIMEtransport", RFC 1652, July 1994. [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995. [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995. [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [DSN] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995. [ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996. [HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. [IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Gellens & Klensin Standards Track [Page 12] RFC 2476 Message Submission December 1998 [MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982; Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. [PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997. [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996. [SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995. [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", Work in Progress. [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996. [SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986. Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. Gellens & Klensin Standards Track [Page 13] RFC 2476 Message Submission December 1998 12. Authors' Addresses 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 Phone: +1 617 960 1011 EMail: klensin@mci.net Gellens & Klensin Standards Track [Page 14] RFC 2476 Message Submission December 1998 13. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. 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. Gellens & Klensin Standards Track [Page 15] ---- 訳について この訳は、美森勇気 が個人的な目的で行いました。利用 は自由ですが、一切の保証はしません。