RFC4405 日本語訳

Network Working Group                                          E. Allman
Request for Comments: 4405                                Sendmail, Inc.
Category: Experimental                                           H. Katz
                                                         Microsoft Corp.
                                                              April 2006

コメントを求めるワーキンググループE.オールマン要求をネットワークでつないでください: 4405年のセンドメールInc.カテゴリ: 実験的なH.キャッツMicrosoft Corp.2006年4月

                       SMTP Service Extension for
       Indicating the Responsible Submitter of an E-Mail Message

メールメッセージの責任があるSubmitterを示すための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.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(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.

以下のドキュメント(RFC4405、RFC4406、RFC4407、およびRFC4408)は同時にExperimental RFCsとして発表されます、どんな一般的な技術的なコンセンサスもありません、そして、2つのアプローチを和解させるための努力は失敗しましたが。 そういうものとして、これらのドキュメントは、完全なIETFレビューを受け取っていなくて、それらがMARIDワーキンググループで考えられたとき異なるアプローチを記録するために「そのままで」発表されます。

   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は、好まれるアプローチがことである立場を全く取らないで、各アプローチのための重大な未解決の問題と2人乗り自転車でそれらを使用することに関する心配があると読者に警告します。 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.

Sender ID実験がこのセットの実験に現在のSPF実験か以前のバージョンのために作成されたかもしれないDNS記録を使用するかもしれないことに注意してください。 記録の内容によって、これは、Sender-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

Sender ID実験DNS記録を当てにする関係者はこのセットの事情の有効なメッセージを失うかもしれないのに注意されます。 SPF実験DNS記録を発表する関係者は考えるべきです。

Allman & Katz                 Experimental                      [Page 1]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[1ページ]RFC4405SMTP

   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.

アドバイスは、RFC4406のセクション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実験の関係者は、規格対応することのシステム(Resent-*ヘッダー、およびRFC822に従うシステムを加えないことによって規格に従いますが、まだRFC2822Resent-*意味論を実行していない明確に自動である混載業者)と対話するとき、正統のメールを受け取るためにResent-*ヘッダーフィールドが使用されている方法が失敗に終わるのを意識している必要があります。 標準化過程の上でこの相互運用性問題を解決しないでSender-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クライアントがメールメッセージの責任があるsubmitterを指定できるシンプルメールトランスファプロトコル(SMTP)サービスと拡大を定義します。 責任があるsubmitterはごく最近輸送の流れにメッセージを取り入れるのに原因となる実体のEメールアドレスです。 この拡張子は、SMTPクライアントが責任があるsubmitterのドメインを代表してメールを伝えるのに権限を与えられるか否かに関係なく、サーバが効率的に決定するメールを受け取るのを助けます。

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

1. 序論…3 1.1. このドキュメントで中古のコンベンション…4 2. SUBMITTERは拡大を修理します…4 3. EHLOコマンドに関するSUBMITTERキーワード…5 4. メールコマンドのSUBMITTERパラメタ…5 4.1. SUBMITTERパラメタ価値を設定します…5 4.2. SUBMITTERパラメタを処理します…5 4.3. aに伝わる、非SUBMITTER意識する、SMTPサーバ…6 5. 例…6 5.1. 服従を郵送してください…7 5.2. 推進を郵送してください…7 5.3. モバイルユーザ…8 5.4. 客メールサービス…9 5.5. 非配送のときに使用されたSUBMITTERは報告します…11 6. セキュリティ問題…11 7. 承認…12 8. IANA問題…12 9. 参照…12 9.1. 標準の参照…12

Allman & Katz                 Experimental                      [Page 2]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[2ページ]RFC4405SMTP

1.  Introduction

1. 序論

   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.

メールメッセージの送付者のアイデンティティを改竄する一般的に「スプーフィング」と呼ばれた習慣は勝手に送り付けてくる商業用電子メールの送付者、または「スパム」によって使用される一般的な戦術です。 この形式の乱用はメールメッセージの「責任があるsubmitter」の識別を改良する必要性を強調しました。

   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.

この仕様では、責任があるsubmitterはごく最近メール輸送ストリームにメッセージを注ぐのに原因となる実体です。 責任があるsubmitterのEメールアドレスはメッセージのPurported Responsible Address(PRA)と呼ばれるでしょう。 Purported Responsible Domain(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クライアントが責任があるsubmitterのドメインを代表してメールを伝えるのに権限を与えられるか否かに関係なく、効率的に有効にする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.

概して、主張された原因となるアドレスを決定するための2つの可能なアプローチがあります: RFC2821[SMTP]プロトコルデータかRFC2822[エムエスジー-FORMAT]メッセージヘッダーから。 各アプローチには、ある利点と損失があります。

   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から主張された原因となるドメインを合法化が利点であるかもしれませんが、SMTPクライアントがメッセージ本体を伝える前に実行されて、2821のデータにはある得ること。 スプーフィングが検出されるなら、SMTPサーバーには、機会があります、それが今までに伝えられる前にメッセージを拒絶するためにローカルの方針によって。 このアプローチの不都合が無病誤診のリスクである、それはそうです、送付者のEメールアドレスがだまされたと不当に結論を下して。 今日、RFC2821コマンドに使用されるインターネットドメイン名が電子メール・メッセージの送付者のものと異なるかもしれないもっともな理由があります。

   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,

RFCから主張された原因となるドメインを得て、2822個のヘッダーには送付者のアイデンティティとして既存のメール・ユーザー・エージェント(MUAs)で通常、合法化が受取人に表示されるアイデンティティに基づいたそうであることができる利点があります。 これは悪意がある送付者が受取人が、メッセージが受取人にとって、よく知られている実体から発すると信じているようにだますのを試みる「フィッシング詐欺」として知られている特に有害な形式のスプーフィングの検出で支援されます。 RFCには、より少ないもっともな理由があるので、このアプローチは無病誤診の下側の危険を伴います。メッセージの本当の送付者と異なる2822個のヘッダー。 このアプローチの不都合はメッセージヘッダーの構文解析と分析を必要とするということです。 実際には

Allman & Katz                 Experimental                      [Page 3]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[3ページ]RFC4405SMTP

   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.

また、RFC2821で説明されたSMTPプロトコルがDATAコマンドを発行した後にメッセージ送信を中断するためにメカニズムを全く提供しないので、多くかすべてのメッセージ本体が伝えられます。

   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コマンドの新しいSUBMITTERパラメタのSMTPクライアントにメッセージを提出するのに原因となる実体のEメールアドレスを指定できます。 SMTPサーバーはそれを有効にするために、SMTPクライアントがSUBMITTERパラメタに含まれたインターネットドメインを代表してメールを伝えるのに権限を与えられるというこの情報を使用できます。

1.1.  Conventions Used in This Document

1.1. 本書では使用されるコンベンション

   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].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?

2.  The SUBMITTER Service Extension

2. SUBMITTERサービス拡張子

   The following SMTP service extension is hereby defined:

以下のSMTPサービス拡張子はこれにより定義されます:

   (1)  The name of this SMTP service extension is "Responsible
        Submitter";

(1) このSMTPサービス拡張子の名前は「責任があるSubmitter」です。

   (2)  The EHLO keyword value associated with this extension is
        "SUBMITTER";

(2) この拡大に関連しているEHLOキーワード価値は"SUBMITTER"です。

   (3)  The SUBMITTER keyword has no parameters;

(3) SUBMITTERキーワードには、パラメタが全くありません。

   (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) 任意のパラメタは、"SUBMITTER"というesmtp-キーワードを使用することでメールコマンドに追加されて、配送へのメッセージを提出するのに原因となる実体のEメールアドレスを指定するのに使用されます。

   (6)  This extension is appropriate for the submission protocol
        [SUBMIT].

(6) 服従プロトコル[SUBMIT]に、この拡大は適切です。

Allman & Katz                 Experimental                      [Page 4]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[4ページ]RFC4405SMTP

3.  The SUBMITTER Keyword of the EHLO Command

3. EHLOコマンドに関するSUBMITTERキーワード

   An SMTP server includes the SUBMITTER keyword in its EHLO response to
   tell the SMTP client that the SUBMITTER service extension is
   supported.

SMTPサーバーは、SUBMITTERサービス拡張子がサポートされるとSMTPクライアントに言うためにEHLO応答にSUBMITTERキーワードを含んでいます。

   The SUBMITTER keyword has no parameters.

SUBMITTERキーワードには、パラメタが全くありません。

4.  The SUBMITTER Parameter of the MAIL Command

4. メールコマンドのSUBMITTERパラメタ

   The syntax of the SUBMITTER parameter is

SUBMITTERパラメタの構文はそうです。

      "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].

MailboxがAugmented BN記法(ABNF)[ABNF]であるところでは、生産はセクション4.1で.2[SMTP]を定義しました。 [DSN]のセクション4で説明される"xtext"としてメールボックスの中に起こるかもしれませんが、ESMTPパラメタ値では受入れられないSPや、「+」や、「=」などのキャラクターをコード化しなければなりません。

4.1.  Setting the SUBMITTER Parameter Value

4.1. SUBMITTERパラメタ価値を設定します。

   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.

SUBMITTERパラメタの目的はSMTPクライアントが直接RFC2821プロトコルのメッセージの主張された原因となるアドレスをサーバに示すのを許容することです。

   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.

したがって、Responsible Submitter拡張子をサポートするSMTPクライアントはすべてのメッセージに関するSUBMITTERパラメタを入れなければなりません。 これはメールコマンドにおける逆経路のヌルを含むメッセージを含んでいます。

   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]で定義されるようにメッセージの主張された原因となるアドレスにSUBMITTERパラメタ価値を設定しなければなりません。 また、これはヌル逆経路を含むメッセージに適用されます。

   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.

