2.4. Anti-Phishing
DMARC is designed to prevent bad actors from sending mail that claims
to come from legitimate senders, particularly senders of
transactional email (official mail that is about business
transactions). One of the primary uses of this kind of spoofed mail
is phishing (enticing users to provide information by pretending to
be the legitimate service requesting the information). Thus, DMARC
is significantly informed by ongoing efforts to enact large-scale,
Internet-wide anti-phishing measures.
2.4. フィッシング対策
DMARCは、悪意のある者が、正規の送信者、特に取引電子メール(商取引に関する公式メール)の送信者から送信されたと主張するメールを送信するのを防ぐように設計されている。この種類のなりすましメールの主な用途の1つは、フィッシング(情報を要求する正規のサービスを装ってユーザーに情報を提供させるようにする)である。したがってDMARCは、大規模かつインターネット全体規模のフィッシング対策を実施しようと現在行われている努力によって主な情報を得ている。
Although DMARC can only be used to combat specific forms of exact-
domain spoofing directly, the DMARC mechanism has been found to be
useful in the creation of reliable and defensible message streams.
DMARCは、特定の形式のドメインに一致するなりすましに直接対抗するためにしか使用できないが、DMARCのメカニズムは信頼かつ防御可能なメッセージストリームの生成に有用であることがわかっている。
DMARC does not attempt to solve all problems with spoofed or
otherwise fraudulent email. In particular, it does not address the
use of visually similar domain names (“cousin domains”) or abuse of
the RFC5322.From human-readable .
DMARCでは、なりすましメールまたは不正な電子メールに関するすべての問題の解決を目指してはいない。特にDMARCでは、視覚的に同じようなドメイン名(「類似ドメイン」)の使用や、RFC5322.Fromの人間が解読可能な<表示名>の不正使用は扱わない。
3. Terminology and Definitions
This section defines terms used in the rest of the 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 [KEYWORDS].
3. 用語と定義
本節は、本文書の残りの部分で使用する用語を定義する。
「なければならない（MUST）」、「してはならない（MUST NOT）」、「…の必要がある（REQUIRED）」、「（当然）…するものとする（SHALL）」、「（当然）…しないものとする（SHALL NOT）」、「…すべきである（SHOULD）」、「…すべきではない（SHOULD NOT）」、「…が推奨される（RECOMMENDED）」、「…してもよい（MAY）」、「…を選択してもよい（OPTIONAL）」は、[KEYWORDS]に記載されるよう解釈する。
Readers are encouraged to be familiar with the contents of
[EMAIL-ARCH]. In particular, that document defines various roles in
the messaging infrastructure that can appear the same or separate in
various contexts. For example, a Domain Owner could, via the
messaging security mechanisms on which DMARC is based, delegate the
ability to send mail as the Domain Owner to a third party with
another role. This document does not address the distinctions among
such roles; the reader is encouraged to become familiar with that
material before continuing.
読者は、[EMAIL-ARCH]の内容をよく理解する必要がある。特に、その内容は、さまざまな状況で同じに見えたり、異なって見えたりするメッセージングインフラでのさまざまな役割を定義する。例えば、ドメイン所有者は、DMARCが基本にするメッセージングセキュリティメカニズムを用い、別の役割のサードパーティにドメイン所有者としてメール送信を任せることができる。本文書では、そのような役割の違いについて記載しないため、読者は、読み進める前に[EMAIL-ARCH]の内容をよく理解する必要がある。
The following terms are also used:
Authenticated Identifiers: Domain-level identifiers that are
validated using authentication technologies are referred to as
“Authenticated Identifiers”. See Section 4.1 for details about
the supported mechanisms.
Author Domain: The domain name of the apparent author, as extracted
from the RFC5322.From field.
また、次の用語を使用する。
認証識別子：認証技術を使用して認証したドメインレベルの識別子を「認証識別子」と呼ぶ。サポートするメカニズムの詳細に関しては、4.1節を参照していただきたい。
著者ドメイン：RFC5322.Fromフィールドから抽出されるような見かけ上の著者のドメイン名である
[Page 7]
| 《PREV》 |