Hence, MUAs and downstream filters must take some care with use of this header even after possibly malicious headers are scrubbed.
それゆえ、おそらく悪意があると思われるヘッダを削除した後でも、MUAおよび下流フィルタはこのヘッダの使用に注意を払わなければならない。
7.3. Header Field Position
Despite the requirements of [MAIL], header fields can sometimes be reordered enroute by intermediate MTAs. The goal of requiring header field addition only at the top of a message is an acknowledgement that some MTAs do reorder header fields, but most do not. Thus, in the general case, there will be some indication of which MTAs (if any) handled the message after the addition of the header field defined here.
7.3. ヘッダフィールドの位置
[MAIL]での要求にもかかわらず、送信途中の中間MTAでヘッダフィールドの順序が変えられてしまうことがあり得る。ヘッダフィールドの追加はメッセージの一番上にのみとする要求の目的は、一部のMTAはヘッダフィールドの順序替えを行うが、ほとんどのMTAは行わないことの確認だ。それゆえ、通常の場合、ここで定義されるヘッダフィールドの追加後に（もしあるとすれば）どのMTAがメッセージを処理したかが何らかの形で示されているだろう。
7.4. Reverse IP Query Denial-of-Service Attacks
Section 5.5 of [SPF] describes a DNS-based denial-of-service attack for verifiers that attempt DNS-based identity verification of arriving client connections. A verifier wishing to do this check and report this information SHOULD take care not to go to unbounded lengths to resolve “A” and “PTR” queries. MUAs or other filters making use of an “iprev” result specified by this memo SHOULD be aware of the algorithm used by the verifier reporting the result and thus be aware of its limitations.
7.4. 逆引きIP問い合わせサービス拒否攻撃
[SPF]の5.5節では、クライアントから届いた通信を対象として、DNSに基づくアイデンティティ検証を行う検証器に対するDNSに基づくサービス拒否攻撃について記載している。この検査を行って情報を報告しようとする検証器は、“A”問い合わせや“PTR”問い合わせの解決が無限に続かないように注意すべきである(SHOULD)。本文書で定義する“iprev”結果を使用するMUAまたはその他のフィルタは、結果を報告している検証器が使うアルゴリズムを知り、従ってその限界を知るべきである(SHOULD)。
7.5. Mitigation of Backscatter
Failing to follow the instructions of Section 4.2 can result in a denial-of-service attack caused by the generation of [DSN] messages (or equivalent) to addresses that did not send the messages being rejected.
7.5. 後方散乱メールの軽減
4.2節の指示に従うことができないと、拒絶されているメッセージを送信しないアドレスへの[DSN]メッセージ(または同種のメッセージ)の生成によるサービス拒否攻撃につながる可能性がある。
7.6. Internal MTA Lists
Section 5 describes a procedure for scrubbing headers that may contain forged authentication results about a message. A compliant installation will have to include, at each MTA, a list of other MTAs known to be compliant and trustworthy. Failing to keep this list current as internal infrastructure changes may expose an ADMD to attack.
7.6. 内部MTAリスト
5章では、メッセージに関する偽の認証結果を含むかもしれないヘッダを削除する手順を説明している。本文書に準拠したサイトでは各MTAに、本文書に準拠しており信頼できると分かっている他のMTAの一覧が含まれていなければならない。内部インフラストラクチャが変化する際にこの一覧を最新に保たないと、ADMDを攻撃にさらすことになるかもしれない。
7.7. Attacks against Authentication Methods
If an attack becomes known against an authentication method, clearly then the agent verifying that method can be fooled into thinking an inauthentic message is authentic, and thus the value of this header field can be misleading. It follows that any attack against the authentication methods supported by this document (and later amendments to it) is also a security consideration here.
7.7. 認証方式に対する攻撃
ある認証攻撃に対する攻撃が知られるようになった場合、その方式を検証するエージェントがだまされて不正なメッセージを本物だと思い込まされ、それゆえこのヘッダフィールドの値が誤解を与えるものになっている可能性がある。本文書で取り扱う認証方式（および後の修正版）に対する何らかの攻撃も、ここでのセキュリティに関する考察の対象である。
[Page 28]
| 《PREV》 | 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 |