SMTPクライアントが[SENDER-ID]のセクション7で説明されて、そうする事情がそうしなければならないいくつかでは、RFCを加えるために、正しいSUBMITTERパラメタ価値がそれを確実にするためにあることができるというメッセージへの2822個のヘッダーがセットしました。

4.2.  Processing the SUBMITTER Parameter

4.2. SUBMITTERパラメタを処理します。

   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.

SUBMITTERパラメタSHOULDで送られたメールメッセージの受信機はメッセージの主張された原因となるドメインとしてSUBMITTERアドレス値のドメイン部分を選定します、そして、SHOULDはそのようなテストを実行します、[SENDER-ID]で定義されたものを含んでいて、接続SMTPクライアントがそのドメインを代表してメールメッセージを送るのに権限を与えられるかどうか決定するのに必要であると考えられるように。

Allman & Katz                 Experimental                      [Page 5]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[5ページ]RFC4405SMTP

   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クライアントがSUBMITTERドメインを代表してメールメッセージを送るのに権限を与えられないで、受信SMTPサーバーSHOULDがメッセージを拒絶するのを示して、拒絶が「.1Submitterが許容しなかった550 5.7」を使用しなければならないと。

   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サーバーでメッセージデータを送ることができるなら、サーバSHOULDは[PRA]で説明されるように2822がヘッダーを通信させるというRFCを調べるのによるメッセージの主張された原因となるアドレスを決定します。 この主張された原因となるアドレスがSUBMITTERパラメタに現れるアドレスに合っていないなら、受信SMTPサーバーはメッセージを拒絶しなければなりません、そして、拒絶が使用されなければならないとき、「550 5.7 .1Submitterはヘッダーに合いません」。

   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サーバーSHOULDはメッセージを拒絶します、そして、拒絶が使用されなければならないと、「554 5.7 .7Cannotはsubmitterアドレスについて確かめます」。

   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.

