o In the MUA, only show the display name if the DMARC mechanism
succeeds. This too is easily defeated, as an attacker could
arrange to pass the DMARC tests while fraudulently using another
domain name in the display name.
o MUAでは、DMARCのメカニズムによる判定が成功する場合にのみ表示名を示す。攻撃者は、表示名に別のドメイン名を不正に使用してDMARC判定に成功することが可能であるため、これも容易に破られる。
o In the MUA, only show the display name if the DMARC mechanism
passes and the email address thus validated matches one found in
the receiving user’s list of known addresses.
o MUAで、DMARCのメカニズムによる判定が成功し、かつ、有効な電子メールアドレスが、受信側ユーザーの既知のアドレスリストに存在する１つと一致する場合にのみ、表示名を示す。
12.5. External Reporting Addresses
To avoid abuse by bad actors, reporting addresses generally have to
be inside the domains about which reports are requested. In order to
accommodate special cases such as a need to get reports about domains
that cannot actually receive mail, Section 7.1 describes a DNS-based
mechanism for verifying approved external reporting.
12.5. 外部報告アドレス
悪意のある者による不正使用を避けるために、一般に、レポートが要求されるドメイン内に報告アドレスが存在する必要がある。実際にメールを受信できないドメインに関するレポートを取得する必要があるなどの特別な場合に対応するため、7.1節に、承認された外部の報告を検証するためのDNSベースのメカニズムについて記載する。
The obvious consideration here is an increased DNS load against
domains that are claimed as external recipients. Negative caching
will mitigate this problem, but only to a limited extent, mostly
dependent on the default TTL in the domain’s SOA record.
ここで検討すべき事項は明らかに、外部の受信者と主張するドメインに対してDNSの負荷が増大するということである。ネガティブキャッシングはこの問題を抑制するが、限られた範囲のみであり、大部分はそのドメインのSOAレコードのデフォルトTTLに依存する。
Where possible, external reporting is best achieved by having the
report be directed to domains that can receive mail and simply having
it automatically forwarded to the desired external destination.
可能な場合、外部のレポートティングを実現する最良の方法は、メールを受信することが可能なドメインにレポートを送信して、希望する外部の送信先にレポートを自動転送させることである。
Note that the addresses shown in the “ruf” tag receive more
information that might be considered private data, since it is
possible for actual email content to appear in the failure reports.
The URIs identified there are thus more attractive targets for
intrusion attempts than those found in the “rua” tag. Moreover,
attacking the DNS of the subject domain to cause failure data to be
routed fraudulently to an attacker’s systems may be an attractive
prospect. Deployment of [DNSSEC] is advisable if this is a concern.
実際の電子メールの内容が失敗レポートに現れる可能性があるため、「ruf」タグに示すアドレスは、プライベートデータとみなされる情報をさらに受信することに留意していただきたい。その結果、「ruf」タグで特定されたURIは、「rua」タグに存在するURIより魅力のある侵入対象となる。さらに、対象のドメインのDNSを攻撃して異常データを攻撃者のシステムに不正に転送することは、魅力的な可能性となりうる。これを懸念するのであれば、DNSSECの展開が望ましい。
The verification mechanism presented in Section 7.1 is currently not
mandatory (“MUST”) but strongly recommended (“SHOULD”). It is
possible that it would be elevated to a “MUST” by later security
review.
7.1節に記載する検証メカニズムは、現在のところ必須(「しなければならない(MUST)」)ではないが、強く推奨する(「するべきである(SHOULD)」)。今後のセキュリティの検討次第では、「しなければならない(MUST)」となる可能性がある。
12.6. Secure Protocols
This document encourages use of secure transport mechanisms to
prevent loss of private data to third parties that may be able to
monitor such transmissions. Unencrypted mechanisms should be
avoided.
12.6. 保護プロトコル
本文書では、その送信を監視可能なサードパーティが、プライベートデータが損失しないために、安全な送信メカニズムを使用することを推奨する。非暗号化メカニズムは、避けるべきである。
[Page 48]
| 《PREV》 |