6. Problem Detection and Handling 6 問題の発見と扱い 6.1 Reliable Delivery and Replies by Email 6.1 Emailによる信頼できる配送と応答 When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage. 受信側SMTPがメールを受けとったとき(DATAへの応答で"250 OK"メッセージを 送ることにより)、そのメッセージを配送ないしリレーする責任を受けとる。 それはこの責任を真剣にうけとめなければならない。ホストが後にクラッシュ するとか、予期できる資源の不足といったつまらない理由でメッセージを失っ てはならない(MUST NOT)。 If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification. Obviously, nothing in this section can or should prohibit local decisions (i.e., as part of the same system environment as the receiver-SMTP) to log or otherwise transmit information about null address events locally if that is desired. If the address is an explicit source route, it MUST be stripped down to its final hop. メッセージ受信後に配送に失敗したならば、受信側のSMTPは説明し、お知らせ メッセージを送らなければならない(MUST)。このお知らせは、エンベロープの reverse-pathにヌルを用いて送信されなければならない(MUST)。このお知らせ の受信者はエンベロープのreturn-path(Return-path: 行)のアドレスでなけれ ばならない(MUST)。しかしながら、もしそのアドレスがヌル("<>")ならば、受 信したSMTPサーバはお知らせを送ってはならない。明らかに、このセクション にあるいずれも、もし望むなら、ヌルアドレスのイベントの転送情報のログな どをとるような、ローカルでの決定を何ら禁止しない(つまり、受信者SMTPと して同じシステム環境の部分として)。もしアドレスが明確なソースルーティ ングであるならば、それは最終ホップへと奪い去らねばならない(MUST)。 For example, suppose that an error notification must be sent for a message that arrived with: 例えば、エラーのお知らせが下記と共に到着するメッセージで送られなければ ならないと仮定する： MAIL FROM:<@a,@b:user@d> The notification message MUST be sent using: お知らせメッセージは以下を用いて送られなければならない: RCPT TO: Some delivery failures after the message is accepted by SMTP will be unavoidable. For example, it may be impossible for the receiving SMTP server to validate all the delivery addresses in RCPT command(s) due to a "soft" domain system error, because the target is a mailing list (see earlier discussion of RCPT), or because the server is acting as a relay and has no immediate access to the delivering system. メッセージがSMTPによって受信されてから配送に失敗することは、避けられな い。例えば、目標はメーリングリスト(RCPTの以前の議論を見よ)であったり、 サーバがリレーとして働いていたり、配送系にすぐにアクセスできなかったり による「ソフトな」ドメインシステムのエラーを起こすことにより、受信した SMTPサーバがRCPTコマンドにあるすべての配送アドレスを確認することは、不 可能である。 To avoid receiving duplicate messages as the result of timeouts, a receiver-SMTP MUST seek to minimize the time required to respond to the final . end of data indicator. See RFC 1047 [28] for a discussion of this problem. タイムアウトの結果として二重のメッセージを受信することを避けるには、受 信側のSMTPはデータが終わる印の最後の.への応答に必要とされ る時間を最小に追及しなければならない(MUST)。この問題への議論は RFC1047[28]を見よ。 Klensin Standards Track [Page 62] RFC 2821 Simple Mail Transfer Protocol April 2001 6.2 Loop Detection 6.2 ループの発見 Simple counting of the number of "Received:" headers in a message has proven to be an effective, although rarely optimal, method of detecting loops in mail systems. SMTP servers using this technique SHOULD use a large rejection threshold, normally at least 100 Received entries. Whatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops. まれに最適化されたメールシステムでのループ発見方法があるにもかかわらず、 メッセージ中の"Received:"ヘッダの数を単純に数えるのが有効と確認されて いる。この技術を用いるSMTPサーバは、普通最低100のReceivedエントリの、 大きな拒否の閾値を用いるべきである(SHOULD)。どのような機構を使うにせよ、 サーバはつまらないループを発見し、停止させる方法を持たねばならない (MUST)。 6.3 Compensating for Irregularities 6.3 不規則の補正 Unfortunately, variations, creative interpretations, and outright violations of Internet mail protocols do occur; some would suggest that they occur quite frequently. The debate as to whether a well- behaved SMTP receiver or relay should reject a malformed message, attempt to pass it on unchanged, or attempt to repair it to increase the odds of successful delivery (or subsequent reply) began almost with the dawn of structured network mail and shows no signs of abating. Advocates of rejection claim that attempted repairs are rarely completely adequate and that rejection of bad messages is the only way to get the offending software repaired. Advocates of "repair" or "deliver no matter what" argue that users prefer that mail go through it if at all possible and that there are significant market pressures in that direction. In practice, these market pressures may be more important to particular vendors than strict conformance to the standards, regardless of the preference of the actual developers. 不運なことに、インターネットメールプロトコルへのばらつき、創造的な解釈、 まったくの違反が起こる；それは大変よくあることだと誰かが言うだろう。よ いふるまいをするSMTP受信者ないしリレーが奇形のメッセージを拒否するべき か、それを変更することなく通過させようとすべきか、成功した配送(や、そ れに続く応答)のおかしな点を直そうとすべきかという点についての議論は、 構築されたネットワークメールの夜明けのころに始まり、おさまる気配も見せ ない。修正する試みの拒否を要求する支持者たちはまれに完全に適切であり、 悪いメッセージを拒否することは機嫌をそこねたソフトウェアを直す唯一の方 法である。「修正」や「何事もなかったように配送」の支持者は、ユーザは可 能であればメールが通り抜けることを望むし、そうするよう大きな市場の圧力 がある、と論じる。実際、特定のベンダーにとってこれらの市場圧力は、実際 の開発者の嗜好にかかわらず、標準への厳密な準拠よりも重要である。 The problems associated with ill-formed messages were exacerbated by the introduction of the split-UA mail reading protocols [3, 26, 5, 21]. These protocols have encouraged the use of SMTP as a posting protocol, and SMTP servers as relay systems for these client hosts (which are often only intermittently connected to the Internet). Historically, many of those client machines lacked some of the mechanisms and information assumed by SMTP (and indeed, by the mail format protocol [7]). Some could not keep adequate track of time; others had no concept of time zones; still others could not identify their own names or addresses; and, of course, none could satisfy the assumptions that underlay RFC 822's conception of authenticated addresses. 正しくない形式のメッセージに関連した問題は、分裂したUAのメールリーディ ングプロトコル[3,26,5,21]の導入により悪化させられる。これらのプロトコ ルは送信プロトコルとしてSMTPと、これらのクライアントホスト(それらはし ばしば、インターネットへ間欠的にのみ接続される)のためのリレーシステム としてのSMTPサーバの利用が促される。歴史的に、こういったクライアントマ シンの多くはSMTP(そして実は、メールフォーマットプロトコル[7])によって 仮定されるいくつかの機構と情報を欠いている。いくつかは時間の追跡をしつ づけるに適当ではない；他のものはタイムゾーンの概念を持たない；また、他 の物は自分自身の名前やアドレスを識別できない；そして、もちろん、RFC 822の認証アドレスの考え方を根底に持つ前提を見たすことができない。 In response to these weak SMTP clients, many SMTP systems now complete messages that are delivered to them in incomplete or incorrect form. This strategy is generally considered appropriate when the server can identify or authenticate the client, and there are prior agreements between them. By contrast, there is at best great concern about fixes applied by a relay or delivery SMTP server that has little or no knowledge of the user or client machine. これらの弱いSMTPクライアントへの応答として、多くのSMTPシステムは現在、 不完全ないし不正なフォームで配送されるメッセージを完成させる。サーバが クライアントを識別ないし認証でき、かつ双方の間で先立って取り決められて いる時、一般にこの戦略は適切と考えられている。反対に、ユーザやクライア ントマシンについて少しだけ、ないしまったく知らないリレーか配送SMTPサー バによって適用された修正について、大きな問題がある。 Klensin Standards Track [Page 63] RFC 2821 Simple Mail Transfer Protocol April 2001 The following changes to a message being processed MAY be applied when necessary by an originating SMTP server, or one used as the target of SMTP as an initial posting protocol: メッセージが処理されることによる以下の変更は、起源となるSMTPサーバによっ て必要とされた時、あるいはそれが最初の送信プロトコルでSMTPの目標として 使われた場合適用されるかもしれない(MAY)： - Addition of a message-id field when none appears 存在しないときmessage-idフィールドを追加する - Addition of a date, time or time zone when none appears 存在しないときdate, time, timezoneフィールドを追加する - Correction of addresses to proper FQDN format アドレスの正確なFQDNフォーマットへの修正 The less information the server has about the client, the less likely these changes are to be correct and the more caution and conservatism should be applied when considering whether or not to perform fixes and how. These changes MUST NOT be applied by an SMTP server that provides an intermediate relay function. サーバがクライアントについて持っている情報が少ないと、これらの変更は正 しくされにくくなって警告が増え、修正するかどうか、どのようにするかを考 える際、保守主義が適用される。これらの変更は、途中のリレー機能を提供す るSMTPサーバによって適用されてはならない(MUST NOT)。 In all cases, properly-operating clients supplying correct information are preferred to corrections by the SMTP server. In all cases, documentation of actions performed by the servers (in trace fields and/or header comments) is strongly encouraged. すべての場合において、正しい情報を提供する正しく運用されているクライア ントはSMTPサーバによる修正を望む。すべての場合において、サーバによって なされるアクション(トレースフィールドと／またはヘッダコメント)の文書化 は強く奨励される。 7. Security Considerations 7. セキュリティに関する考察 7.1 Mail Security and Spoofing 7.1 メールセキュリティと詐称 SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else. Constructing such a message so that the "spoofed" behavior cannot be detected by an expert is somewhat more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable. 受信やリレーのSMTPサーバへ直接繋ぐことができることや、経験の浅い受信者に どこか他から来たと信じられるようだますメッセージを作成することが略式の ユーザにさえ公平に実現可能であることから、SMTPメールは本質的にセキュア でない。 専門家に発見不可能なように詐称してふるまうようなメッセージを作成することは それよりいくらか難しいが、解決でき、知っている人の十分なさまたげとならない。 Consequently, as knowledge of Internet mail increases, so does the knowledge that SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]). 続いて、インターネットメールの知識は増えているので、SMTPメールは本質的 に認証され得ないとか、配送レベルで完全なチェックを提供できないという知 識も増えている。本当のメールセキュリティはメッセージボディに含まれた、 例えばデジタル署名を用いるようなエンドトゥエンドの方式だけにある([14] を見よ。例えばPGP[4]やS/MIME[31])。 Various protocol extensions and configuration options that provide authentication at the transport level (e.g., from an SMTP client to an SMTP server) improve somewhat on the traditional situation described above. However, unless they are accompanied by careful handoffs of responsibility in a carefully-designed trust environment, they remain inherently weaker than end-to-end mechanisms which use digitally signed messages rather than depending on the integrity of the transport system. 配送レベルでの(例えば、SMTPクライアントからSMTPサーバの)認証を提供する いろいろなプロトコルの拡張と設定オプションは上記の従来の状況をいくぶん か改善する。しかしながら、注意深くデザインされた信用できる環境への責任 の注意深いハンドオフを伴なわない限り、それはまだ本質的に配送システムの 完全性に依存するよりむしろデジタル署名されたメッセージを使うエンドトゥ エンドメカニズムよりも弱い。 Klensin Standards Track [Page 64] RFC 2821 Simple Mail Transfer Protocol April 2001 Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another or in which error (or normal) replies should be directed to a special address. (Systems that provide convenient ways for users to alter these fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender fields within the message data can be generated sensibly.) ユーザが、主として間違った方に導かれる彼ら自身のもの以外の有効なアドレ スを指すようにエンベロープreturn-pathや"From:"ヘッダフィールドを設定す るのをより難しくする努力：ある人の代わりに別のユーザによってメールが送 られたり、特殊なアドレスへとエラー応答が向けられるのに、彼らは合法的な アプリケーションの利用をあきらめる。(メッセージごとの理由で、これらの フィールドの代わりにユーザに便利な方法を提供するシステムは、主要で永続 的なメールボックスアドレスを受信者に対して知らせる試みをすべきであるこ とから、賢明にもメッセージデータに含まれるSenderフィールドを生成できる。) This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail. この規定により、メールを偽造しようとする無知なユーザからは若干保護され るかもしれないが、便利な機能は使えないようにすべきでない、という意見の 支持者がSMTPに関連した認証の問題を言うのと同程度のことしか述べていない。 7.2 "Blind" Copies 7.2 "Blind"コピー Addresses that do not appear in the message headers may appear in the RCPT commands to an SMTP server for a number of reasons. The two most common involve the use of a mailing address as a "list exploder" (a single address that resolves into multiple addresses) and the appearance of "blind copies". Especially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the headers, either as part of trace headers or as informational or private-extension headers. Since this rule is often violated in practice, and cannot be enforced, sending SMTP systems that are aware of "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command. メッセージヘッダに現れないアドレスがいくつかの理由により、SMTPサーバに 対するRCPTコマンドに現れるかもしれない。最も一般的な2つは、「リストの 起爆装置」(複数のアドレスに展開される単一のアドレス)としてのメーリング リストのアドレスの利用と、"blindcopies"の出現である。特に複数のRCPTコ マンドが存在するとき、またこれらのメカニズムの目的がうまくいかないのを 防ぐために、SMTPクライアントとサーバはヘッダにトレースヘッダの一部、あ るいは情報的ないし私的に拡張されたヘッダとして、RCPTコマンドの引数のフ ルセットをコピーすべきではない(SHOULD NOT)。このルールはしばしば実際に は守られず、強行できないので、"bcc"を利用するのに気付いた送信SMTPシス テムは、1つだけのRCPTコマンドを持つ別個のメッセージトランザクションと して、それぞれのblind copyを送信するのが有用であると思うかもしれない (MAY)。 There is no inherent relationship between either "reverse" (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the headers. Receiving systems SHOULD NOT attempt to deduce such relationships and use them to alter the headers of the message for delivery. The popular "Apparently-to" header is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used. SMTPトランザクション("envelope")における"reverse"(MAIL, SAMLなどのコマ ンド)ないし"forward"(RCPT)アドレスと、ヘッダにあるアドレスとの間には、 本質的には関連がない。受信側のシステムはそれらの関連を推測し、配送のた めのメッセージヘッダに代えて利用しようとするべきではない(SHOULD NOT)。 一般的な"Apparently-to"ヘッダは、意図しない情報公開の共通する源と同様、 この原理に違反し、使われるべきではない(SHOULD NOT)。 7.3 VRFY, EXPN, and Security 7.3 VRFY, EXPN とセキュリティ As discussed in section 3.5, individual sites may want to disable one or both VRFY or EXPN for security reasons. As a corollary to the above, implementations that permit this MUST NOT appear to have verified addresses that are not, in fact, verified. If a site Klensin Standards Track [Page 65] RFC 2821 Simple Mail Transfer Protocol April 2001 disables these commands for security reasons, the SMTP server MUST return a 252 response, rather than a code that could be confused with successful or unsuccessful verification. セクション3.5で議論したように、それぞれのサイトではセキュリティ上の理 由からVRFYとEXPNのいずれか、或いは両方を使えなくすることを望むかもしれ ない。上記の結果、これを許す実装は、実際には確認されていないアドレスを 確認されたものであるように見せてはならない(MUST NOT)。 サイトがセキュリティ上の理由でこれらのコマンドを使えなくしたならば、 SMTPサーバは確認に成功したか不成功だったか、と混乱するかもしれないコー ドではなく、252応答を返さねばならない。 Returning a 250 reply code with the address listed in the VRFY command after having checked it only for syntax violates this rule. Of course, an implementation that "supports" VRFY by always returning 550 whether or not the address is valid is equally not in conformance. 構文のみチェックした後にVRFYコマンドで並べられたアドレスに250応答コー ドを返すことは、このルールに反する。もちろん、アドレスが有効か否かにか かわらず常に550を返すようなVRFYをサポートする実装は、同じように適合し ていない。 Within the last few years, the contents of mailing lists have become popular as an address information source for so-called "spammers." The use of EXPN to "harvest" addresses has increased as list administrators have installed protections against inappropriate uses of the lists themselves. Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs. As authentication mechanisms are introduced into SMTP, some sites may choose to make EXPN available only to authenticated requestors. ここ数年、メーリングリストの内容は"spammers"と呼ばれる者にとってアドレ ス情報の源として一般化している。リストの管理者がリスト自身の不適切な利 用に対しての防御を組み込むので、アドレスを「収穫」するためにEXPNを利用 することが増えている。実装ではまだEXPNのサポートを提供するべきである (SHOULD)が、サイトは注意深くトレードオフを評価すべきである(SHOULD)。 SMTPに認証メカニズムが導入されたら、いくつかのサイトは認証された要求者 に対してのみEXPNを有効にすることを選ぶかもしれない。 7.4 Information Disclosure in Announcements 7.4 アナウンスによる情報公開 There has been an ongoing debate about the tradeoffs between the debugging advantages of announcing server type and version (and, sometimes, even server domain name) in the greeting response or in response to the HELP command and the disadvantages of exposing useful information to potential hostile attack. The utility of the debugging information is beyond doubt. Those who argue for making it available point out that it is far better to actually secure an SMTP server rather than hope that trying to conceal known vulnerabilities by hiding the server's precise identity will provide more protection. Sites are encouraged to evaluate the tradeoff with that issue in mind; implementations are strongly encouraged to minimally provide for making type and version information available in some way to other network hosts. 挨拶への応答やHELPコマンドへの応答でサーバタイプとバージョン(時にはサー バのドメイン名)をアナウンスすることによるデバッグにおける利点と、潜在 的に悪意ある攻撃にとって有用な情報を公開する欠点のトレードオフについて、 議論がなされてきている。デバッグ情報の利用は、疑惑を超えている。それを 利用可能にするための議論をする人は、サーバの正確な識別子を隠すことによっ て知られた脆弱性を秘密にしよう希望するよりも、実際にセキュアなSMTPサー バがより多くの防御を提供する方がはるかに良いと指摘する。サイトは心して その問題のトレードオフを評価することが推奨される；実装は、別のネットワー クのホストへ何らかの方法でタイプとバージョン情報を利用可能にするために、 最小限提供することが推奨される。 7.5 Information Disclosure in Trace Fields 7.5 トレースフィールドの情報の公開 In some circumstances, such as when mail originates from within a LAN whose hosts are not directly from the public Internet, trace ("Received") fields produced in conformance with this specification may disclose host names and similar information that would not normally be available. This ordinarily does not pose a problem, but sites with special concerns about name disclosure should be aware of it. Also, the optional FOR clause should be supplied with caution or not at all when multiple recipients are involved lest it inadvertently disclose the identities of "blind copy" recipients to others. いくつかの環境で、メールが、公のインターネットと直接つながっていない LAN内部を起点とするような時、この標準に適合して作られたトレースフィー ルド(Received)はホスト名や、似た普通では入手できない情報を公開してしま うことになるかもしれない。たいてい、これは問題を引き起こさないが、名前 の公開に関して特別に心配するサイトでは、それに気をつけるべきである。ま た、オプションのFOR節は、複数の受信者が含まれるとき、うっかり他の人に "blind copy"の受信者の正体を開かしてしまうといけないので、注意して提供 するか、まったく提供すべきでない。 Klensin Standards Track [Page 66] RFC 2821 Simple Mail Transfer Protocol April 2001 7.6 Information Disclosure in Message Forwarding メッセージフォワーディングでの情報の公開 As discussed in section 3.4, use of the 251 or 551 reply codes to identify the replacement address associated with a mailbox may inadvertently disclose sensitive information. Sites that are concerned about those issues should ensure that they select and configure servers appropriately. セクション3.4で議論したように、メールボックスに関連するアドレスの変更 を識別する251ないし551応答コードを利用することにより、うかつにも慎重を 要する情報が公開されてしまうかもしれない。こういう問題について関心を持 つサイトは適切にサーバを選択し設定したことを確認すべきである。 7.7 Scope of Operation of SMTP Servers 7.7 SMTPサーバ運用の範囲 It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server. However, cooperation among sites and installations makes the Internet possible. If sites take excessive advantage of the right to reject traffic, the ubiquity of email availability (one of the strengths of the Internet) will be threatened; considerable care should be taken and balance maintained if a site decides to be selective about the traffic it will accept and process. SMTPサーバが運営上や技術的な、サーバを提供するサイトにとって筋の通った 理由によりメールを受けとることを拒否するかもしれないということは、良く 確立された原理である。しかしながら、サイトや設備間の協調はインターネッ トを可能にする。もしもサイトがトラフィックを拒否する権利を過度に行使す るならば、どこでもemailが利用できるということ(インターネットの力の1つ) はおびやかされるだろう；もしもサイトが、受信して処理するトラフィックに ついて選択することを決定したならば、かなりの注意をはらい、バランスをと るべきである。 In recent years, use of the relay function through arbitrary sites has been used as part of hostile efforts to hide the actual origins of mail. Some sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering. When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT as appropriate. 近年、任意のサイトからリレー機能を利用することが、実際のメールの出所を 隠すための敵意ある努力の一部として使われている。いくつかのサイトでは、 出所を知っている、ないし識別可能な場合にリレー機能の利用を制限すること を決定してきており、実装はこの型のフィルタが実行できる能力を提供すべき である(SHOULD)。これ、ないしその他ポリシー上の理由でメールが拒否された とき、550コードがEHLO, MAIL, RCPTへの応答に適切に利用されるべきである (SHOULD)。 8. IANA Considerations 8. IANAの考察 IANA will maintain three registries in support of this specification. The first consists of SMTP service extensions with the associated keywords, and, as needed, parameters and verbs. As specified in section 2.2.2, no entry may be made in this registry that starts in an "X". Entries may be made only for service extensions (and associated keywords, parameters, or verbs) that are defined in standards-track or experimental RFCs specifically approved by the IESG for this purpose. IANAはこの規定がサポートする3つのレジストリを維持する。最初のものはキーワー ドと、必要に応じてパラメータと動詞に関連するSMTPサービス拡張からなる。 セクション2.2.2で規定したように、"X"で始まるエントリがこのレジストリに 作られることはなかろう。この目的のためにIESGで承認された標準トラックか 実験的RFCで規定されたサービス拡張(と、それに関連するキーワード、パラメー タ、動詞)についてのみ、エントリが作られるだろう。 The second registry consists of "tags" that identify forms of domain literals other than those for IPv4 addresses (specified in RFC 821 and in this document) and IPv6 addresses (specified in this document). Additional literal types require standardization before being used; none are anticipated at this time. 2つ目のレジストリはIPv4アドレス(RFC 821と本文書で規定)とIPv6アドレス (本文書で規定)のためのもの以外のドメインリテラルの形式を識別するための タグからなる。追加のリテラルタイプは利用する前に標準化する必要がある； 先行するものは現時点ではない。 The third, established by RFC 821 and renewed by this specification, is a registry of link and protocol identifiers to be used with the "via" and "with" subclauses of the time stamp ("Received: header") Klensin Standards Track [Page 67] RFC 2821 Simple Mail Transfer Protocol April 2001 described in section 4.4. Link and protocol identifiers in addition to those specified in this document may be registered only by standardization or by way of an RFC-documented, IESG-approved, Experimental protocol extension. 3つ目は、RFC 821が確立してこの標準が新しくなるので、セクション4.4に書 いたタイムスタンプ(Received ヘッダ)における"via"と"with"従属節で利用さ れるリンクとプロトコルの識別子の登録である。本文書中に規定されたものに 追加されるリンクとプロトコルの識別子は、標準化されるかRFCドキュメント 化されIESGに推薦された実験プロトコルによる拡張による方法のみである。 9. References [1] American National Standards Institute (formerly United States of America Standards Institute), X3.4, 1968, "USA Code for Information Interchange". ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. [2] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989. [3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J. Reynolds, "Post Office Protocol - version 2", RFC 937, February 1985. [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, August 1990. [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 2060, December 1996. [7] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982. [8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [9] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996. [10] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. [11] Freed, N, "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000. [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. Klensin Standards Track [Page 68] RFC 2821 Simple Mail Transfer Protocol April 2001 [13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2920, September 2000. [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156, January 1998. [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995. [19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995. [20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994. [21] Lambert, M., "PCMAIL: A distributed mail system for personal computers", RFC 1056, July 1988. [22] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996. [24] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. Klensin Standards Track [Page 69] RFC 2821 Simple Mail Transfer Protocol April 2001 [27] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986. [28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February 1988. [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981. [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982. [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [32] Resnick, P., Ed., "Internet Message Format", STD 11, RFC 2822, April 2001. [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995. [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996. 10. Editor's Address John C. Klensin AT&T Laboratories 99 Bedford St Boston, MA 02111 USA Phone: 617-574-3076 EMail: klensin@research.att.com 11. Acknowledgments 11. 謝辞 Many people worked long and hard on the many iterations of this document. There was wide-ranging debate in the IETF DRUMS Working Group, both on its mailing list and in face to face discussions, about many technical issues and the role of a revised standard for Internet mail transport, and many contributors helped form the wording in this specification. The hundreds of participants in the many discussions since RFC 821 was produced are too numerous to mention, but they all helped this document become what it is. 多くの人たちがこの文書の何度にもわたる繰り返しに長いこと一生懸命働いてっ くれた。メーリングリスト、直接会っての議論双方でIETF DRUMSワーキンググ ループにおいて、多くの技術的な問題点とインターネットメール配送の訂正さ れた標準としての役割について広域の討論がなされ、多くの貢献者によるこの 規定を言葉であらわす形成の助けがあった。 RFC 821からのたくさんの議論の大勢の参加者は記述するには多すぎるが、彼 らはすべてこの文書がこうなる手助けをしてくれた。 Klensin Standards Track [Page 70] RFC 2821 Simple Mail Transfer Protocol April 2001 APPENDICES 付録 A. TCP Transport Service A TCP転送サービス The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero. Service extensions may modify this rule to permit transmission of full 8-bit data bytes as part of the message body, but not in SMTP commands or responses. TCP接続は8ビットバイトの転送をサポートする。SMTPデータは7ビットのASCII 文字である。それぞれの文字は、高位ビットを0にクリアした8ビットバイトと して転送される。サービス拡張によりこのルールを、SMTPコマンドや応答では なく、メッセージボディの部分では8ビットバイト全部を使って転送すること を許可してもよい。 B. Generating SMTP Commands from RFC 822 Headers B RFC 822ヘッダから生成されるSMTPコマンド Some systems use RFC 822 headers (only) in a mail submission protocol, or otherwise generate SMTP commands from RFC 822 headers when such a message is handed to an MTA from a UA. While the MTA-UA protocol is a private matter, not covered by any Internet Standard, there are problems with this approach. For example, there have been repeated problems with proper handling of "bcc" copies and redistribution lists when information that conceptually belongs to a mail envelopes is not separated early in processing from header information (and kept separate). いくつかのシステムではメール提出プロトコルでRFC 822ヘッダ(だけ)を用い るし、またそのようなメッセージがUAからMTAへと渡された時、RFC 822ヘッダ からSMTPコマンドを生成する。MTA-UAのプロトコルはインターネット標準の範 囲ではなく私的な問題なので、このアプローチには問題がある。例えば、 "bcc"コピーの確かな扱いや、概念的にはメールエンベロープに属する情報が ヘッダ情報の処理で早期に分離されない(し、分離されつづける)という繰り返 されてきている問題がある。 It is recommended that the UA provide its initial MTA with an envelope separate from the message itself. However, if the envelope is not supplied, SMTP commands SHOULD be generated as follows: UAはメッセージそのものからエンベロープを分離するための最初のMTAを準備 する。しかしながら、もしエンベロープが与えられないならば、SMTPコマンド は以下のようにして生成すべきである(SHOULD): 1. Each recipient address from a TO, CC, or BCC header field SHOULD be copied to a RCPT command (generating multiple message copies if that is required for queuing or delivery). This includes any addresses listed in a RFC 822 "group". Any BCC fields SHOULD then be removed from the headers. Once this process is completed, the remaining headers SHOULD be checked to verify that at least one To:, Cc:, or Bcc: header remains. If none do, then a bcc: header with no additional information SHOULD be inserted as specified in [32y]. 1. TO, CC, BCCヘッダフィールドからのそれぞれの受信者アドレスはRCPTコマ ンドへとコピーされるべきである(SHOULD)(それがキューないし配送を要求 するなら、複数のメッセージコピーが生成する)。これは、RFC 822で "group"としてリストされたすべてのアドレスを含む。BCCフィールドは、 その時ヘッダから除かれるべきである(SHOULD)。一度この処理が完了する と、残りのヘッダは少なくとも1つのTo:, Cc:, Bcc:ヘッダが残っているこ とを確認のため、チェックされるべきである(SHOULD)。 2. The return address in the MAIL command SHOULD, if possible, be derived from the system's identity for the submitting (local) user, and the "From:" header field otherwise. If there is a system identity available, it SHOULD also be copied to the Sender header field if it is different from the address in the From header field. (Any Sender field that was already there SHOULD be removed.) Systems may provide a way for submitters to override the envelope return address, but may want to restrict its use to privileged users. This will not prevent mail forgery, but may lessen its incidence; see section 7.1. 2. MAILコマンドのリターンアドレスは、可能なら提出した(ローカルの)ユー ザのためのシステムによる認証から導き出され、そうでなければ"From:"ヘッ ダから導出される。もしシステムによる認証が利用可能であり、もしFrom ヘッダフィールドのアドレスと異なるならば、それはまた、Senderヘッダ フィールドにコピーされるべきである(SHOULD)。(既に存在するいかなる Senderフィールドも除かれるべきである(SHOULD))。システムは提出者に対 し、エンベロープのリターンアドレスを覆す方法を提供してもよいが、特 権ユーザの使用に制限したいかもしれない。これはメールの偽造を防ぐわ けではないだろうが、その発生率を低下させるだろう；セクション7.1を見 よ。 Klensin Standards Track [Page 71] RFC 2821 Simple Mail Transfer Protocol April 2001 When an MTA is being used in this way, it bears responsibility for ensuring that the message being transmitted is valid. The mechanisms for checking that validity, and for handling (or returning) messages that are not valid at the time of arrival, are part of the MUA-MTA interface and not covered by this specification. MTAがこの方法で利用されたとき、それは送出されたメッセージが有効である ことを確実にする責任を負う。有効性のチェックと到着時間が有効でないメッ セージの扱い(送り返し)のメカニズムは、MUA-MTAのインターフェイスの一部 であり、この標準の範囲ではない。 A submission protocol based on Standard RFC 822 information alone MUST NOT be used to gateway a message from a foreign (non-SMTP) mail system into an SMTP environment. Additional information to construct an envelope must come from some source in the other environment, whether supplemental headers or the foreign system's envelope. 標準RFC 822情報のみに基盤を置く提出プロトコルは、メッセージを外部の (SMTPでない)メールシステムからSMTP環境へとゲートウェイするのに用いては ならない(MUST NOT)。エンベロープを作成するための追加の情報は、追加のヘッ ダか外部システムのエンベロープといった別の環境のソースから来なければな らない。 Attempts to gateway messages using only their header "to" and "cc" fields have repeatedly caused mail loops and other behavior adverse to the proper functioning of the Internet mail environment. These problems have been especially common when the message originates from an Internet mailing list and is distributed into the foreign environment using envelope information. When these messages are then processed by a header-only remailer, loops back to the Internet environment (and the mailing list) are almost inevitable. ヘッダ"to:"と"cc:"フィールドのみを用いてメッセージをゲートウェイする試 みにより、メールループやその他インターネットメール環境の適切な機能に対 する不都合なふるまいがくり返し、引きおこされてきた。これらの問題は、特 にインターネットのメーリングリストからメッセージが送出され、エンベロー プ情報を用いて外部環境へと配送されたときによく見られる。これらのメッセー ジがヘッダだけのリメーラにより処理された時、インターネット環境(そして メーリングリスト)へのループバックはほとんど避けられない。 C. Source Routes ソースルーティング The is a reverse source routing list of hosts and a source mailbox. The first host in the SHOULD be the host sending the MAIL command. Similarly, the may be a source routing lists of hosts and a destination mailbox. However, in general, the SHOULD contain only a mailbox and domain name, relying on the domain name system to supply routing information if required. The use of source routes is deprecated; while servers MUST be prepared to receive and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT transmit them. はソースルーティングされたホストの逆向きのリストであり、 出所のメールボックスである。の最初のホストはMAILコマンド を送出したホストであるべきである(SHOULD)。類似して、は ソースルーティングされたホストのリストであり、あて先のメールボックスか もしれない。しかしながら、一般には1つのメールボックスと ドメイン名だけを含んでいるべきであり(SHOULD)、必要ならルーティング情報 を提供するのにDNSを信頼する。ソースルーティングの利用は良くないことで ある；サーバは受信し、セクション3.3とF.2で議論したように扱うための準備 をしなければならず(MUST)、クライアントはそれを送出すべきでない(SHOULD)。 For relay purposes, the forward-path may be a source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully- qualified domain names. This form is used to emphasize the distinction between an address and a route. The mailbox is an absolute address, and the route is information about how to get there. The two concepts should not be confused. リレーの目的で、forward-pathは"@ONE,@TWO:JOE@THREE"の形式のソースルー ティングかもしれない。ここでONE, TWO, THREEはFQDNでなければならない (MUST)。この形式はアドレスと経路の区別を強調するのに使われる。メールボッ クスは完全なアドレスであり、経路はそこへたどりつく方法の情報である。こ の2つの考えを混同すべきではない。 If source routes are used, RFC 821 and the text below should be consulted for the mechanisms for constructing and updating the forward- and reverse-paths. もしソースルーティングが使われるならば、RFC 821と下記のテキストを forward- と reverse-pathの生成とアップデートのメカニズムを参考とすべき である。 The SMTP server transforms the command arguments by moving its own identifier (its domain name or that of any domain for which it is acting as a mail exchanger), if it appears, from the forward-path to the beginning of the reverse-path. もし存在するならば、forward-pathからreverse-pathの最初へとそれ自身の識 別子(ドメイン名か、メールエクスチェンジャとして動作するドメイン)を動か すことで、SMTPサーバはコマンドの引数を送出する。 Klensin Standards Track [Page 72] RFC 2821 Simple Mail Transfer Protocol April 2001 Notice that the forward-path and reverse-path appear in the SMTP commands and replies, but not necessarily in the message. That is, there is no need for these paths and especially this syntax to appear in the "To:" , "From:", "CC:", etc. fields of the message header. Conversely, SMTP servers MUST NOT derive final message delivery information from message header fields. forward-pathとreverse-pathはSMTPコマンドと応答に現れるが、メッセージ中 には必要ではないことに注意。つまり、これらのパスは必要なく、特にメッセー ジヘッダの"To:","From:", "CC:"等のフィールドにこの構文が現れる必要はな い。逆に、SMTPサーバはメッセージヘッダフィールドから最終のメッセージ配 送に関する情報を持ってきてはならない(MUST NOT)。 When the list of hosts is present, it is a "reverse" source route and indicates that the mail was relayed through each host on the list (the first host in the list was the most recent relay). This list is used as a source route to return non-delivery notices to the sender. As each relay host adds itself to the beginning of the list, it MUST use its name as known in the transport environment to which it is relaying the mail rather than that of the transport environment from which the mail came (if they are different). ホストのリストが存在するとき、それは「逆の」ソースルーティングであり、 そのメールがリスト上のそれぞれのホストをリレーされて来たことを示す(リ スト中、最初のホストが最も新しいリレーである)。リストは、送り手に配送 不能のお知らせを返すのに、ソースルーティングとして使われる。それぞれの リレーホストはリストの最初に自分自身を追加するので、リレーホストは、 (もし異なるならば)メールが来た配送環境というよりメールをリレーする配送 環境で知られた名前を使わねばならない(MUST)。 D. Scenarios D. シナリオ This section presents complete scenarios of several types of SMTP sessions. In the examples, "C:" indicates what is said by the SMTP client, and "S:" indicates what is said by the SMTP server. このセクションではいくつかの型のSMTPセッションの完全なシナリオを示す。 例中、"C:"はSMTPクライアントが発言したことを示し、"S:"はSMTPサーバが発 言したことを示す。 D.1 A Typical SMTP Transaction Scenario D.1 典型的なSMTPトランザクションのシナリオ This SMTP example shows mail sent by Smith at host bar.com, to Jones, Green, and Brown at host foo.com. Here we assume that host bar.com contacts host foo.com directly. The mail is accepted for Jones and Brown. Green does not have a mailbox at host foo.com. このSMTPの例では、bar.com上のSmithがfoo.com上のJones, Green, Brownにメー ルを送ったものである。ここで、bar.comはfoo.comと直接接続できると仮定す る。メールはJonesとBrownによって受信される。Greenはfoo.com上にメールボッ クスを持たない。 S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: MAIL FROM: S: 250 OK C: RCPT TO: S: 250 OK C: RCPT TO: S: 550 No such user here C: RCPT TO: S: 250 OK C: DATA S: 354 Start mail input; end with . C: Blah blah blah... C: ...etc. etc. etc. Klensin Standards Track [Page 73] RFC 2821 Simple Mail Transfer Protocol April 2001 C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel D.2 Aborted SMTP Transaction Scenario D.2 中止されたSMTPトランザクションのシナリオ S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: MAIL FROM: S: 250 OK C: RCPT TO: S: 250 OK C: RCPT TO: S: 550 No such user here C: RSET S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel D.3 Relayed Mail Scenario D.3 リレーされたメールのシナリオ Step 1 -- Source Host to Relay Host Step 1 出所のホストからリレーホストへ S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: MAIL FROM: S: 250 OK C: RCPT TO:<@foo.com:Jones@XYZ.COM> S: 250 OK C: DATA S: 354 Start mail input; end with . C: Date: Thu, 21 May 1998 05:33:29 -0700 C: From: John Q. Public C: Subject: The Next Meeting of the Board C: To: Jones@xyz.com C: C: Bill: Klensin Standards Track [Page 74] RFC 2821 Simple Mail Transfer Protocol April 2001 C: The next meeting of the board of directors will be C: on Tuesday. C: John. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel Step 2 -- Relay Host to Destination Host Step 2 リレーホストから宛て先ホストへ S: 220 xyz.com Simple Mail Transfer Service Ready C: EHLO foo.com S: 250 xyz.com is on the air C: MAIL FROM:<@foo.com:JQP@bar.com> S: 250 OK C: RCPT TO: S: 250 OK C: DATA S: 354 Start mail input; end with . C: Received: from bar.com by foo.com ; Thu, 21 May 1998 C: 05:33:29 -0700 C: Date: Thu, 21 May 1998 05:33:22 -0700 C: From: John Q. Public C: Subject: The Next Meeting of the Board C: To: Jones@xyz.com C: C: Bill: C: The next meeting of the board of directors will be C: on Tuesday. C: John. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel D.4 Verifying and Sending Scenario D.4 確認して送信するシナリオ S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: VRFY Crispin S: 250 Mark Crispin C: SEND FROM: S: 250 OK Klensin Standards Track [Page 75] RFC 2821 Simple Mail Transfer Protocol April 2001 C: RCPT TO: S: 250 OK C: DATA S: 354 Start mail input; end with . C: Blah blah blah... C: ...etc. etc. etc. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel E. Other Gateway Issues E. その他のゲートウェイに関する問題 In general, gateways between the Internet and other mail systems SHOULD attempt to preserve any layering semantics across the boundaries between the two mail systems involved. Gateway- translation approaches that attempt to take shortcuts by mapping, (such as envelope information from one system to the message headers or body of another) have generally proven to be inadequate in important ways. Systems translating between environments that do not support both envelopes and headers and Internet mail must be written with the understanding that some information loss is almost inevitable. 一般に、インターネットと他のメールシステムの間のゲートウェイは、2つの メールシステムの境界を超えるとき、レイヤ化された意味論を保存することを 試みるべきである(SHOULD)。マッピング(1つのシステムのエンベロープの情報 をメッセージヘッダや別のボディに入れるなど)の近道の試みであるゲートウェ イでの変換のアプローチは一般に、重要な時に不適当であることが確認されて きた。エンベロープとヘッダ両方をサポートしない環境間の変換システムと、 インターネットメールは、いくぶんかの情報が失われることを理解の上で書か れなければならないことは、ほとんど避けられない。 F. Deprecated Features of RFC 821 F. 問題のあるRFC 821の特徴 A few features of RFC 821 have proven to be problematic and SHOULD NOT be used in Internet mail. RFC 821のいくつかの特徴は問題があることが確認され、インターネットメー ルでは利用すべきではない(SHOULD NOT)。 F.1 TURN F.1 TURN This command, described in RFC 821, raises important security issues since, in the absence of strong authentication of the host requesting that the client and server switch roles, it can easily be used to divert mail from its correct destination. Its use is deprecated; SMTP systems SHOULD NOT use it unless the server can authenticate the client. RFC 821に記されたこのコマンドは、ホストがクライアントとサーバが役割り を入れかえることを要求するのに強力な認証を欠くため、正しい宛て先からメー ルを転送するのに容易に使えることから、重要なセキュリティ上の問題を引き おこす。その利用は阻止される；SMTPシステムは、サーバがクライアントを認 証できるのでない限り、その利用をすべきでない(SHOULD NOT)。 F.2 Source Routing F.2 ソースルーティング RFC 821 utilized the concept of explicit source routing to get mail from one host to another via a series of relays. The requirement to utilize source routes in regular mail traffic was eliminated by the introduction of the domain name system "MX" record and the last significant justification for them was eliminated by the introduction, in RFC 1123, of a clear requirement that addresses following an "@" must all be fully-qualified domain names. Consequently, the only remaining justifications for the use of source Klensin Standards Track [Page 76] RFC 2821 Simple Mail Transfer Protocol April 2001 routes are support for very old SMTP clients or MUAs and in mail system debugging. They can, however, still be useful in the latter circumstance and for routing mail around serious, but temporary, problems such as problems with the relevant DNS records. RFC 821では1つのホストから別のホストへ、一連のリレーを通じてメールを得 るため、明確にソースルーティングの概念を利用している。正規のメールトラ フィックでソースルーティングを利用するという要求は、DNSの"MX"レコード の導入によりなくなり、また、それへの最後の重大な正当化がRFC1123における @に続くアドレスはFQDNでなければならないという、明確な要求事項により削 除された。続いて、ソースルーティングを利用する残った唯一の正当化は非常 に古いSMTPクライアントやMUAをサポートするためと、メールシステムのデバッ グのためである。にもかかわらず、後者の環境にとって容易ならないメールの ルーティングのため有用かもしれないが、しかし一時的には、DNSレコードと 関連するような問題になり得る。 SMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123. They MAY, if necessary, ignore the routes and utilize only the target domain in the address. If they do utilize the source route, the message MUST be sent to the first domain shown in the address. In particular, a server MUST NOT guess at shortcuts within the source route. SMTPサーバは本文書の主要部分とRFC 1123に規定したようにソースルーティン グの構文を受信しつづけなければならない(MUST)。必要なら、ルーティング情 報を無視してアドレス中の対象ドメインだけを利用してもよい(MAY)。 もしソースルーティングを利用するならば、メッセージはアドレスの最初のド メインへと送られなければならない(MUST)。特に、サーバはソースルーティン グ中のショートカットを推測してはならない(MUST NOT)。 Clients SHOULD NOT utilize explicit source routing except under unusual circumstances, such as debugging or potentially relaying around firewall or mail system configuration errors. クライアントは、デバッグやファイアウォールまわりの潜在的なリレーやメー ルシステムの設定エラーといった普通じゃない状況下を除き、明示的なソース ルーティングを利用すべきでない(SHOULD NOT)。 F.3 HELO F.3 HELO As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO when the server will accept the former. Servers must continue to accept and process HELO in order to support older clients. セクション3.1と4.1.1で議論したように、サーバが前者を受けいれるとき、 EHLOがHELOよりも強く好まれる。サーバは、古いクライアントをサポートする ためにHELOを受信し、処理しつづけなければならない。 F.4 #-literals F.4 #-リテラル RFC 821 provided for specifying an Internet address as a decimal integer host number prefixed by a pound sign, "#". In practice, that form has been obsolete since the introduction of TCP/IP. It is deprecated and MUST NOT be used. RFC 821では、ポンドサイン "#" を前置した十進整数のホスト番号とするイン ターネットアドレスの規定を提供していた。実際には、TCP/IPの導入によりこ の形式は時代遅れとなった。これは反対され、利用してはならない(MUST NOT)。 F.5 Dates and Years F.5 日付と年 When dates are inserted into messages by SMTP clients or servers (e.g., in trace fields), four-digit years MUST BE used. Two-digit years are deprecated; three-digit years were never permitted in the Internet mail system. SMTPクライアントやサーバによりメッセージに日付が挿入された時(例えば追 跡フィールド)、4桁の年が使われなければならない(MUST)。2桁の年は反対さ れた；3桁の年はインターネットメールシステムでは決して許可されない。 F.6 Sending versus Mailing F.6 送信すること対メール In addition to specifying a mechanism for delivering messages to user's mailboxes, RFC 821 provided additional, optional, commands to deliver messages directly to the user's terminal screen. These commands (SEND, SAML, SOML) were rarely implemented, and changes in workstation technology and the introduction of other protocols may have rendered them obsolete even where they are implemented. ユーザのメールボックスにメッセージを配信するためのメカニズムの規定に加 え、RFC 821は追加でオプションの、ユーザのターミナルスクリーンへと直接 メッセージを配送するコマンドを提供していた。これらのコマンド(SEND, SAML, SOML)はめったに実装されず、ワークステーションの技術が変わり、ま たたとえそれが実装されていたとしても、別のプロトコルの導入により時代遅 れとなっているかもしれない。 Klensin Standards Track [Page 77] RFC 2821 Simple Mail Transfer Protocol April 2001 Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers MAY implement them. If they are implemented by servers, the implementation model specified in RFC 821 MUST be used and the command names MUST be published in the response to the EHLO command. クライアントはSEND, SAML, SOMLをサービスとして提供すべきでない(SHOULD NOT)。サーバはそれらを実装してもよい。もしサーバに実装されるならば、 RFC 821に規定された実装モデルが使われ、コマンド名はEHLOコマンドへの応 答に書かれなければならない(MUST)。 Klensin Standards Track [Page 78] RFC 2821 Simple Mail Transfer Protocol April 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Klensin Standards Track [Page 79] ---- 訳について この訳は、美森勇気 が個人的な目的で行いました。利用 は自由ですが、一切の保証はしません。