メール配達エージェントについて確かめて、(MTAs)がRFCに対してSUBMITTERパラメタを有効にするよう強く促される、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.

メールコマンドに関するSUBMITTERパラメタの存在がメッセージの有効な逆経路を変えてはいけないことに注意してください。 どんな配送状態通知も逆経路に送らなければなりません、1つが存在しているなら、SUBMITTERパラメタの存在にかかわらず[SMTP]のセクション3.7に従って。 逆経路がヌルであるなら、配送状態通知をSUBMITTERアドレスに送ってはいけません。

   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.

同様に、SUBMITTERパラメタはメッセージの有効な回答アドレスを変えてはいけません。 または、Fromアドレスに回答を送らなければならない、Reply、-、アドレス、SUBMITTERパラメタの存在にかかわらず説明されるとして.2セクション3.6[エムエスジー-FORMAT]に存在しているなら。

4.3.  Transmitting to a Non-SUBMITTER-Aware SMTP Server

4.3. aに伝わる、非SUBMITTER意識する、SMTPサーバ

   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がSUBMITTER拡張子をサポートしない別のMTAに送信するとき、上に、推進MTA MUSTはSUBMITTERパラメタなしでメッセージを送ります。 SUBMITTERパラメタがメッセージヘッダーから得られた情報を含むのに必要であるので、これは情報の損失に全くかかわるべきではありません。

5.  Examples

5. 例

   This section provides examples of how the SUBMITTER parameter would
   be used.  The following dramatis personae appear in the examples:

