10.5. Untrusted Information Sources
SPF uses information supplied by third parties, such as the "HELO" domain name, the "MAIL FROM" address, and SPF records. This information is then passed to the receiver in the Received-SPF: trace fields and possibly returned to the client MTA in the form of an SMTP rejection message. This information must be checked for invalid characters and excessively long lines.
10.5. 信頼できない情報源
SPFは、“HELO”ドメイン名や“MAIL FROM”アドレス、SPFレコードなどの、第三者によって提供された情報を使う。これらの情報は次に、Received-SPF:追跡フィールドで受信者に渡され、可能ならSMTP拒否メッセージの形でクライアントMTAに返される。これらの情報については、無効な文字や長すぎる行について検査しなければならない。
When the authorization check fails, an explanation string may be included in the reject response. Both the sender and the rejecting receiver need to be aware that the explanation was determined by the publisher of the SPF record checked and, in general, not the receiver. The explanation may contain malicious URLs, or it may be offensive or misleading.権限検査が失敗した場合、拒絶応答には説明文が含まれるかもしれない。送信者と拒否する受信者の両方が、その説明は検査されるSPFレコードの公開者によって決定されたもので、受信者によって決められたものではないことに注意する必要がある。説明は不正なURLを含んでいたり、攻撃的で読み間違いやすい文章であるかもしれない。
This is probably less of a concern than it may initially seem since such messages are returned to the sender, and the explanation strings come from the sender policy published by the domain in the identity claimed by that very sender. As long as the DSN is not redirected to someone other than the actual sender, the only people who see malicious explanation strings are people whose messages claim to be from domains that publish such strings in their SPF records. In practice, DSNs can be misdirected, such as when an MTA accepts an E-Mail and then later generates a DSN to a forged address, or when an E-Mail forwarder does not direct the DSN back to the original sender.上記のようなメッセージは送信者に返され、その説明文は、まさにその送信者が主張したアイデンティティ中のドメインが公開する送信者ポリシから作られるので、おそらく上記は最初に思われるほど問題ではないのだろう。DSNが実際の送信者以外の誰かにリダイレクトされない限り、悪意のある説明文を見るのは、SPFレコード中でこのような文字列を公開するドメインから出されたとされるメッセージの作者なのである。実際に、MTAが電子メールを受け入れてから後で偽称アドレスへのDSNを生成するようなときや、電子メール転送ソフトウェアがDSNを元の送信者に送り返さない場合には、DSNは間違った宛先に送られるかもしれない。
10.6. Privacy Exposure
Checking SPF records causes DNS queries to be sent to the domain owner. These DNS queries, especially if they are caused by the "exists" mechanism, can contain information about who is sending E-Mail and likely to which MTA the E-Mail is being sent. This can introduce some privacy concerns, which may be more or less of an issue depending on local laws and the relationship between the domain owner and the person sending the E-Mail.
10.6. プライバシーの露出
SPFレコードの検査によって、ドメイン所有者にDNS問い合わせが送られるようになる。これらのDNS問い合わせは、特に“exists”機構によって引き起こされるときには、電子メールを送っている人や電子メールを送っているMTAについての情報を含むことがある。これによってプライバシーに関する不安が起こりうる。この不安は多かれ少なかれ、地元の法律や、ドメイン所有者と電子メールの送信者との関係に依存する問題である。
11. Contributors and Acknowledgements
This document is largely based on the work of Meng Weng Wong and Mark Lentczner. Although, as this section acknowledges, many people have contributed to this document, a very large portion of the writing and editing are due to Meng and Mark.
11. 貢献してくれた人々とお礼の言葉
本文書はMen Weng WongとMark Lentcznerの作業に大きく基づいている。しかし、本章で感謝するように、本文書には多くの人が貢献しており、記述の大部分と編集がMengとMarkによるものだ。
This design owes a debt of parentage to [RMX] by Hadmut Danisch and to [DMP] by Gordon Fecyk. The idea of using a DNS record to check the legitimacy of an E-Mail address traces its ancestry further back through messages on the namedroppers mailing list by Paul Vixie [Vixie] (based on suggestion by Jim Miller) and by David Green [Green].本設計はHadmut Danischの[RMX]とGordon Fecykの[DMP]に由来する。電子メールアドレスの正当性の検査にDNSレコードを使うというアイデアは、Paul Vixie[Vixie](Jim Millerの提案に基づく)とDavid Green[Green]によるnamedroppersメーリングリスト上のメッセージに源を発している。
[Page 38]
《PREV》 |