10.2. DNS Load and Caching
DMARC policies are communicated using the DNS and therefore inherit a
number of considerations related to DNS caching. The inherent
conflict between freshness and the impact of caching on the reduction
of DNS-lookup overhead should be considered from the Mail Receiver’s
point of view. Should Domain Owners publish a DNS record with a very
short TTL, Mail Receivers can be provoked through the injection of
large volumes of messages to overwhelm the Domain Owner’s DNS.
Although this is not a concern specific to DMARC, the implications of
a very short TTL should be considered when publishing DMARC policies.
10.2. DNSの負荷およびキャッシング
DMARCポリシーは、DNSを使用して通信することから、DNSキャッシングに関連する多数の検討事項を引き継ぐことになる。更新とDNSルックアップのオーバヘッドを減らすキャッシングの影響との間の内在する矛盾は、メール受信者の観点から検討するべきである。仮に、ドメイン所有者が、TTLがきわめて短いDNSレコードを公開すると、メール受信者は、ドメイン所有者のDNSを圧倒する大量のメッセージの送信を引き起こす可能性がある。これはDMARCに特有の懸念事項ではないが、DMARCポリシーを公開する場合、TTLをきわめて短くすることの意義を検討するべきである。
Conversely, long TTLs will cause records to be cached for long
periods of time. This can cause a critical change to DMARC
parameters advertised by a Domain Owner to go unnoticed for the
length of the TTL (while waiting for DNS caches to expire). Avoiding
this problem can mean shorter TTLs, with the potential problems
described above. A balance should be sought to maintain
responsiveness of DMARC preference changes while preserving the
benefits of DNS caching.
反対に、TTLが長いと、長期間レコードをキャッシュすることになる。これにより、ドメイン所有者によって通知されるDMARCパラメータの重要な変更が、TTLの間(DNSキャッシュの期限が切れるのを待つ間)は気付かない可能性がある。この問題を避けるには、TTLを短くすることが重要であるが、この場合は上に記載した問題が潜在することになる。DNSキャッシングの便益を保持しながら、DMARCのプリファレンス変更の応答性を維持するためにバランスを求めるべきである。
10.3. Rejecting Messages
This proposal calls for rejection of a message during the SMTP
session under certain circumstances. This is preferable to
generation of a Delivery Status Notification ([DSN]), since
fraudulent messages caught and rejected using DMARC would then result
in annoying generation of such failure reports that go back to the
RFC5321.MailFrom address.
10.3. メッセージ拒否
この提案では、ある特定の状況下でSMTPセッション中に、メッセージの拒否を要求する。これは、配信ステータス状況通知 ([DSN])を生成するよりも好ましい。というのも、不正メッセージがDMARCを使用して捕捉、拒否されると、失敗レポートが作成され、RFC5321.MailFromアドレス宛に返送されて煩わしいからである。
This synchronous rejection is typically done in one of two ways:
o Full rejection, wherein the SMTP server issues a 5xy reply code as
an indication to the SMTP client that the transaction failed; the
SMTP client is then responsible for generating notification that
delivery failed (see Section 4.2.5 of [SMTP]).
o A “silent discard”, wherein the SMTP server returns a 2xy reply
code implying to the client that delivery (or, at least, relay)
was successfully completed, but then simply discarding the message
with no further action.
この同期拒否は通常、以下の2つのうちのどちらかの方法によって行われる。
o 完全拒否：SMTPサーバーは、5xy応答コードを発行して、トランザクションに失敗したことをSMTPクライアントに示す。SMTPクライアントはその際、配信失敗通知を生成する役割を担う([SMTP]の4.2.5節を参照)。
o 「サイレント破棄」：SMTPサーバーはその配信(少なくともリレー)が無事に完了したことを意味する2xy応答コードをクライアントに返すが、メッセージをそれ以上処理しないで単に破棄する。
Each of these has a cost. For instance, a silent discard can help to
prevent backscatter, but it also effectively means that the SMTP
server has to be programmed to give a false result, which can
confound external debugging efforts.
これらにはそれぞれ、代償がある。例えば、サイレント破棄は、後続処理への影響を防ぐのに有用であるが、SMTPサーバーには、間違った結果を与えるようにプログラムしなければならないことを事実上意味し、外部からのデバッグの努力を複雑にする可能性がある。
[Page 40]
| 《PREV》 |