このセクションはSUBMITTERパラメタがどう使用されるだろうかに関する例を提供します。 以下の登場人物は例に現れます:

Allman & Katz                 Experimental                      [Page 6]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[6ページ]RFC4405SMTP

   alice@example.com: the original sender of each e-mail message.

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 の彼のオフィスアカウントにメールを転送するために構成したボブによって使用されたEメールアドレス。

   alice@mobile.net.example: an e-mail account provided to Alice by her
   mobile e-mail network carrier.

alice@mobile.net.example : メール・アカウントは彼女のモバイルメールネットワークキャリヤーによるアリスに提供されました。

5.1.  Mail Submission

5.1. 服従を郵送してください。

   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.

通常の状況下で、アリスは、SUBMITプロトコル[SUBMIT]を使用することでメールシステムに彼女のメッセージを提出するために彼女のMUAを構成するでしょう。 MUAはSUBMITTERパラメタなしでメッセージを送るでしょう。 SUBMITサーバは有効にされるでしょう。MUAは何らかの外部の計画、恐らくSMTP Authentication[SMTPAUTH]を通してメッセージを提出できます。 ほとんどの状況で、これは正常で、認証されたSMTP取引に似ているでしょう。 SUBMITサーバはRFCから彼女の名前を抜粋するでしょう。メッセージのその後の送信のSUBMITTERパラメタにおける使用のための2822個のヘッダー。

5.2.  Mail Forwarding

5.2. メール転送

   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アカウントでメッセージをボブに送るとき、彼女のSUBMITサーバからの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

S: 220 almamater.edu.example ESMTPのサーバ持ち合わせのC: EHLO example.com S: 250-almamater.edu.example S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 サイズC: FROM:<alice@example.com に郵送してください、gt;、SUBMITTERは alice@example.com Sと等しいです: 250 <alice@example.com 、gt;、送付者OK C: RCPT TO:<bob@almamater.edu.example 、gt;、S: 250 <bob@almamater.edu.example 、gt;、受取人OK C: データS: 354 間違いなく、メッセージCを送ってください: (メッセージ本体はここに行きます) C: . S: 250メッセージはCを受け入れました: Sをやめてください: 221さよなら

Allman & Katz                 Experimental                      [Page 7]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[7ページ]RFC4405SMTP

   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 によっていっぱいにされます。( bob@almamater.edu.example はメールの推進を bob@company.com.example に確立しました)。 したがって、almamater.edu.example MTAは新しい主張されたすなわち、メッセージ、 bob@almamater.edu.example において、原因となるアドレスを決定して、それに従って、SUBMITTERパラメタを設定します。 また、推進MTAが挿入する、Resent、-、ヘッダー、確実にするメッセージ本体では、主張された原因となるアドレスがRFC2822ヘッダーマッチにSUBMITTERアドレスに由来していました。

      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

S: 220 company.com.example ESMTPのサーバ持ち合わせのC: EHLO almamater.edu.example S: 250-company.com.example S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 サイズC: FROM:<alice@example.com に郵送してください、gt;、SUBMITTERは bob@almamater.edu.example Sと等しいです: 250 <alice@example.com 、gt;、送付者OK C: RCPT TO:<bob@company.com.example 、gt;、S: 250 <bob@company.com.example 、gt;、受取人OK C: データS: 354 間違いなく、メッセージCを送ってください: From:に憤慨します。 bob@almamater.edu.example C: 以下は受け取りました。 ... C: (メッセージ本体はここに行きます) C: . S: 250メッセージはCを受け入れました: Sをやめてください: 221さよなら

5.3.  Mobile User

5.3. モバイルユーザ

   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によって提供されたキャリヤーネットワークを通って移動しますが、アリスが彼女のすべてのメッセージのFrom線に関する彼女のexample.comアドレスを使用するので、回答は彼女のオフィスメールボックスに行きます。

Allman & Katz                 Experimental                      [Page 8]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[8ページ]RFC4405SMTP

   Here is an example of the SMTP session between the MTAs at
   mobile.net.example and almamater.edu.example.

ここに、MTAsの間のSMTPセッションに関する例がmobile.net.exampleとalmamater.edu.exampleにあります。

      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

