the end user might never actually see, which can create a vector
for attack against end users by simply forging a Sender field
containing some identifier that DMARC will like.
エンドユーザーが実際には目にしない識別子にポリシーを適用することを意味することになり、DMARCが要求する何らかの識別子を含むSenderフィールドを偽造するだけで、エンドユーザーへの攻撃の道をつくることができる。
2. Although it is certainly true that this is what the Sender field
is for, its use in this way is also unreliable, making it a poor
candidate for inclusion in the DMARC evaluation algorithm.
3. Allowing multiple ways to discover policy introduces unacceptable
ambiguity into the DMARC evaluation algorithm in terms of which
policy is to be applied and when.
2. メッセージ認証がSenderフィールドの目的であることには一理あるが、このような目的で使用すると信頼性も低く、DMARC判定アルゴリズムに含める対象とはならない。
3. ポリシーを検索する方法が複数可能になると、どのポリシーをいつ適用されるかという点で、DMARC判定アルゴリズムが曖昧となり受け入れられない。
A.4. Domain Existence Test
A common practice among MTA operators, and indeed one documented in
[ADSP], is a test to determine domain existence prior to any more
expensive processing. This is typically done by querying the DNS for
MX, A, or AAAA resource records for the name being evaluated and
assuming that the domain is nonexistent if it could be determined
that no such records were published for that domain name.
A.4. ドメイン存在判定
MTA運用者の中のよく知られているプラクティスで、実際には[ADSP]に記載される方法は、コストのかかる処理の前にドメインの存在を判定することである。これは通常、評価するドメイン名の通常MX、A、またはAAAAリソースレコードをDNSに問い合わせることによって行われ、そのドメイン名に対してそのようなリソースレコードが公開されなかったことが判断できれば、そのドメインが実在しないとみなす。
The original pre-standardization version of this protocol included a
mandatory check of this nature. It was ultimately removed, as the
method’s error rate was too high without substantial manual tuning
and heuristic work. There are indeed use cases this work needs to
address where such a method would return a negative result about a
domain for which reporting is desired, such as a registered domain
name that never sends legitimate mail and thus has none of these
records present in the DNS.
本プロトコルの標準化前の最初のバージョンには、この手の判定を行うことは必須としていた。手動によるチューニングと試行錯誤的な作業をかなり行わない限りは、その方法のエラー率が高くなりすぎたため、結果的にはその判定を削除した。そのような方法によって、正規のメールを一切送信しないためにDNSにこれらのレコードが存在しない登録ドメイン名など、報告を望むドメインについて否定的な結果が返される場合に、この作業により対処する必要がある使用事例が実際には存在する。
A.5. Issues with ADSP in Operation
DMARC has been characterized as a “super-ADSP” of sorts.
Contributors to DMARC have compiled a list of issues associated with
ADSP, gained from operational experience, that have influenced the
direction of DMARC:
A.5. 運用時のADSPの問題
DMARCは、ある種の「super-ADSP」として位置付けられている。
DMARCの貢献者は、運用エクスペリエンスから得たADSPによる問題のリストをまとめ、DMARCの方向性に影響を与えている。
1. ADSP has no support for subdomains, i.e., the ADSP record for
example.com does not explicitly or implicitly apply to
subdomain.example.com. If wildcarding is not applied, then
spammers can trivially bypass ADSP by sending from a subdomain
with no ADSP record.
1. ADSPには、サブドメインのサポートがない。すなわち、example.comのADSPレコードは、明示的にも暗黙的にもsubdomain.example.comに適用しない。ワイルドカードが適用されない場合、スパマーは、ADSPレコードのないサブドメインから送信することによって、ADSPを簡単に迂回させることができる。
[Page 54]
| 《PREV》 |