10.2. SPF-Authorized E-Mail May Contain Other False Identities
The "MAIL FROM" and "HELO" identity authorizations must not be construed to provide more assurance than they do. It is entirely possible for a malicious sender to inject a message using his own domain in the identities used by SPF, to have that domain's SPF record authorize the sending host, and yet the message can easily list other identities in its header. Unless the user or the MUA takes care to note that the authorized identity does not match the other more commonly-presented identities (such as the From: header field), the user may be lulled into a false sense of security.
10.2. SPFで認証された電子メールが他の偽称アイデンティティを持つ可能性
“MAIL FROM”アイデンティティと“HELO”アイデンティティへの権限付与が、それ以上の保証を提供すると解釈してはならない。悪意を持った送信者が、SPFで用いられるアイデンティティに自分自身のドメインを使ってメッセージを送出し、そのドメインのSPFレコードで送信ホストに権限を付与することはまったく可能であり、それでもそのメッセージのヘッダには簡単に他のアイデンティティを入れられる。その権限を持つアイデンティティが他の、より一般的に表示されるアイデンティティ（From:ヘッダフィールドなど）に合致しないことをユーザかMUAで記録するよう心がけない限り、ユーザは偽の安心感にだまされるかもしれない。
10.3. Spoofed DNS and IP Data
There are two aspects of this protocol that malicious parties could exploit to undermine the validity of the check_host() function:
10.3. 偽称されたDNSとIPデータ
このプロトコルには、悪意を持った者が check_host() 関数の評価を弱体化させるために
利用できる点が2つある。o The evaluation of check_host() relies heavily on DNS. A malicious attacker could attack the DNS infrastructure and cause check_host() to see spoofed DNS data, and then return incorrect results. This could include returning "Pass" for an <ip> value where the actual domain's record would evaluate to "Fail". See [RFC3833] for a description of DNS weaknesses.
- check_host() の評価はDNSに大きく依存している。悪意を持った攻撃者はDNSインフラストラクチャを攻撃し、check_host() が偽称されたDNSデータを閲覧して不正確な結果を返すようにさせられるかもしれない。これによって、実際のドメインのレコードなら“Fail”と評価するところで、<ip> 値に“Pass”を返すことができる。DNSの弱点の説明については［RFC3833］を参照のこと。
o The client IP address, <ip>, is assumed to be correct. A malicious attacker could spoof TCP sequence numbers to make mail appear to come from a permitted host for a domain that the attacker is impersonating.
- クライアントIPアドレス、すなわち <ip> は正確だと仮定される。悪意のある攻撃者がTCPシーケンス番号を偽称して、攻撃者が装っているドメインに対して許可されているホストから送られたように見えるようなメールを作るかもしれない。
10.4. Cross-User Forgery
By definition, SPF policies just map domain names to sets of authorized MTAs, not whole E-Mail addresses to sets of authorized users. Although the "l" macro (Section 8) provides a limited way to define individual sets of authorized MTAs for specific E-Mail addresses, it is generally impossible to verify, through SPF, the use of specific E-Mail addresses by individual users of the same MTA.
10.4. ユーザ横断偽称
定義によれば、SPFポリシはドメイン名を権限のあるMTA群にマッピングするだけで、電子メールアドレス全体を権限を持つユーザ群にマッピングするわけではない。“l”マクロ（8章）は、特定の電子メールアドレスに対して権限を持つ個別のMTA群を定義するための限定的な方法を提供するが、SPFを通して同一のMTAの個々のユーザによる特定の電子メールアドレスの使用を検証することは、通常では不可能である。
It is up to mail services and their MTAs to directly prevent cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be restricted to using only those E-Mail addresses that are actually under their control (see [RFC4409], Section 6.1). Another means to verify the identity of individual users is message cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851]).直接的なユーザ横断偽称の防止はメールサービスやそのMTA次第である。SMTP AUTH（［RFC2554］）に基づき、ユーザは実際に自分の制御下にある電子メールアドレスだけを使うように制限されるべきである（［RFC4409］の6.1を参照）。個々のユーザのアイデンティティを検証するもうひとつの方法は、PGP（［RFC2440］）やS/MIME（［RFC3851］）などのメッセージ暗号化である。
[Page 37]
| 《PREV》 |