S: 220 almamater.edu.example ESMTPのサーバ持ち合わせのC: EHLO mobile.net.example S: 250-almamater.edu.example S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 サイズC: FROM:<alice@example.com に郵送してください、gt;、SUBMITTERは alice@mobile.net.example Sと等しいです: 250 <alice@example.com 、gt;、送付者OK C: RCPT TO:<bob@almamater.edu.example 、gt;、S: 250 <bob@almamater.edu.example 、gt;、受取人OK C: データS: 354 間違いなく、メッセージCを送ってください: 送付者: alice@mobile.net.example C: 以下は受け取りました。 ... C: (メッセージ本体はここに行きます) C: . S: 250メッセージはCを受け入れました: Sをやめてください: 221さよなら

   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がこのメッセージのための責任があるsubmitterとして alice@mobile.net.example を指定するのにSUBMITTERパラメタを使用することに注意してください。 また、さらに、このMTAは、主張された原因となるアドレスがRFC2822ヘッダーマッチにSUBMITTERアドレスに由来していたのを保証するためにSenderヘッダーを挿入します。

   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.

また、同様に、そのアドレスがMAIL FROMアドレスと異なるなら、従来のISPは、責任があるsubmitterとしてISPのネットワークに関するユーザのアドレスを指定するのにSUBMITTERパラメタを使用するのを選ぶかもしれません。 これは特に複数のドメインを接待するか、または別の方法で複数のドメインの中でMTAsを共有する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のようにSUBMITTERパラメタを bob@almamater.edu.example に取り替えて、加える、それ自身、Resent、-、ヘッダー

5.4.  Guest E-Mail Service

5.4. 客メールサービス

   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ホテルによって提供された、インターネットに接続して、メールを送った広帯域アクセス施設を使用しますが。 ホテルはそれ自身のSMTPサーバー、email.hotel.com.exampleを通してすべての外国行きのメールを発送します。

Allman & Katz                 Experimental                      [Page 9]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[9ページ]RFC4405SMTP

   The SMTP session for Alice's message to Bob from the Exemplar Hotel
   would look like this:

Exemplarホテルからのボブへのアリスのメッセージのための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

S: 220 almamater.edu.example ESMTPのサーバ持ち合わせのC: EHLO email.hotel.com.example S: 250-almamater.edu.example S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 サイズC: FROM:<alice@example.com に郵送してください、gt;、SUBMITTERは guest.services@email.hotel.com.example Sと等しいです: 250 <alice@example.com 、gt;、送付者OK C: RCPT TO:<bob@almamater.edu.example 、gt;、S: 250 <bob@almamater.edu.example 、gt;、受取人OK C: データS: 354 間違いなく、メッセージCを送ってください: From:に憤慨します。 guest.services@email.hotel.com.example C: 以下は受け取りました。 ... C: (メッセージ本体はここに行きます) C: . S: 250メッセージはCを受け入れました: Sをやめてください: 221さよなら

   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がこのメッセージのための原因となるsubmitterアドレスとして一般的なアカウントを guest.services@email.hotel.com.example に指定するのにSUBMITTERパラメタを使用することに注意してください。 アリス自身がそのドメインにアカウントを持っていないので、一般的なアカウントは使用されています。 その上、また、このクライアントが挿入する、Resent、-、ヘッダー、主張された原因となるアドレスを確実にするのはRFCからSUBMITTERアドレスがある2822個のヘッダーを引き出しました。

   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のようにSUBMITTERパラメタを bob@almamater.edu.example に取り替えて、加える、それ自身、Resent、-、ヘッダー

Allman & Katz                 Experimental                     [Page 10]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[10ページ]RFC4405SMTP

5.5.  SUBMITTER Used on a Non-Delivery Report

5.5. 非配送レポートで使用されるSUBMITTER

   Alice sends an incorrectly addressed e-mail message and receives a
   non-delivery report from a SUBMITTER-compliant server.

アリスは、SUBMITTER対応することのサーバから不当に記述されたメールメッセージを送って、非配送レポートを受け取ります。

      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

S: 220 example.com ESMTPのサーバ持ち合わせのC: EHLO almamater.edu.example S: 250-example.com S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 サイズC: メールFROM:<>SUBMITTERは mailer-daemon@almamater.edu.example Sと等しいです: 250 OK C: RCPT TO:<alice@example.com 、gt;、S: 250 OK C: データS: 354 OK、メッセージCを送ってください: (メッセージ本体はここに行きます) C: . S: 250メッセージはCを受け入れました: Sをやめてください: 221さよなら

6.  Security Considerations

6. セキュリティ問題

   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プロトコルのメールメッセージの責任があるsubmitterを特定して、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.

