2. Nonexistent subdomains are explicitly out of scope in ADSP.
There is nothing in ADSP that states receivers should simply
reject mail from NXDOMAINs regardless of ADSP policy (which of
course allows spammers to trivially bypass ADSP by sending email
from nonexistent subdomains).
2. 実在しないサブドメインは、ADSPの範囲外であることが明示されている。受信者がADSPポリシーを問わずNXDOMAINからのメールを単に拒否すべきであるという規定は、ADSPには存在しない(当然ながら、スパマーは、実在しないサブドメインから電子メールを送ることによって、ADSPを簡単に迂回させることができる)。
3. ADSP has no operational advice on when to look up the ADSP
record.
4. ADSP has no support for using SPF as an auxiliary mechanism to
DKIM.
5. ADSP has no support for a slow rollout, i.e., no way to configure
a percentage of email on which the receiver should apply the
policy. This is important for large-volume senders.
3. ADSPには、いつADSPレコードを参照するかについて運用上のアドバイスがない。
4. ADSPには、DKIMの補助メカニズムとしてSPFの使用をサポートしていない。
5. ADSPには、ロールアウトに時間をかけることをサポートしていない。すなわち、メール受信者がポリシーを適用すべきである電子メールの割合を設定する方法がない。これは、大量の電子メールの送信者にとって重要である。
6. ADSP has no explicit support for an intermediate phase where the
receiver quarantines (e.g., sends to the recipient’s “spam”
folder) rather than rejects the email.
7. The binding between the “From” header domain and DKIM is too
tight for ADSP; they must match exactly.
6. ADSPは、受信者が電子メールを拒否ではなく検疫する(例えば、受信者の「スパム」フォルダに送信する)中間段階を明示的にサポートしない。
7. 「From」ヘッダードメインとDKIMの間の結び付きがADSPには厳しすぎ、これらは完全一致しなければならない。
A.6. Organizational Domain Discovery Issues
Although protocols like ADSP are useful for “protecting” a specific
domain name, they are not helpful at protecting subdomains. If one
wished to protect “example.com” by requiring via ADSP that all mail
bearing an RFC5322.From domain of “example.com” be signed, this would
“protect” that domain; however, one could then craft an email whose
RFC5322.From domain is “security.example.com”, and ADSP would not
provide any protection. One could use a DNS wildcard, but this can
undesirably interfere with other DNS activity; one could add ADSP
records as fraudulent domains are discovered, but this solution does
not scale and is a purely reactive measure against abuse.
A.6. 組織ドメイン検索の問題
ADSPのようなプロトコルは、特定のドメイン名を「保護」するのに有用であるが、サブドメインの保護には有用でない。ADSPを介してRFC5322.Fromドメインが「example.com」であるすべてのメールに署名を要求して「example.com」を保護したい場合、このドメインは「保護」される。しかし、RFC5322.Fromドメインが「security.example.com」である電子メールが巧妙に作られても、ADSPは全く保護しない。DNSでワイルドカードを使用することができるが、DNSの他の動作が不必要に妨げられることになる。不正なドメインが検索されるようにADSPレコードを加えることが可能であるが、この解決策は、規模が大きくなると利用できなくなり、また不正使用に対しても対処療法でしかない。
The DNS does not provide a method by which the “domain of record”, or
the domain that was actually registered with a domain registrar, can
be determined given an arbitrary domain name. Suggestions have been
made that attempt to glean such information from SOA or NS resource
records, but these too are not fully reliable, as the partitioning of
the DNS is not always done at administrative boundaries.
DNSは、「レコードのドメイン」、つまりドメインレジストラに実際に登録されたドメインを任意のドメイン名として特定できることが可能な方法を提供しない。SOAリソースレコードまたはNSリソースレコードからのそのような情報を収集するのを試みることを提案したが、DNSの分割が常に管理境界で行われないため、完全に信頼できるというわけではない。
When seeking domain-specific policy based on an arbitrary domain
name, one could “climb the tree”, dropping labels off the left end of
the name until the root is reached or a policy is discovered, but
then one could craft a name that has a large number of nonsense
任意のドメイン名に基づくドメイン特有のポリシーを求める場合、ルートに達するか、あるいはポリシーが検索されるまで名前の左端のラベルを落として、「ツリーを登る」ことができるが、意味のないラベルを多数含む名前を巧妙に作ることが可能なので、
[Page 55]
| 《PREV》 |