IAjapanロゴ
有害情報対策ポータルサイト
−迷惑メール対策編−
■ トップ > メール管理者の皆様へ > 技術情報 > RFC翻訳 > RFC4408 (p.23)
サイト紹介 | 新着情報 | 一般利用者の皆様へ | メール管理者の皆様へ | 活動・関連情報
RFC4405
RFC4406
RFC4407
RFC4408
RFC4409
6.1.  redirect: Redirected Query
If all mechanisms fail to match, and a "redirect" modifier is
present, then processing proceeds as follows:

redirect = "redirect" "=" domain-spec

6.1. redirect:問い合わせのリダイレクト

すべての機構が合致に失敗し、“redirect”変更子が存在する場合、処理は以下のように進む:

redirect         = "redirect" "=" domain-spec
The domain-spec portion of the redirect section is expanded as per
the macro rules in Section 8. Then check_host() is evaluated with
the resulting string as the <domain>. The <ip> and <sender>
arguments remain the same as current evaluation of check_host().

redirect記述のdomain-spec部分を8章のマクロ規則に則って展開する。check_host() はその結果の文字列を <domain> として評価する。引数 <ip> と <sender> はその前の check_host() 評価と同じである。

The result of this new evaluation of check_host() is then considered
the result of the current evaluation with the exception that if no
SPF record is found, or if the target-name is malformed, the result
is a "PermError" rather than "None".

この新たな check_host() 評価の結果は、その前の評価の結果に、SPFレコードが見つからないかtarget-nameの形式が不正である場合には結果が“None”ではなく“PermError”になる、という例外が追加されたものだと考えられる。

Note that the newly-queried domain may itself specify redirect
processing.

新たに問い合わせられるドメインそのものがリダイレクト処理を定義しているかもしれない。

This facility is intended for use by organizations that wish to apply
the same record to multiple domains. For example:

la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"

この機能は、複数ドメインに同じレコードを適用したい組織による使用を意図している。
たとえば:

  la.example.com. TXT "v=spf1 redirect=_spf.example.com"
  ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
  sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
In this example, mail from any of the three domains is described by
the same record. This can be an administrative advantage.

この例では、3つのドメインのいずれかから来るメールは必ず同じレコードで記述される。これは管理上の利点となりうる。

Note: In general, the domain "A" cannot reliably use a redirect to
another domain "B" not under the same administrative control. Since
the <sender> stays the same, there is no guarantee that the record at
domain "B" will correctly work for mailboxes in domain "A",
especially if domain "B" uses mechanisms involving localparts. An
"include" directive may be more appropriate.

注記:
通常、ドメイン“A”から管理者が同じでない別のドメイン“B”へのリダイレクトの使用は信頼できない。<sender> が同一のままなので、特にドメイン“B”がローカル部分を含む機構を使う場合、ドメイン“B”のレコードがドメイン“A”のメールボックスに対して正しく動作する保証はない。このような場合は“include”指示子の方が適切だろう。

For clarity, it is RECOMMENDED that any "redirect" modifier appear as
the very last term in a record.

念のため、“redirect”変更子はレコード中の一番最後の要素として記述することが推奨される(RECOMMENDED)。

6.2.  exp: Explanation
explanation      = "exp" "=" domain-spec

6.2. exp:説明

explanation      = "exp" "=" domain-spec
If check_host() results in a "Fail" due to a mechanism match (such as
"-all"), and the "exp" modifier is present, then the explanation
string returned is computed as described below. If no "exp" modifier
is present, then either a default explanation string or an empty
explanation string may be returned.

機構の合致検査に対して check_host() が“Fail”の結果になり、“exp”変更子が存在する場合、以下に記述するようにして、返される説明文が生成される。“exp”変更子が存在しない場合は、デフォルトの説明文または空の説明文が返されるだろう。

 

[Page 23]

 

《PREV》
1  4  5  9  12  16  22  25  27  31  35  38  39  42  44
《NEXT》
IAjapanについて | 連絡先 | リンク・転載・引用・ロゴ使用について | プライバシーポリシー
 (c) 2001-2009 Internet Association Japan