サイトマップ | 連絡先 | IAjapan TOP
IAjapan 財団法人インターネット協会
有害情報対策ポータルサイト 迷惑メール対策編
  • 一般利用者の皆様へ
  • メール管理者の皆様へ
  • 関連情報
  • サイト紹介

Page 36

When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
there MUST be a limit of no more than 10 MX or PTR RRs looked up and
checked.

“mx”、“ptr”の各機構または %{p} マクロを評価する場合は、検索・検査を行うMXまたはPTR RRの数を10個以下に制限しなければならない(MUST)。

SPF implementations SHOULD limit the total amount of data obtained
from the DNS queries.  For example, when DNS over TCP or EDNS0 are
available, there may need to be an explicit limit to how much data
will be accepted to prevent excessive bandwidth usage or memory usage
and DoS attacks.

SPF実装は、DNS問い合わせから取得するデータの総量を制限すべきである(SHOULD)。たとえば、TCPまたはEDNS0上のDNSが利用できる場合は、過剰な帯域幅またはメモリの使用やDoS攻撃を防ぐため、受け入れるデータ量には明示的な制限が必要かもしれない。

MTAs or other processors MAY also impose a limit on the maximum
amount of elapsed time to evaluate check_host().  Such a limit SHOULD
allow at least 20 seconds.  If such a limit is exceeded, the result
of authorization SHOULD be "TempError".

MTAその他の処理プログラムは、check_host() を評価する最大経過時間量に制限を課してもよい(MAY)。そのような制限は少なくとも20秒を許容すべきである(SHOULD)。そのような制限を超過した場合、認証結果は”TempError”となるべきである(SHOULD)。

Domains publishing records SHOULD try to keep the number of "include"
mechanisms and chained "redirect" modifiers to a minimum.  Domains
SHOULD also try to minimize the amount of other DNS information
needed to evaluate a record.  This can be done by choosing directives
that require less DNS information and placing lower-cost mechanisms
earlier in the SPF record.

レコードを公開するドメインは、“include”機構の数を維持して、“redirect”変更子の連鎖を最低に保つようにすべきである(SHOULD)。ドメインはまた、レコード評価に必要なその他のDNS情報の量を最小にするよう心がけるべきである(SHOULD)。これは、DNS情報をできるだけ要求しない指示子を選び、コストの低い機構をSPFレコードの最初の方に置くことで実現できる。

For example, consider a domain set up as follows:

example.com.      IN MX   10 mx.example.com.
mx.example.com.   IN A    192.0.2.1
a.example.com.    IN TXT  "v=spf1 mx:example.com -all"
b.example.com.    IN TXT  "v=spf1 a:mx.example.com -all"
c.example.com.    IN TXT  "v=spf1 ip4:192.0.2.1 -all"

たとえば、以下のようなドメイン群を想定しよう:

example.com.      IN MX   10 mx.example.com.
mx.example.com.   IN A    192.0.2.1
a.example.com.    IN TXT  "v=spf1 mx:example.com -all"
b.example.com.    IN TXT  "v=spf1 a:mx.example.com -all"
c.example.com.    IN TXT  "v=spf1 ip4:192.0.2.1 -all"
Evaluating check_host() for the domain "a.example.com" requires the
MX records for "example.com", and then the A records for the listed
hosts.  Evaluating for "b.example.com" requires only the A records.
Evaluating for "c.example.com" requires none.

“a.example.com”というドメインに対する check_host() の評価には、“example.com”のMXレコードと評価対象の各ホストに対するAレコードが必要である。“b.example.com”に対する評価はAレコードしか必要でない。“c.example.com”に対する評価は何も必要としない。

However, there may be administrative considerations: using "a" over
"ip4" allows hosts to be renumbered easily.  Using "mx" over "a"
allows the set of mail hosts to be changed easily.

しかし、管理の観点からの考察もあるかもしれない。“ip4”に“a”を使うと簡単に番号を付け替えられる。“a”の代わりに“mx”を使うとメールホスト群を簡単に変更できる。

 

[Page 36]

 

《PREV》
1  4  5  9  12  16  22  25  27  31  35  38  39  42  44

 
リンク・転載・引用・ロゴ使用について | プライバシーポリシー | IAjapanについて | 連絡先