しかしながら、攻撃者がSUBMITTERパラメタの値を鍛造するのは、かなり可能です。 その上、攻撃者がSUBMITTERパラメタが2822個のRFCから派生しているヘッダーとしてメッセージの主張された原因となるアドレスに合っていないメールメッセージを送るのは、可能です。 したがって、SUBMITTERパラメタの存在は提供します、それ自体で、メッセージの信憑性か責任があるsubmitterの保証がありません。 むしろ、SUBMITTERパラメタが彼らが効率的に明確に責任があるsubmitterの正当性を決定するのを可能にするために受信電子メール・システムに追加情報を供給することを意図します、SMTPクライアントが主張された責任があるsubmitterのドメインを代表してメールを伝えるのに権限を与えられるか否かに関係なく。 セクション4.2は受信電子メール・システムがどうSUBMITTERパラメタを処理するはずであるかを説明します。

Allman & Katz                 Experimental                     [Page 11]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[11ページ]RFC4405SMTP

7.  Acknowledgements

7. 承認

   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拡張子の考えには、多くの先祖がいます。 ニック・シェルは作者のひとりとの密談における考えを勧めました。 ピートレズニックはMARIDメーリングリストで異形を勧めました。 また、Anti-スパムResearch Group(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:

また、作者は彼らのコメントと提案についてMARIDワーキンググループと以下の個人の関係者に感謝したがっています:(提案はこのドキュメントを大いに改良しました)。

      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.

ロバート・アトキンソン、サイモン・アットウェル、ロイBadami(グレッグ・コナー、デーヴ・クロッカー、マシュー・エルビ、ネッドが解放したトニーFinch)はLentczner、ジム・リヨン、ブルース・マクミラン、サム・ニーリー、ダリルOdnert、マーガレット・オルソン、ピートレズニック、ヘクトル・サントス、ニック・シェル、Randワッカー、およびMeng Wengウォンをマークします。

8.  IANA Considerations

8. IANA問題

      The IANA has registered the SUBMITTER SMTP service extension.

IANAはSUBMITTER SMTPサービス拡張子を登録しました。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 4234, October 2005.

[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [DSN]        Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
                Extension for Delivery Status Notifications (DSNs)", RFC
                3461, January 2003.

[DSN]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [MSG-FORMAT] Resnick, P., "Internet Message Format", RFC 2822, April
                2001.

[エムエスジー形式] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [PRA]        Lyon, J., "Purported Responsible Address in E-Mail
                Messages", RFC 4407, April 2006.

[PRA] リヨン、J.、「メールメッセージの主張された原因となるアドレス」、RFC4407、2006年4月。

   [SENDER-ID]  Lyon, J. and M. Wong, "Sender ID: Authenticating E-
                Mail", RFC 4406, April 2006.

[送付者ID] リヨン、J.、およびM.ウォン、「送付者ID:」 「電子メールを認証します」、RFC4406、2006年4月。

   [SUBMIT]     Gellens, R. and J. Klensin, "Message Submission for
                Mail", RFC 4409, April 2006.

[提出します] GellensとR.とJ.Klensin、「メールのためのメッセージ提案」、RFC4409、2006年4月。

Allman & Katz                 Experimental                     [Page 12]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[12ページ]RFC4405SMTP

   [SMTP]       Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
                April 2001.

[SMTP] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。

   [SMTPAUTH]   Myers, J., "SMTP Service Extension for Authentication",
                RFC 2554, March 1999.

[SMTPAUTH] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。

Authors' Addresses

作者のアドレス

   Eric Allman
   Sendmail, Inc.
   6425 Christie Ave, Suite 400
   Emeryville, CA 94608
   USA

クリスティAve、エリックオールマンセンドメールInc.6425Suite400カリフォルニア94608エマリービル(米国)

   EMail: eric@sendmail.com

メール: eric@sendmail.com

   Harry Katz
   Microsoft Corp.
   1 Microsoft Way
   Redmond, WA 98052
   USA

ハリーキャッツMicrosoft Corp.1マイクロソフト、道のワシントン98052レッドモンド(米国)

   EMail: hkatz@microsoft.com

メール: hkatz@microsoft.com

Allman & Katz                 Experimental                     [Page 13]

RFC 4405          SMTP Responsible Submitter Extension        April 2006

Submitter拡大2006年4月に責任があるオールマンとキャッツ実験的な[13ページ]RFC4405SMTP

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Allman & Katz                 Experimental                     [Page 14]

オールマンとキャッツExperimentalです。[14ページ]