9.2. Mailing Lists
Mailing lists must be aware of how they re-inject mail that is sent to the list. Mailing lists MUST comply with the requirements in [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that the reverse-path MUST be changed to be the mailbox of a person or other entity who administers the list. Whereas the reasons for changing the reverse-path are many and long-standing, SPF adds enforcement to this requirement.
9.2. メーリングリスト
メーリングリストは、自らが再送出したメールがリストに送られる方法に注意を払わなければならない。メーリングリストは［RFC2821］の3.10、および［RFC1123］の5.3.6で規定されている、また、reverse-pathをリスト管理者のメールボックスに変更しなければならないという要求に準拠しなければならない（MUST）。reverse-pathを変更する理由は数多く長年に渡るものだが、SPFはこの要求にさらに理由を付け加える。
In practice, almost all mailing list software in use already complies with this requirement. Mailing lists that do not comply may or may not encounter problems depending on how access to the list is restricted. Such lists that are entirely internal to a domain (only people in the domain can send to or receive from the list) are not affected.実際には、使われているほとんどすべてのメーリングリストソフトウェアがすでにこの要求に準拠している。準拠していないメーリングリストに問題が起こるかどうかは、メーリングリストへのアクセスを制限する方法によって異なる。完全にドメイン内用のメーリングリスト（ドメイン内の人だけがリストの送信/受信可能）には問題は起きないだろう。
9.3. Forwarding Services and Aliases
Forwarding services take mail that is received at a mailbox and direct it to some external mailbox. At the time of this writing, the near-universal practice of such services is to use the original "MAIL FROM" of a message when re-injecting it for delivery to the external mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" rather than a "mail list". This means that the external mailbox's MTA sees all such mail in a connection from a host of the forwarding service, and so the "MAIL FROM" identity will not, in general, pass authorization.
9.3. 転送サービスとエイリアス
転送サービスは、メールボックスに受信したメールを何らかの外部メールボックスに向けて送る。本文書執筆時点では、このようなサービスはほぼ世界中で、外部メールボックスに向けての再送出時にメッセージの元の“MAIL FROM”を使う方法をとっている。［RFC1123］と［RFC2821］では、この動作を「メーリングリスト」ではなく「エイリアス」と呼んでいる。これはすなわち、外部メールボックスのMTAが転送サービスホストからの接続で出会うのはすべてそのようなメールである、ということであり、それゆえ一般に“MAIL FROM”アイデンティティは認証を通らない。
There are three places that techniques can be used to ameliorate this problem.この問題を改善するために対処できるタイミングは3箇所ある。
1. The beginning, when E-Mail is first sent.1. "Neutral" results could be given for IP addresses that may be forwarders, instead of "Fail" results. For example: "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org? all"1. 最初、電子メールが初めて送られるとき。
- 転送プログラムかもしれないIPアドレスに対して、“Fail”という結果ではなく、“Neutral”という結果を与えることができるだろう:
"v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"This would cause a lookup on an anti-spam DNS blacklist (DNSBL) and cause a result of "Fail" only for E-Mail coming from listed sources. All other E-Mail, including E-Mail sent through forwarders, would receive a "Neutral" result. By checking the DNSBL after the known good sources, problems with incorrect listing on the DNSBL are greatly reduced.上記のレコードは、反スパムDNSブラックリスト（DNSBL）上の検索を引き起こし、リストに載っている送信元から来た電子メールだけを“Fail”という結果にするだろう。他の電子メールはすべて、転送プログラムを通って送られる電子メールを含め、“Neutral”という結果を受け取る。DNSBLの検査を既知の信頼できる送信元の後に行えば、DNSBLに間違って記載されているドメインに関する問題が大きく減少する。
[Page 32]
| 《PREV》 |