[要約] RFC 4405は、電子メールメッセージの送信者を示すためのSMTPサービス拡張機能に関するものです。このRFCの目的は、電子メールの送信者情報を正確に識別し、信頼性を向上させることです。
Network Working Group E. Allman
Request for Comments: 4405 Sendmail, Inc.
Category: Experimental H. Katz
Microsoft Corp.
April 2006
SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message
電子メールメッセージの責任ある提出者を示すためのSMTPサービス拡張機能
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
IESG Note
IESGノート
The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such, these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group.
次のドキュメント（RFC 4405、RFC 4406、RFC 4407、およびRFC 4408）は、実験的なRFCとして同時に公開されていますが、2つのアプローチを再構成する一般的な技術的コンセンサスと努力は失敗しています。そのため、これらのドキュメントは完全なIETFレビューを受け取っておらず、マリドワーキンググループで考慮されたさまざまなアプローチを文書化するために「AS-IS」を公開されています。
The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them.
IESGは、どのアプローチが優先されるかについての立場を取り、読者に、それぞれのアプローチに重大なオープンな問題とそれらをタンデムで使用することに関する懸念があることを警告します。IESGは、異なるアプローチを文書化すると、それらを文書化しないよりも害が少ないと考えています。
Note that the Sender ID experiment may use DNS records that may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt.
送信者ID実験は、この一連の実験で現在のSPF実験または以前のバージョンに作成された可能性のあるDNSレコードを使用する場合があることに注意してください。レコードの内容に応じて、これは、送信者-IDヒューリスティックがメッセージに誤って適用されることを意味する場合があります。受信者がそれらのヒューリスティックに関連付けたアクションに応じて、メッセージは配信されないか、受領時に破棄される場合があります。
Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. Participants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict.
送信者ID実験DNSレコードに依存している参加者は、この一連の状況で有効なメッセージを失う可能性があると警告されています。SPF実験DNSレコードを公開する参加者は、RFC 4406のセクション3.4に記載されているアドバイスを検討する必要があり、競合を回避するためにV = SPF1とSPF2.0レコードの両方を公開することをお勧めします。
Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem.
Sender-ID実験の参加者は、res resting-*ヘッダーフィールドが使用される方法が、標準に準拠したシステム（特にresentを追加しないことで標準に準拠する自動転送業者に相互作用する際に正当な電子メールを受信できないことを認識する必要があります。*ヘッダー、およびRFC 822に準拠しているが、まだRFC 2822 Resent-* Semanticsを実装していないシステム。この相互運用性の問題を解決することなく、標準トラックで送信者-IDを前進させることは不適切です。
The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future.
コミュニティは、将来コミュニティのコンセンサスに到達できるように、出版後2年間の2つのアプローチの成功または失敗を観察するよう招待されています。
Abstract
概要
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain.
このメモは、SMTPクライアントが電子メールメッセージの責任ある送信者を指定できるようにするSimple Mail Transfer Protocol（SMTP）サービスの拡張機能を定義します。責任ある提出者は、トランスポートストリームにメッセージを導入する責任があるエンティティの電子メールアドレスです。この拡張機能は、電子メールサーバーを受信すると、SMTPクライアントが責任ある提出者のドメインに代わってメールを送信することを許可されているかどうかを効率的に判断するのに役立ちます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. The SUBMITTER Service Extension .................................4
3. The SUBMITTER Keyword of the EHLO Command .......................5
4. The SUBMITTER Parameter of the MAIL Command .....................5
4.1. Setting the SUBMITTER Parameter Value ......................5
4.2. Processing the SUBMITTER Parameter .........................5
4.3. Transmitting to a Non-SUBMITTER-Aware SMTP Server ..........6
5. Examples ........................................................6
5.1. Mail Submission ............................................7
5.2. Mail Forwarding ............................................7
5.3. Mobile User ................................................8
5.4. Guest E-Mail Service .......................................9
5.5. SUBMITTER Used on a Non-Delivery Report ...................11
6. Security Considerations ........................................11
7. Acknowledgements ...............................................12
8. IANA Considerations ............................................12
9. References .....................................................12
9.1. Normative References ......................................12
The practice of falsifying the identity of the sender of an e-mail message, commonly called "spoofing", is a prevalent tactic used by senders of unsolicited commercial e-mail, or "spam". This form of abuse has highlighted the need to improve identification of the "responsible submitter" of an e-mail message.
一般的に「スポーフィング」と呼ばれる電子メールメッセージの送信者の身元を偽造する慣行は、未承諾の商用電子メールまたは「スパム」の送信者が使用する一般的な戦術です。この形式の虐待は、電子メールメッセージの「責任のある提出者」の識別を改善する必要性を強調しています。
In this specification, the responsible submitter is the entity most recently responsible for injecting a message into the e-mail transport stream. The e-mail address of the responsible submitter will be referred to as the Purported Responsible Address (PRA) of the message. The Purported Responsible Domain (PRD) is the domain portion of that address.
この仕様では、責任ある提出者は、最近、電子メール輸送ストリームにメッセージを注入する責任があるエンティティです。責任ある提出者の電子メールアドレスは、メッセージの責任あるアドレス（PRA）と呼ばれます。主張された責任あるドメイン（PRD）は、そのアドレスのドメイン部分です。
This specification codifies rules for encoding the purported responsible address into the SMTP transport protocol. This will permit receiving SMTP servers to efficiently validate whether or not the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain.
この仕様は、責任者とされたアドレスをSMTP輸送プロトコルにエンコードするためのルールを成文化します。これにより、SMTPサーバーがSMTPクライアントが責任ある提出者のドメインに代わってメールを送信することを許可されているかどうかを効率的に検証できるようになります。
Broadly speaking, there are two possible approaches for determining the purported responsible address: either from RFC 2821 [SMTP] protocol data or from RFC 2822 [MSG-FORMAT] message headers. Each approach has certain advantages and disadvantages.
大まかに言えば、RFC 2821 [SMTP]プロトコルデータから、またはRFC 2822 [MSG-Format]メッセージヘッダーのいずれかから、責任あるアドレスを決定するための2つの可能なアプローチがあります。各アプローチには、特定の利点と短所があります。
Deriving the purported responsible domain from RFC 2821 data has the advantage that validation can be performed before the SMTP client has transmitted the message body. If spoofing is detected, then the SMTP server has the opportunity, depending upon local policy, to reject the message before it is ever transmitted. The disadvantage of this approach is the risk of false positives, that is, incorrectly concluding that the sender's e-mail address has been spoofed. There are today legitimate reasons why the Internet domain names used in RFC 2821 commands may be different from those of the sender of an e-mail message.
RFC 2821データから主張された責任あるドメインを導き出すことは、SMTPクライアントがメッセージ本文を送信する前に検証を実行できるという利点があります。スプーフィングが検出された場合、SMTPサーバーには、ローカルポリシーに応じて、メッセージが送信される前にメッセージを拒否する機会があります。このアプローチの欠点は、誤検知のリスクです。つまり、送信者の電子メールアドレスがスプーフィングされていると誤って結論付けています。今日、RFC 2821コマンドで使用されているインターネットドメイン名が電子メールメッセージの送信者とは異なる場合がある理由があります。
Deriving the purported responsible domain from RFC 2822 headers has the advantage that validation can usually be based on an identity that is displayed to recipients by existing Mail User Agents (MUAs) as the sender's identity. This aids in detection of a particularly noxious form of spoofing known as "phishing" in which a malicious sender attempts to fool a recipient into believing that a message originates from an entity well known to the recipient. This approach carries a lower risk of false positives since there are fewer legitimate reasons for RFC 2822 headers to differ from the true sender of the message. The disadvantage of this approach is that it does require parsing and analysis of message headers. In practice, much if not all the message body is also transmitted since the SMTP protocol described in RFC 2821 provides no mechanism to interrupt message transmission after the DATA command has been issued.
RFC 2822ヘッダーから主張された責任あるドメインを導き出すことは、通常、既存のメールユーザーエージェント（MUAS）が送信者のIDとして受信者に表示されるIDに基づいて検証が基づいているという利点があります。これは、「フィッシング」として知られるスプーフィングの特に有害な形態の検出に役立ちます。これは、悪意のある送信者が受信者をだまして、メッセージが受信者によく知られているエンティティから発生すると信じるようにしようとします。このアプローチは、RFC 2822ヘッダーがメッセージの真の送信者と異なるために正当な理由が少ないため、誤検知のリスクが低くなります。このアプローチの欠点は、メッセージヘッダーの解析と分析が必要であることです。実際には、RFC 2821で説明されているSMTPプロトコルがデータコマンドが発行された後にメッセージ送信を中断するメカニズムを提供しないため、すべてではないにしても、すべてのメッセージ本文も送信されます。
It is desirable to unify these two approaches in a way that combines the benefits of both while minimizing their respective disadvantages.
これらの2つのアプローチを、それぞれの欠点を最小限に抑えながら、両方の利点を組み合わせる方法で統一することが望ましいです。
This specification describes just such a unified approach. It uses the mechanism described in [SMTP] to describe an extension to the SMTP protocol. Using this extension, an SMTP client can specify the e-mail address of the entity most recently responsible for submitting the message to the SMTP client in a new SUBMITTER parameter of the SMTP MAIL command. SMTP servers can use this information to validate that the SMTP client is authorized to transmit e-mail on behalf of the Internet domain contained in the SUBMITTER parameter.
この仕様は、まさにそのような統一されたアプローチを説明しています。[SMTP]で説明されているメカニズムを使用して、SMTPプロトコルの拡張を記述します。この拡張機能を使用して、SMTPクライアントは、SMTP Mailコマンドの新しい提出者パラメーターでSMTPクライアントにメッセージを送信する責任があるエンティティの電子メールアドレスを指定できます。SMTPサーバーは、この情報を使用して、SMTPクライアントが送信者パラメーターに含まれるインターネットドメインに代わって電子メールを送信することを許可されていることを検証できます。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信された行を示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
The following SMTP service extension is hereby defined:
次のSMTPサービス拡張機能は、次のように定義されています。
(1) The name of this SMTP service extension is "Responsible Submitter";
(1) このSMTPサービス拡張機能の名前は「責任のある提出者」です。
(2) The EHLO keyword value associated with this extension is "SUBMITTER";
(2) この拡張機能に関連付けられているEhloキーワード値は「送信者」です。
(3) The SUBMITTER keyword has no parameters;
(3) 送信者キーワードにはパラメーターがありません。
(4) No additional SMTP verbs are defined by this extension;
(4) この拡張機能によって追加のSMTP動詞は定義されていません。
(5) An optional parameter is added to the MAIL command using the esmtp-keyword "SUBMITTER", and is used to specify the e-mail address of the entity responsible for submitting the message for delivery;
(5) esmtp-keyword "submitter"を使用してオプションのパラメーターがメールコマンドに追加され、配信のメッセージを送信する責任者の電子メールアドレスを指定するために使用されます。
(6) This extension is appropriate for the submission protocol [SUBMIT].
(6) この拡張機能は、送信プロトコル[送信]に適しています。
An SMTP server includes the SUBMITTER keyword in its EHLO response to tell the SMTP client that the SUBMITTER service extension is supported.
SMTPサーバーには、EHLO応答に送信者キーワードが含まれており、SMTPクライアントに送信者サービス拡張機能がサポートされていることを伝えます。
The SUBMITTER keyword has no parameters.
送信者キーワードにはパラメーターがありません。
The syntax of the SUBMITTER parameter is
送信者パラメーターの構文はです
"SUBMITTER=" Mailbox
"submitter ="メールボックス
where Mailbox is the Augmented Backus-Naur Form (ABNF) [ABNF] production defined in Section 4.1.2 of [SMTP]. Characters such as SP, "+", and "=" that may occur in Mailbox but are not permitted in ESMTP parameter values MUST be encoded as "xtext" as described in Section 4 of [DSN].
ここで、メールボックスは、[SMTP]のセクション4.1.2で定義されている拡張されたBackus-Naurフォーム（ABNF）[ABNF]生産です。[dsn]のセクション4で説明されているように、sp、 "、"、 "、" = "などの文字は、eSMTPパラメーター値では許可されていません。
The purpose of the SUBMITTER parameter is to allow the SMTP client to indicate to the server the purported responsible address of the message directly in the RFC 2821 protocol.
送信者パラメーターの目的は、SMTPクライアントがRFC 2821プロトコルで直接メッセージの責任アドレスをサーバーに指定できるようにすることです。
Therefore, SMTP clients that support the Responsible Submitter extension MUST include the SUBMITTER parameter on all messages. This includes messages containing a null reverse-path in the MAIL command.
したがって、責任ある送信者拡張機能をサポートするSMTPクライアントには、すべてのメッセージに送信者パラメーターを含める必要があります。これには、メールコマンドにヌルリバースパスを含むメッセージが含まれます。
SMTP clients MUST set the SUBMITTER parameter value to the purported responsible address of the message as defined in [PRA]. This also applies to messages containing a null reverse-path.
SMTPクライアントは、[PRA]で定義されているように、メッセージの責任あるアドレスに送信者パラメーター値を設定する必要があります。これは、ヌルの逆パスを含むメッセージにも適用されます。
In some circumstances, described in Section 7 of [SENDER-ID], SMTP clients may need to add RFC 2822 headers to the message in order to ensure that the correct SUBMITTER parameter value can be set.
[Sender-ID]のセクション7で説明されている状況によっては、SMTPクライアントは、正しい送信者パラメーター値を設定できるようにするために、RFC 2822ヘッダーをメッセージに追加する必要がある場合があります。
Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD select the domain part of the SUBMITTER address value as the purported responsible domain of the message, and SHOULD perform such tests, including those defined in [SENDER-ID], as are deemed necessary to determine whether the connecting SMTP client is authorized to transmit e-mail messages on behalf of that domain.
送信者パラメーターで送信された電子メールメッセージの受信者は、メッセージの責任あるドメインとされる責任あるドメインとして送信者アドレス値のドメイン部分を選択し、必要と思われる[Sender-ID]で定義されたものを含むそのようなテストを実行する必要があります。接続するSMTPクライアントが、そのドメインに代わって電子メールメッセージを送信することを許可されているかどうかを判断します。
If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed."
これらのテストが、接続するSMTPクライアントが送信者ドメインに代わって電子メールメッセージを送信することを許可されていないことを示している場合、受信SMTPサーバーはメッセージを拒否する必要があり、拒否する場合は「550 5.7.1提出者が許可されていない」を使用する必要があります。
If the receiving SMTP server allows the connecting SMTP client to transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message headers as described in [PRA]. If this purported responsible address does not match the address appearing in the SUBMITTER parameter, the receiving SMTP server MUST reject the message and when rejecting MUST use "550 5.7.1 Submitter does not match header."
受信SMTPサーバーが接続するSMTPクライアントがメッセージデータを送信できる場合、サーバーは[PRA]で説明されているRFC 2822メッセージヘッダーを調べることにより、メッセージの責任あるアドレスを決定する必要があります。この責任あるアドレスが送信者パラメーターに表示されるアドレスと一致しない場合、受信SMTPサーバーはメッセージを拒否する必要があり、拒否する場合は「550 5.7.1提出者はヘッダーと一致しません」を使用する必要があります。
If no purported responsible address is found according to the procedure defined in [PRA], the SMTP server SHOULD reject the message and when rejecting MUST use "554 5.7.7 Cannot verify submitter address."
[PRA]で定義されている手順に従って責任のあるアドレスが見つからない場合、SMTPサーバーはメッセージを拒否する必要があり、拒否する場合は「554 5.7.7は送信者アドレスを確認できません」を使用する必要があります。
Verifying Mail Transfer Agents (MTAs) are strongly urged to validate the SUBMITTER parameter against the RFC 2822 headers; otherwise, an attacker can trivially defeat the algorithm.
メール転送エージェント（MTA）の検証は、RFC 2822ヘッダーに対する提出者パラメーターを検証することを強く求められます。それ以外の場合、攻撃者はアルゴリズムを簡単に倒すことができます。
Note that the presence of the SUBMITTER parameter on the MAIL command MUST NOT change the effective reverse-path of a message. Any delivery status notifications must be sent to the reverse-path, if one exists, as per Section 3.7 of [SMTP] regardless of the presence of a SUBMITTER parameter. If the reverse-path is null, delivery status notifications MUST NOT be sent to the SUBMITTER address.
メールコマンドに送信者パラメーターが存在することは、メッセージの効果的な逆パスを変更してはならないことに注意してください。提出者パラメーターの存在に関係なく、[SMTP]のセクション3.7に従って、存在する場合は、配信ステータス通知をリバースパスに送信する必要があります。リバースパスがnullの場合、配信ステータス通知を提出者アドレスに送信してはなりません。
Likewise, the SUBMITTER parameter MUST NOT change the effective reply address of a message. Replies MUST be sent to the From address or the Reply-To address, if present, as described in Section 3.6.2 of [MSG-FORMAT] regardless of the presence of a SUBMITTER parameter.
同様に、送信者パラメーターは、メッセージの効果的な返信アドレスを変更してはなりません。提出者パラメーターの存在に関係なく、[MSG-Format]のセクション3.6.2で説明されているように、存在する場合は、存在する場合は、fromアドレスまたは返信者に返信する必要があります。
Notwithstanding the provisions of Section 4.1 above, when an MTA transmits a message to another MTA that does not support the SUBMITTER extension, the forwarding MTA MUST transmit the message without the SUBMITTER parameter. This should involve no information loss, since the SUBMITTER parameter is required to contain information derived from the message headers.
上記のセクション4.1の規定にもかかわらず、MTAが送信者拡張機能をサポートしていない別のMTAにメッセージを送信する場合、転送MTAは送信者パラメーターなしでメッセージを送信する必要があります。送信者パラメーターはメッセージヘッダーから派生した情報を含める必要があるため、これには情報の損失は含まれません。
This section provides examples of how the SUBMITTER parameter would be used. The following dramatis personae appear in the examples: alice@example.com: the original sender of each e-mail message.
このセクションでは、提出者パラメーターがどのように使用されるかの例を示します。次のDramatis Personaeが例に掲載されています：alice@example.com：各電子メールメッセージの元の送信者。
bob@company.com.example: the final recipient of each e-mail.
bob@company.com.example：各電子メールの最終受信者。
bob@almamater.edu.example: an e-mail address used by Bob that he has configured to forward mail to his office account at bob@company.com.example.
bob@almamater.edu.example：bob@company.com.exampleのオフィスアカウントにメールを転送するように構成したBobが使用した電子メールアドレス。
alice@mobile.net.example: an e-mail account provided to Alice by her mobile e-mail network carrier.
alice@mobile.net.example：モバイル電子メールネットワークキャリアによってAliceに提供される電子メールアカウント。
Under normal circumstances, Alice would configure her MUA to submit her message to the mail system using the SUBMIT protocol [SUBMIT]. The MUA would transmit the message without the SUBMITTER parameter. The SUBMIT server would validate that the MUA is allowed to submit a message through some external scheme, perhaps SMTP Authentication [SMTPAUTH]. Under most circumstances, this would look like a normal, authenticated SMTP transaction. The SUBMIT server would extract her name from the RFC 2822 headers for use in the SUBMITTER parameters of subsequent transmissions of the message.
通常の状況では、アリスは彼女のMUAを設定して、送信プロトコル[送信]を使用してメールシステムにメッセージを送信します。MUAは、送信者パラメーターなしでメッセージを送信します。送信サーバーは、MUAが何らかの外部スキーム、おそらくSMTP認証[SMTPAUTH]を介してメッセージを送信できることを検証します。ほとんどの場合、これは通常の認証されたSMTPトランザクションのように見えます。送信サーバーは、メッセージの後続の送信の送信者パラメーターで使用するために、RFC 2822ヘッダーから彼女の名前を抽出します。
When Alice sends a message to Bob at his almamater.edu.example account, the SMTP session from her SUBMIT server might look something like this:
アリスが彼のalmamater.edu.exampleアカウントでボブにメッセージを送信すると、彼女の送信サーバーからのSMTPセッションは次のようになるかもしれません：
S: 220 almamater.edu.example ESMTP server ready
C: EHLO example.com
S: 250-almamater.edu.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com> SUBMITTER=alice@example.com
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@almamater.edu.example>
S: 250 <bob@almamater.edu.example> recipient ok
C: DATA
S: 354 okay, send message
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
The almamater.edu.example MTA must now forward this message to bob@company.com.example. Although the original sender of the message is alice@example.com, Alice is not responsible for this most recent retransmission of the message. That role is filled by bob@almamater.edu.example, who established the forwarding of mail to bob@company.com.example. Therefore, the almamater.edu.example MTA determines a new purported responsible address for the message, namely, bob@almamater.edu.example, and sets the SUBMITTER parameter accordingly. The forwarding MTA also inserts a Resent-From header in the message body to ensure the purported responsible address derived from the RFC 2822 headers matches the SUBMITTER address.
almamater.edu.example MTAは、このメッセージをbob@company.com.exampleに転送する必要があります。メッセージの元の送信者はalice@example.comですが、アリスはメッセージのこの最新の再送信について責任を負いません。その役割はbob@almamater.edu.exampleによって記入されています。したがって、almamater.edu.example Mtaは、メッセージの新しい責任アドレス、つまりbob@almamater.edu.exampleを決定し、それに応じて送信者パラメーターを設定します。また、転送MTAはメッセージ本文にヘッダーからresったヘッダーを挿入して、RFC 2822ヘッダーから派生した責任あるアドレスが送信者アドレスに一致するようにします。
S: 220 company.com.example ESMTP server ready
C: EHLO almamater.edu.example
S: 250-company.com.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com>
SUBMITTER=bob@almamater.edu.example
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@company.com.example>
S: 250 <bob@company.com.example> recipient ok
C: DATA
S: 354 okay, send message
C: Resent-From: bob@almamater.edu.example
C: Received By: ...
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
Alice is at the airport and uses her mobile e-mail device to send a message to Bob. The message travels through the carrier network provided by mobile.net.example, but Alice uses her example.com address on the From line of all her messages so that replies go to her office mailbox.
アリスは空港にいて、モバイル電子メールデバイスを使用してボブにメッセージを送信します。このメッセージは、mobile.net.exampleが提供するキャリアネットワークを介して移動しますが、アリスはすべてのメッセージのラインでexample.comアドレスを使用して、返信がオフィスメールボックスに送られるようにします。
Here is an example of the SMTP session between the MTAs at mobile.net.example and almamater.edu.example.
mobile.net.exampleとalmamater.edu.exampleのMTAS間のSMTPセッションの例を次に示します。
S: 220 almamater.edu.example ESMTP server ready
C: EHLO mobile.net.example
S: 250-almamater.edu.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com>
SUBMITTER=alice@mobile.net.example
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@almamater.edu.example>
S: 250 <bob@almamater.edu.example> recipient ok
C: DATA
S: 354 okay, send message
C: Sender: alice@mobile.net.example
C: Received By: ...
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
Note that mobile.net.example uses the SUBMITTER parameter to designate alice@mobile.net.example as the responsible submitter for this message. Further, this MTA also inserts a Sender header to ensure the purported responsible address derived from the RFC 2822 headers matches the SUBMITTER address.
mobile.net.exampleは、送信者パラメーターを使用して、alice@mobile.net.exampleをこのメッセージの責任ある送信者として指定することに注意してください。さらに、このMTAは、送信者ヘッダーを挿入して、RFC 2822ヘッダーから派生した責任あるアドレスが送信者アドレスに一致するようにします。
Likewise, conventional ISPs may also choose to use the SUBMITTER parameter to designate as the responsible submitter the user's address on the ISP's network if that address is different from the MAIL FROM address. This may be especially useful for ISPs that host multiple domains or otherwise share MTAs among multiple domains.
同様に、従来のISPは、そのアドレスがアドレスからメールとは異なる場合、責任者の提出者としてISPのネットワーク上のユーザーのアドレスを責任ある提出者として指定することを選択する場合があります。これは、複数のドメインをホストしたり、複数のドメイン間でMTAを共有したりするISPに特に役立ちます。
When the message is subsequently forwarded by the almamater.edu.example MTA, that MTA will replace the SUBMITTER parameter with bob@almamater.edu.example as in Section 5.2 and add its own Resent-From header.
その後、メッセージがalmamater.edu.example MTAによって転送されると、そのMTAはセクション5.2のようにbob@almamater.edu.exampleに送信者パラメーターを置き換え、ヘッダーから独自のresentを追加します。
While on a business trip, Alice uses the broadband access facilities provided by the Exemplar Hotel to connect to the Internet and send e-mail. The hotel routes all outbound e-mail through its own SMTP server, email.hotel.com.example.
出張中に、アリスはExemplar Hotelが提供するブロードバンドアクセス設備を使用して、インターネットに接続して電子メールを送信します。ホテルは、独自のSMTPサーバー、email.hotel.com.exampleを介してすべてのアウトバウンド電子メールをルーティングします。
The SMTP session for Alice's message to Bob from the Exemplar Hotel would look like this:
Exemplar HotelのBobへのAliceのメッセージのSMTPセッションは、次のようになります。
S: 220 almamater.edu.example ESMTP server ready
C: EHLO email.hotel.com.example
S: 250-almamater.edu.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com>
SUBMITTER=guest.services@email.hotel.com.example
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@almamater.edu.example>
S: 250 <bob@almamater.edu.example> recipient ok
C: DATA
S: 354 okay, send message
C: Resent-From: guest.services@email.hotel.com.example
C: Received By: ...
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
Note that email.hotel.com.example uses the SUBMITTER parameter to designate a generic account guest.services@email.hotel.com.example as the responsible submitter address for this message. A generic account is used since Alice herself does not have an account at that domain. Furthermore, this client also inserts a Resent-From header to ensure the purported responsible address derived from the RFC 2822 headers with the SUBMITTER address.
email.hotel.com.exampleは、送信者パラメーターを使用して、一般的なアカウントguest.services@email.hotel.com.exampleをこのメッセージの責任ある提出者アドレスとして指定することに注意してください。アリス自身がそのドメインにアカウントを持っていないため、一般的なアカウントが使用されます。さらに、このクライアントは、RFC 2822ヘッダーから派生した責任あるアドレスを提出者アドレスで確保するために、ヘッダーからresったresティを挿入します。
As before, when the message is subsequently forwarded by the almamater.edu.example MTA, that MTA will replace the SUBMITTER parameter with bob@almamater.edu.example as in Section 5.2 and add its own Resent-From header.
前と同様に、メッセージがその後almamater.edu.example MTAによって転送されると、そのMTAはセクション5.2のようにbob@almamater.edu.exampleに送信者パラメーターを置き換え、ヘッダーから独自のresを追加します。
Alice sends an incorrectly addressed e-mail message and receives a non-delivery report from a SUBMITTER-compliant server.
アリスは、誤ってアドレス指定された電子メールメッセージを送信し、送信者に準拠したサーバーから配信のないレポートを受け取ります。
S: 220 example.com ESMTP server ready
C: EHLO almamater.edu.example
S: 250-example.com
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<> SUBMITTER=mailer-daemon@almamater.edu.example
S: 250 OK
C: RCPT TO:<alice@example.com>
S: 250 OK
C: DATA
S: 354 OK, send message
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
This extension provides an optimization to allow an SMTP client to identify the responsible submitter of an e-mail message in the SMTP protocol, and to enable SMTP servers to perform efficient validation of that identity before the message contents are transmitted.
この拡張機能は、SMTPクライアントがSMTPプロトコルの電子メールメッセージの責任ある提出者を識別できるようにし、メッセージ内容が送信される前にSMTPサーバーがそのアイデンティティの効率的な検証を実行できるようにする最適化を提供します。
It is, however, quite possible for an attacker to forge the value of the SUBMITTER parameter. Furthermore, it is possible for an attacker to transmit an e-mail message whose SUBMITTER parameter does not match the purported responsible address of the message as derived from the RFC 2822 headers. Therefore, the presence of the SUBMITTER parameter provides, by itself, no assurance of the authenticity of the message or the responsible submitter. Rather, the SUBMITTER parameter is intended to provide additional information to receiving e-mail systems to enable them to efficiently determine the validity of the responsible submitter, and specifically, whether the SMTP client is authorized to transmit e-mail on behalf of the purported responsible submitter's domain. Section 4.2 describes how receiving e-mail systems should process the SUBMITTER parameter.
ただし、攻撃者が提出者パラメーターの値を偽造することは非常に可能です。さらに、攻撃者は、RFC 2822ヘッダーから派生したメッセージの責任あるアドレスと提出者パラメーターが一致しない電子メールメッセージを送信することができます。したがって、送信者パラメーターの存在は、それ自体で、メッセージまたは責任ある提出者の信頼性の保証を提供しません。むしろ、提出者パラメーターは、責任ある提出者の有効性を効率的に決定できるように、電子メールシステムを受信するための追加情報を提供することを目的としています。提出者のドメイン。セクション4.2では、電子メールシステムの受信が提出者パラメーターをどのように処理するかについて説明します。
The idea of an ESMTP extension to convey the identity of the responsible sender of an e-mail message has many progenitors. Nick Shelness suggested the idea in a private conversation with one of the authors. Pete Resnick suggested a variant on the MARID mailing list. The idea was also discussed on the Anti-Spam Research Group (ASRG) mailing list.
電子メールメッセージの責任ある送信者の身元を伝えるためのESMTP拡張のアイデアには、多くの先祖があります。ニック・シェルネスは、著者の一人とのプライベートな会話でこのアイデアを提案しました。ピート・レストニックは、マリドのメーリングリストにバリアントを提案しました。このアイデアは、アンチスパム研究グループ（ASRG）メーリングリストについても議論しました。
The authors would also like to thank the participants of the MARID working group and the following individuals for their comments and suggestions, which greatly improved this document:
著者はまた、マリドワーキンググループの参加者と次の個人にコメントと提案に感謝したいと思います。これにより、このドキュメントが大幅に改善されました。
Robert Atkinson, Simon Attwell, Roy Badami, Greg Connor, Dave Crocker, Matthew Elvey, Tony Finch, Ned Freed, Mark Lentczner, Jim Lyon, Bruce McMillan, Sam Neely, Daryl Odnert, Margaret Olson, Pete Resnick, Hector Santos, Nick Shelness, Rand Wacker, and Meng Weng Wong.
ロバート・アトキンソン、サイモン・アトウェル、ロイ・バダミ、グレッグ・コナー、デイブ・クロッカー、マシュー・エルベイ、トニー・フィンチ、ネッド・フリード、マーク・レンツナー、ジム・リヨン、ブルース・マクミラン、サム・ニーリー、ダリル・オドナート、マーガレット・オルソン、ピート・レスニック、ヘクター・サントス、ニック・シェルネス、ランド・ワッカー、メン・ウェン・ウォン。
The IANA has registered the SUBMITTER SMTP service extension.
IANAは、提出者SMTPサービス拡張機能を登録しました。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN] Moore、K。、「配送ステータス通知（DSNS）のSimple Mail Transfer Protocol（SMTP）サービス拡張」、RFC 3461、2003年1月。
[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月。
[MSG-FORMAT] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[MSG-Format] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[PRA] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[PRA] Lyon、J。、「電子メールメッセージの責任ある住所」、RFC 4407、2006年4月。
[SENDER-ID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[Sender-Id] Lyon、J。およびM. Wong、「送信者ID：認証電子メール」、RFC 4406、2006年4月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[送信] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTPAUTH] Myers、J。、「認証のためのSMTPサービス拡張」、RFC 2554、1999年3月。
Authors' Addresses
著者のアドレス
Eric Allman Sendmail, Inc. 6425 Christie Ave, Suite 400 Emeryville, CA 94608 USA
Eric Allman Sendmail、Inc。6425 Christie Ave、Suite 400 Emeryville、CA 94608 USA
EMail: eric@sendmail.com
Harry Katz Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA
Harry Katz Microsoft Corp. 1 Microsoft Way Redmond、WA 98052 USA
EMail: hkatz@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。