この文書はインターネットドラフトの日本語訳（和訳）です。 翻訳者はこの文書の翻訳の正確さを保障しません。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの翻訳の配布に制限をしません。
MARID Working Group J. Lyon
Internet Draft Microsoft Corp
Document: draft-ietf-marid-core-03.txt M. Wong
pobox.com
Expires: February 2005 August 2004
Sender ID: Authenticating E-Mail
送信者識別子：電子メール認証
Status of this Memo
このメモの状態
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
このインターネットドラフトを提出することによって、私は私が気付いて
いるどんな適用可能な特許あるいは他の知的財産クレームも発表されたか、
あるいは明らかにされることを保証します、そして私が気付くどれも、
ＲＦＣ３６６８のとおりに、明らかにされるでしょう。
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
groups may also distribute working documents as Internet-Drafts.
インターネットドラフトはインターネット技術タスクフォース（ＩＥＴＦ）
とそのエリアとその作業グループの作業文書です。他のグループがインター
ネットドラフトとして同じく作業文書を配るかもしれないことに注意してく
ださい。
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
インターネットドラフトは最大６カ月間有効なドラフト文書で、いつでも他
の文書によって、更新か、置換えか、時代遅れにされるかもしれません。イ
ンターネットドラフトは、「進行中の仕事」として以外に、参照材料あるい
は引用として用いることは不適当です。
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
現在のインターネットドラフトのリストは
http://www.ietf.org/ietf/1id-abstracts.txt でアクセスできます。
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
インターネットドラフトの影ディレクトリのリストは
http://www.ietf.org/shadow.html でアクセスできます。
Abstract
要約
Internet mail suffers from the fact that much unwanted mail is sent
using spoofed addresses -- "spoofed" in this case means the address
is used without the permission of the domain owner. This document
describes the following: mechanisms by which a domain owner can
publish its set of outgoing MTAs, mechanisms by which SMTP servers
can determine what email address is allegedly responsible for most
proximately introducing a message into the Internet mail system, and
whether that introduction is authorized by the owner of the domain
contained in that email address.
インターネットメールは、多くの望まれないメールが偽アドレスで送られて
いる事実で苦しみます。−この場合「偽」はドメイン所有者の許可無しでア
ドレスが使われることを意味します。この文書は次のことを記述します：ド
メイン所有者がその外向ＭＴＡの集合を公開することができるメカニズム、
ＳＭＴＰサーバが、電子メールアドレスに対し、インターネットメールシス
テムにメッセージを投入れる責任がだれにあるか決定することができるメカ
ニズム、そしてその投入がその電子メールアドレスのドメイン所有者によっ
て公認されるか否か。
The specification is carefully tailored to ensure that the
overwhelming majority of legitimate emailers, remailers and mailing
list operators are already compliant.
仕様書は慎重に、圧倒的な大多数の正しいメーラとリメーラとメーリングリ
ストオペレータがすでに準拠しているのを保証するように適応させられます。
Table of Contents
目次
1. Introduction...................................................3
2. Problem Statement..............................................3
2.1 Positive Problem Statement.................................3
2.2 Negative Problem Statement.................................4
3. Decision Model.................................................4
4. Determining the Purported Responsible Address..................5
5. Actions Based on the Decision..................................5
5.1 Neutral or None or PermError...............................6
5.2 Pass.......................................................6
5.3 Fail.......................................................6
5.4 SoftFail...................................................6
5.5 TempError..................................................6
6. Security Considerations........................................6
6.1 DNS Attacks................................................7
6.2 TCP Attacks................................................7
6.3 Forged Sender Attacks......................................7
6.4 Address Space Hijacking....................................7
7. Implementation Guidance........................................8
7.1 Simple E-mailers...........................................8
7.2 E-Mail Forwarders..........................................8
7.3 Mailing List Servers.......................................8
7.4 Third-Party Mailers........................................9
7.5 MUA Implementers...........................................9
8. IANA Considerations............................................9
9. Acknowledgements...............................................9
10. References...................................................10
10.1 Normative References.....................................10
10.2 Informative References...................................10
11. Authors' Addresses...........................................11
Conventions used in this document
この文書の決まり
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 [RFC2119].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONALは
[RFC2119]で記述されるように、解釈されます。
1. Introduction
1. はじめに
Today, a huge majority of unwanted email contains headers that lie
about the origin of the mail. This is true of most spam and
substantially all of the virus email that is sent.
今日、望まれない電子メールの莫大な数がメールの発信元を偽るヘッダを含
んでいます。これはたいていのスパムで事実で、大体の電子メールを送るウ
イルスで事実です。
This document describes a mechanism such that receiving MTAs, MDAs
and/or MUAs can recognize mail in the above category and take
appropriate action. For example, an MTA might refuse to accept a
message, an MDA might discard a message rather than placing it into a
mailbox, and an MUA might render that message in some distinctive
fashion.
この文書は、受信ＭＴＡとＭＤＡとＭＵＡで上記のカテゴリーのメールを
認識し、適切な行動をとることができるように、メカニズムを記述します。
例えば、ＭＴＡがメッセージを受け入れることを拒否するかもしれません、
ＭＤＡがメールボックスの中にそれを置くよりむしろメッセージを捨てる
かもしれません、そしてＭＵＡがある特有な方法でそのメッセージを提出
するかもしれません。
In order to avoid further fragmentation of the Internet email system,
it is necessary that the Internet community as a whole come to a
consensus as to what mail senders should do to make their mail appear
non-spoofed, and how mail receivers should determine whether mail is
spoofed. On the other hand, it is not necessary to reach a consensus
regarding the actions that various parties take once a message has
been determined to be spoofed. This can be done unilaterally -- one
agent might decide to discard a spoofed message while another decides
to add a disclaimer.
インターネット電子メールシステムにこれ以上の分断を避けるために、イン
ターネット共同体が、メール送り主がメールが詐欺でないように見えさせる
ために何をするべきであるか、そしてどのようにメール受信者がメールが偽
アドレスで送られるかどうか決定するべきであるかについて、全体として合
意に到達することは必要です。他方、メッセージが偽と決定した後でとる行
動に関して合意に達することは必要ではありません。これは一方的にできま
す−あるエージェントがメッセージを捨てると決め、あるエージェントが断
り書きを加えることに決めるかもしれません。
2. Problem Statement
2. 問題宣言
2.1 Positive Problem Statement
2.1 積極的な問題宣言
Briefly stated, the mechanisms of this document allow one to answer
the following question:
手短かに述べると、この文書のメカニズムは次の質問に答えることを可能に
します：
When a message is transferred via SMTP between two UNRELATED parties,
does the SMTP client host have permission to send mail on behalf of
the mailbox that allegedly caused the most recent introduction of the
message into the mail delivery system?
メッセージが２つの無関係な者の間でＳＭＴＰで転送される時、メール配達
システムにメッセージを送ったＳＭＴＰクライアントホストはメールボック
スにメールを送る許可を持っていますか？
As seen from the question, this mechanism applies to unrelated
parties: it is useful at the point where a message passes across the
Internet from one organization to another. It is beyond the scope of
this document to describe authentication mechanisms that can be
deployed within an organization.
質問からわかるように、この機構は無関係な者に当てはまります：これは１
つの組織から他にインターネットを越えてメッセージが通過する点で有用で
す。組織の中に配置する認証メカニズムの記述はこの文書の範囲外です。
The mechanism of this document also seeks to authenticate the mailbox
associated with the MOST RECENT introduction of a message into the
mail delivery system. In simple cases, this is who the mail is from.
However, in the case of a third-party mailer, a forwarder or a
mailing list server, the address being authenticated is that of the
third party, the forwarder or the mailing list.
この文書の機構は同じくメール配達システムの中のメッセージのMOST RECENT
導入と結び付けられたメールボックスを認証しようと努めます。単純な場合、
これはメールが誰からであるかです。しかしながら、第三者メイラー、転送、
メーリングリストサーバの場合、本物と証明されているアドレスは第三者、
転送者あるいはメーリングリストのそれです。
This document provides means to authenticate the DOMAIN of the
appropriate email address; it is not directed at the local-part. A
domain owner gets to determine which SMTP clients speak on behalf of
addresses within the domain; a responsible domain owner should not
authorize SMTP clients that will lie about local parts.
この文書は適切な電子メールアドレスのドメインを認証する手段を供給しま
す；これはローカルな部分に向けられていません。ドメイン所有者がどのＳ
ＭＴＰクライアントがドメインのアドレスを使って話をするか決定できます；
責任があるドメイン所有者がローカル部について嘘をつくＳＭＴＰクライア
ントを認証するべきではありません。
In the long run, once the domain of the sender is authenticated, it
will be possible to use that domain as part of a mechanism to
determine the likelihood that a given message is spam, using, for
example, reputation and accreditation services. (These services are
not the subject of the present mechanism, but it should enable them.)
長い目で見れば、送信者のドメインが認証されると、例えば評判や認可サー
ビスを使って、あるメッセージがスパムであるという可能性を決定するため
にそのドメインをメカニズムの一部として用いることは可能であるでしょう。
（これらのサービスは現在の機構の主題ではありません、しかしそれらを可
能にするべきです。）
2.2 Negative Problem Statement
2.2 否定的な問題主張
Following are several alternate questions, which this specification
makes no attempt to answer:
下記はいくつかの代わりの質問で、そしてこの仕様書が答える試みをします：
1. Is the host at a particular IP address authorized to act as an
SMTP client?
1. 特定のＩＰアドレスのホストはＳＭＴＰクライアントの役を務める権限
を与えられていますか？
2. Is an SMTP client authorized to use a particular domain name in
its SMTP EHLO command?
2. ＳＭＴＰクライアントがSMTP EHLOコマンドで特定のドメイン名を使う
権限を与えられていますか？
3. Is an SMTP client authorized to use a particular email address in
an SMTP "MAIL FROM:" command?
3. ＳＭＴＰクライアントが特定の電子メールアドレスでＳＭＴＰの"MAIL
FROM:"コマンドを使う権限を与えられていますか？
4. Was a message really authored by who it claims to be authored by?
4. 著者と主張された人によって本当にメッセージは著作されたか？
3. Decision Model
3. 決定モデル
The essence of this specification is:
この仕様書の本質は以下です：
Given an email message, and given an IP address from which it has
been (or will be) received, is the SMTP client at that IP address
authorized to send that email message?
ある電子メールメッセージと、それを受取った（受取る予定）のＩＰアドレ
スに対し、そのＩＰアドレスのＳＭＴＰクライアントはその電子メールメッ
セージを送る権限を与えられますか？
This question will usually be asked by an SMTP server as part of
deciding whether to accept an incoming mail message. However, this
question could also be asked later by a different party. An MUA, for
example, could use the result of this question to determine how to
file or present a message.
この質問は通常入メールメッセージを受け入れるべきかを決めるのと同じ部
分でＳＭＴＰサーバによってされるでしょう。しかしながら、この質問は同
じく異なる関係者により後でされることができます。例えば、ＭＡＵがどの
順でメッセージをファイルするか表示するかを決定するためにこの質問の結
果を使うことができました。
There are four steps to answering this question:
この質問に答える４つのステップがあります：
(1) From the headers of the email message, extract the "purported
responsible address". This is the mailbox that the message
claims is responsible for the most recent introduction of the
message into the delivery system. This step is described in
detail in section 4 below. A separate specification,
[Submitter], describes an SMTP extension that allows an SMTP
server to perform this check at the time of the SMTP MAIL
command instead of the SMTP DATA command.
(1) 電子メールメッセージのヘッダから、「信頼できると言われているアド
レス」を抜き出してください。これはメッセージ配達システムでメッセー
ジの投入に関して責任があると主張するメールボックスです。このステッ
プは下の４章で詳細で記述されます。別の仕様書、[Submitter]、がＳ
ＭＴＰサーバがＳＭＴＰデータコマンドの代わりにＳＭＴＰメールコマ
ンドの時にこの検査を行うことを許すＳＭＴＰ拡張が記述されます。
(2) Extract the domain part of the purported responsible address.
Call this the "purported responsible domain".
(2) 信頼できると言われているアドレスのドメイン部を抜き出してください。
これを「信頼できると言われているドメイン」と呼んでください。
(3) Call the check_host function defined in [Protocol], passing the
following parameters:
(3) [Protocol]で定義された、check_host機能を次のパラメータで呼んでく
ださい：
a. The IP address (either IPv4 or IPv6) from which the message
is being or has been received.
a. メッセージを送ってきたＩＰアドレス（ＩＰｖ４あるいはＩＰｖ６）。
b. The purported responsible domain from step (2) above.
b. ステップ（２）の責任があると称するドメイン。
c. The purported responsible address from step (1) above.
c. ステップ（１）の責任があると称するアドレス。
The result of the check_host function is one of the values "Neutral",
"Pass", "Fail", "SoftFail", "None", "TempError" or "PermError".
Section 5 describes how these results are used by MTAs receiving
messages. This specification imposes no requirements on parties
performing this test in other environments.
check_host機能の結果は値"中立"、"通過"、"失敗"、"ソフト障害"、"なし"、
"一時エラー"、"恒久エラー"のどれかです。５章がメッセージを受取るＭＴ
Ａがこれらの結果を使う方法を記述します。この指定は他の環境でこの検査
を行っている関係者に必要条件を課しません。
4. Determining the Purported Responsible Address
4. 信頼できると言われているアドレスの決定
The purported responsible address (PRA) of a message MUST be
determined using the algorithm described in [PRA].
メッセージの信頼できると言われているアドレス（ＰＲＡ）は[PRA]で記述さ
れたアルゴリズムを使って決定されなくてはなりません。
If the Sender ID check is being performed by an MTA as part of
receiving an e-mail message, and the PRA algorithm cannot determine a
PRA, then the message SHOULD be rejected with error "550 5.1.7
Missing purported Responsible Address".
もし送信者識別子検査がＭＴＡで電子メールメッセージの受信の一部として
行われ、そしてＰＲＡアルゴリズムがＰＲＡを決定できないなら、メッセー
ジはエラー"550 5.1.7 Missing purported Responsible Address"で拒絶され
るべきです。
5. Actions Based on the Decision
5. 決定に基づいた行動
When the Sender ID test is used by an SMTP server as part of
receiving a message, the server should take the actions described by
this section.
送信者識別子試験がＳＭＴＰサーバでメッセージ受信の一部として使われる
とき、サーバはこの章で記述された行動をとるべきです。
The check_host function returns one of the following results. See
[Protocol] for the meaning of these results.
check_host関数は次の結果の１つを返します。これらの結果の意味は
[Protocol]を見てください。
5.1 Neutral or None or PermError
5.1 中立や無しやPermError
An SMTP server receiving one of these results SHOULD NOT reject the
message for this reason alone, but MAY subject the message to
heightened scrutiny by other anti-spam measures, and MAY reject the
message as a result of this heightened scrutiny.
これらの結果の１つを受けたＳＭＴＰサーバはこの理由だけでメッセージを
拒絶するべきではありません、しかし他の対スパムの手段でメッセージの精
密検査をしてもよくて、精密検査の結果としてメッセージを拒絶してもよい
です。
5.2 Pass
5.2 通過
An SMTP server receiving this result SHOULD treat the message as
authentic. It may accept or reject the message depending on other
policies.
この結果を受けたＳＭＴＰサーバがメッセージを正しいとして扱うべきです。
受け入れるか、他のポリシに従ってメッセージを拒絶するかもしれません。
5.3 Fail
5.3 落第
An SMTP server receiving this result SHOULD reject the message with a
"550 5.7.1 Sender ID xxx - yyy" SMTP error, where "xxx" is replaced
with the additional reason returned by the check_host function and
"yyy" is replaced with the explanation string returned by the
check_host function.
この結果を受けたＳＭＴＰサーバは"550 5.7.1 Sender ID xxx - yyy"ＳＭ
ＴＰエラーでメッセージを拒絶するべきです、ここで"xxx"はcheck_host関
数の追加理由で置き換えられ、"yyy"はcheck_host関数の返した説明文字列
で置き換えられるべきです。
5.4 SoftFail
5.4 ソフト障害
An SMTP server receiving this result SHOULD NOT reject the message
for this reason alone, but MAY subject the message to heightened
scrutiny by other anti-spam measures, and MAY reject the message as a
result of this heightened scrutiny. A message for which the result
is "SoftFail" is less likely to be authentic than a message for which
the result is "Neutral".
この結果を受けたＳＭＴＰサーバがこの理由だけでメッセージを拒絶するべ
きではありませんが、他の対スパムの方法でメッセージを精密検査してもよ
くて、この精密検査の結果としてメッセージを拒絶してもよいです。結果が
「ソフト障害」であるメッセージは結果が「中立」であるメッセージより信
頼できる可能性が低いです。
5.5 TempError
5.5 一時エラー
An SMTP server receiving this result MAY reject the message with a
"450 4.4.3 Sender ID check is temporarily unavailable" error code.
Alternatively, an SMTP server receiving this result MAY accept a
message and optionally subject it to heightened scrutiny by other
anti-spam measures.
この結果を受けたＳＭＴＰサーバが"450 4.4.3 Sender ID check is
temporarily unavailable"エラーコードでメッセージを拒絶してもよいです。
代わりに、この結果を受けたＳＭＴＰサーバがメッセージを受け入れて、他
の対スパムの方法でオプションとして精密検査をしてもよいです。
6. Security Considerations
6. セキュリティの考察
This entire document describes a new mechanism for mitigating spoofed
email, which is today a pervasive security problem in the Internet.
この文書全体は偽アドレスで送られた電子メールを抑制する新しいメカニズ
ムを記述し、これはインターネットで今日起きているセキュリティ問題です。
Assuming that this mechanism is widely deployed, the following
sections describe counter-attacks that could be used to defeat this
mechanism.
このメカニズムが広く配置されると想定し、次の章はこのメカニズムを破る
ために使える逆襲を記述します。
6.1 DNS Attacks
6.1 ＤＮＳ攻撃
The new mechanism is entirely dependent on DNS lookups, and is
therefore only as secure as DNS. An attacker bent on spoofing
messages could attempt to get his messages accepted by sending forged
answers to DNS queries.
新しいメカニズムは完全にＤＮＳ検索に依存していて、それゆえにＤＮＳと
同程度に安全なだけです。詐欺メッセージを決意している攻撃者が彼のメッ
セージが受け入れられるようにＤＮＳ問合せに偽応答を試みることができま
す。
An MTA could largely defeat such an attack by using a properly
paranoid DNS resolver. DNSSEC may ultimately provide a way to
completely neutralize this class of attacks.
ＭＴＡは主に正確に検査をするＤＮＳリゾルバを使うことによってこのよう
な攻撃を破ることができます。ＤＮＳＳＥＣは究極的に完全にこの攻撃のク
ラスを無力にする方法を供給するかもしれません。
6.2 TCP Attacks
6.2 ＴＣＰ攻撃
This mechanism is designed to be used in conjunction with SMTP over
TCP. A sufficiently resourceful attacker might be able to send TCP
packets with forged from-addresses, and thus execute an entire SMTP
session that appears to come from somewhere other than its true
origin.
このメカニズムはＴＣＰ上のＳＭＴＰと関連して使われるよう意図されます。
十分に柔軟な攻撃者が偽アドレスからＴＣＰパケットを送ることが可能であ
るかもしれません、そして恩らいの送信場所以外のどこかからか来るように
思われるＳＭＴＰセッションを実行できます。
Such an attack requires guessing what TCP sequence numbers an SMTP
server will use. It also requires transmitting completely in the
blind - the attack will be unable hear any of the server's side of
the conversation.
このような攻撃はＳＭＴＰサーバがどのＴＣＰシーケンス番号を使うか言い
当てることを必要とします。攻撃者はサーバ側の会話を聞けないだろうから、
完全にめ予測で信号を送る事が要求されます。
Attacks of this sort can be ameliorated if IP gateways refuse to
forward packets when the source address is clearly bogus.
もしソースアドレスが明らかに偽である時ＩＰゲートウェイがパケットを転
送することを拒否するなら、この種類の攻撃に対して改善され得ます。
6.3 Forged Sender Attacks
6.3 偽造送信者攻撃
This mechanism chooses a purported responsible address from one of a
number of message headers, and then uses that address for validation.
A message with a true Resent-From header (for example), but a forged
From header will be accepted. Since many MUAs do not display all of
the headers of received messages, the message will appear to be
forged when displayed.
このメカニズムは多くのメッセージヘッダの１つから信頼できると思われる
アドレスを選択して、次に確証のためにそのアドレスを使います。本当の
Resent-Fromヘッダと（例えば）偽Ｆｒｏｍヘッダがあるメッセージは受け
入れられるであろう。多くのＭＵＡが受信メッセージのヘッダのすべてを示
すわけではないので、メッセージは表示される時に偽造されてるように思わ
れるでしょう。
In order to neutralize this attack, MUAs will need to start
displaying at least the header that was verified.
この攻撃を無力にするために、ＭＵＡは少なくとも検証されたヘッダを示す
必要があるでしょう。
6.4 Address Space Hijacking
6.4 アドレス空間ハイジャック
This mechanism assumes the integrity of IP address space for
determining whether a given client is authorized to send messages
from a given PRA. In addition to the TCP attack given in section
6.2, a sufficiently resourceful attacker might be able to alter the
IP routing structure to permit two-way communication using a
specified IP address. It would then be possible to execute an SMTP
session that appears to come from an authorized address, without the
need to guess TCP sequence numbers or transmit in the blind.
このメカニズムはあるクライアントがあるＰＲＡからのメッセージを送る権
限を与えられるかどうか決定することに対してＩＰアドレス空間の完全性を
仮定します。６.２章で与えられたＴＣＰ攻撃のほかに、十分に賢い攻撃者が
両方向通信で指定されたＩＰアドレスを使うのを許すためにＩＰルーティン
グ構造を変えることが可能であるかもしれません。ＴＣＰシーケンス番号を
推測するか、あるいは盲目で送信する必要無しで、公認アドレスから来るよ
うに思われるＳＭＴＰセッションを実行することはその時可能であるでしょ
う。
Such an attack might occur if the attacker obtained access to a
router which participates in external BGP routing. Such a router
could advertise a more specific route to a rogue SMTP client,
temporarily overriding the legitimate owner of the address.
このような攻撃は、もし攻撃者が外部のＢＧＰルーティングに参加するルー
タにアクセスを得たなら、起こるかもしれません。このようなルータは、一
時的にアドレスの合法的な所有者に優先して、特定の経路が怪しいＳＭＴＰ
クライアントに向かうように、広告できます。
7. Implementation Guidance
7. 実装ガイドライン
This section describes the actions that certain members of the
Internet email ecosystem must take to be compliant with this
specification.
この章はインターネット電子メール生態系のある特定のメンバがこの仕様書
に準拠する場合にとらなくてはならない行動を記述します。
7.1 Simple E-mailers
7.1 単純なメーラ
A domain that injects original email into the Internet, using its own
name in From headers, need do nothing to be compliant. However, such
domains SHOULD publish e-mail policy records in DNS.
ヘッダに自分自身の名前を使い、インターネットに電子メールを投入するド
メインは、準拠するために何もする必要がありません。しかしながら、この
ようなドメインはＤＮＳで電子メールポリシーレコードを公開するべきです。
7.2 E-Mail Forwarders
7.2 電子メール転送者
A program that forwards received mail to other addresses MUST add an
appropriate header that contains an email address that it is
authorized to use. Such programs SHOULD use the Resent-From header
for this purpose.
受信メールを他のアドレスに転送するプログラムは、使う権限を与えられた
電子メールアドレスを含んでいる適切なヘッダを加えなくてはなりません。
このようなプログラムはこの目的のためにResent-Fromヘッダを使うべきです。
Additionally, e-mail forwarders SHOULD publish Sender ID records for
their domains, and SHOULD use MTAs for which the Sender ID check
yields a "pass" result.
さらに、電子メール転送者が自ドメインの送信者識別子レコードを公開する
べきで、そして送信者識別子検査に通過する結果をもたらすＭＴＡを使うべ
きです。
Some of today's forwarders already add an appropriate header
(although many of them use Sender rather than Resent-From.)
今日の転送者のいくらかがすでに適切なヘッダを加えています（それらの多
くがResent-FromよりSenderを使います）。
7.3 Mailing List Servers
7.3 メーリングリストサーバ
A mailing list server MUST add an appropriate header that contains an
email address that it is authorized to use. Such programs SHOULD use
the Resent-From header for this purpose.
メーリングリストサーバは使う権限を与えられた電子メールアドレスを含ん
でいる適切なヘッダを加えなくてはなりません。このようなプログラムはこ
の目的のためにResent-Fromヘッダーを使うべきです。
Additionally, mailing list servers SHOULD publish Sender ID records
for their domains, and SHOULD use MTAs for which the Sender ID check
yields a "pass" result.
さらに、メーリングリストサーバがそのドメインのために送信者識別子レコー
ドを公開するべきで、そして送信者識別子検査に通過する結果をもたらすＭ
ＴＡを使うべきです。
Most of today's mailing list software already adds an appropriate
header (although most of them use Sender rather than Resent-From).
今日のメーリングリストソフトウェアの大部分は、（それらの大部分が
Resent-FromよりSenderを使うけれども）、すでに適切なヘッダーを加えます。
7.4 Third-Party Mailers
7.4 第三者メイラ
A program that sends mail on behalf of another user MUST add an
appropriate header that contains an email address that it is
authorized to use. Such programs SHOULD use the Sender header for
this purpose.
他のユーザにメールを送るプログラムは、使う権限を与えられた電子メール
アドレスを含んでいる適切なヘッダを加えなくてはなりません。このような
プログラムはこの目的のために送信者ヘッダを使うべきです。
Additionally, third-part mailers servers SHOULD publish Sender ID
records for their domains, and SHOULD use MTAs for which the Sender
ID check yields a "pass" result.
さらに、第三者メイラーサーバがそのドメインのために送信者識別子レコー
ドを公開するべきで、そして送信者識別子検査に通過する結果をもたらすＭ
ＴＡを使うべきです。
Many, but not all, of today's third-party mailers are already
compliant.
すべてではないが、多くの今日の第三者メイラがすでに準拠しています。
7.5 MUA Implementers
7.5 ＭＵＡ実装者
When displaying a received message, an MUA SHOULD display the
purported responsible address as defined by this document whenever
that address differs from the RFC 2822 From address. This display
SHOULD be in addition to the RFC 2822 From address.
受信メッセージを示す時、ＭＵＡは、そのアドレスがＲＦＣ２８２２のFrom
アドレスとは違う時はいつでも、この文書で定義されるように、信頼できる
と言われているアドレスを示すべきです。この表示はＲＦＣ２８２２のFrom
アドレスに追加してであるべきです。
When a received message contains multiple headers that might be used
for the purported responsible address determination, an MUA should
consider displaying all of them. That is, if a message contains
several Resent-From's, a Sender and a From, an MUA should consider
displaying all of them.
受信メッセージが信頼できると言われているアドレスの決定に使えるかもし
れない多数のヘッダを含んでいる時、ＭＵＡはそれらのすべてを示すことを
考えるべきです。すなわち、もしメッセージがいくつかのResent-Fromや
SenderやFromを含んでいるなら、ＭＵＡはそれらのすべてを示すことを考え
るべきです。
8. IANA Considerations
8. ＩＡＮＡの考慮
This document contains no actions for IANA.
この文書はＩＡＮＡのために行動を含んでいません。
9. Acknowledgements
9. 謝辞
Variations on the idea of using a DNS record to check the legitimacy
of an email address have occurred multiple times. The earliest known
work is [Vixie]; others include [RMX], [SPF] and [CallerID].
電子メールアドレスの正当性を検査するためにＤＮＳレコードを使うアイデ
アは何度も出ました。知られている最も早い仕事は[Vixie]です；他に[RMX]
と[SPF]と[CallerID]があります。
The current document borrows heavily from each of the above, and
incorporates ideas proposed by many members of the MARID working
group. The contributions of each of the above are gratefully
acknowledged.
現在の文書は上記からかなり流用し、そしてＭＡＲＩＤ作業班の多くのメン
バにより提言された考えを含みます。上記の人たちのそれぞれの貢献に感謝
します。
10. References
10. 参考文献
10.1 Normative References
10.1 基準的参考文献
[PRA] J. Lyon, "Purported Responsible Address in E-Mail
Messages", draft-ietf-marid-pra-00. Work in progress.
[Protocol] M. Wong and M. Lentczner, "The SPF Record Format and Test
Protocol", draft-ietf-marid-protocol-01. Work in
progress.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119.
10.2 Informative References
10.2 有益な参考文献
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical
Specification,
http://www.microsoft.com/mscorp/twc/privacy/spam_callerid
.mspx.
[RMX] H. Danisch, "The RMX DNS RR and method for lightweight
SMTP sender authorization", draft-danisch-dns-rr-smtp-04.
Work in progress.
[SPF] M. Lentczner and M. Wong, "Sender Policy Framework (SPF):
A Convention to Describe Hosts Authorized to Send SMTP
Traffic", draft-mengwong-spf-01. Work in progress.
[Submitter] E. Allman and H. Katz, "SMTP Service Extension for
Indicating the Responsible Submitter of an E-mail
Message", draft-ietf-marid-submitter-03. Work in
progress.
[Vixie] Paul Vixie, "Repudiating Mail-From",
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/
msg00658.html
11. Authors' Addresses
11. 著者のアドレス
Jim Lyon
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
jimlyon@microsoft.com
Meng Weng Wong
Singapore
mengwong@dumbo.pobox.com
Intellectual Property Statement
知的所有権宣言
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Disclaimer of Validity
正当性の断り書き
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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Copyright Statement
著作権表示
Copyright (C) The Internet Society (2004). 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.
著作権（Ｃ）インターネット学会（２００４）。この文書はＢＣＰ７８に含
まれる権利と許可と制限の適用を受け、そしてこの中に明らかにされる以外
は著者がすべての権利を維持します。
Acknowledgment
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。