2. The "MAIL FROM" identity could have additional information in
       the localpart that cryptographically identifies the mail as
       coming from an authorized source.  In this case, such an SPF
       record could be used:
 
           "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"

2. “MAIL FROM”アイデンティティによってローカル部分に、そのメールが権限のある送信元から来たと暗号で示す追加情報を入れられるだろう。この場合、以下のようなSPFレコードが使える:

"v=spf1 mx exists:%{l}._spf_verify.%{d} -all"

       Then, a specialized DNS server can be set up to serve the
       _spf_verify subdomain that validates the localpart.  Although
       this requires an extra DNS lookup, this happens only when the
       E-Mail would otherwise be rejected as not coming from a known
       good source.

すると、ローカル部分を検証する_spf_verifyサブドメインを供給するために特殊なDNSサーバを設定できる。これには余分なDNS検索が必要だが、そのようなDNS検索は、電子メールが他の方法では既知の信頼できる送信元から来ていないとして拒否されるような場合にのみ起こる。

       Note that due to the 63-character limit for domain labels,
       this approach only works reliably if the localpart signature
       scheme is guaranteed either to only produce localparts with a
       maximum of 63 characters or to gracefully handle truncated
       localparts.

ドメインラベルの63文字制限のため、この方法が確実に動作するのは、ローカル部分の署名機構が、必ず63文字以下のローカル部分を生成するか、切り詰めたローカル部分を問題なく処理できると保証される場合に限られる。

     3. Similarly, a specialized DNS server could be set up that will
        rate-limit the E-Mail coming from unexpected IP addresses.
 
           "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"

3. 同様に、予期しないIPアドレスから来る電子メールの率を制限するような、特殊なDNSサーバを設定できるだろう。

"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"

    4. SPF allows the creation of per-user policies for special
       cases.  For example, the following SPF record and appropriate
       wildcard DNS records can be used:
 
              "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"

4. SPFによって、特殊な場合に対するユーザ毎のポリシを生成できる。たとえば、以下のSPFレコードと適切なワイルドカードDNSレコードを使える：

"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"

2.  The middle, when E-Mail is forwarded.

    1. Forwarding services can solve the problem by rewriting the
       "MAIL FROM" to be in their own domain.  This means that mail
       bounced from the external mailbox will have to be re-bounced
       by the forwarding service.  Various schemes to do this exist
       though they vary widely in complexity and resource
       requirements on the part of the forwarding service.

2. 中間、電子メールが転送されるとき。

1. 転送サービスは、“MAIL FROM”を自分のドメイン内になるように書き直すことで問題を解決できる。これはすなわち、外部メールボックスから宛先不明で返送されるメールを転送サービスが再返送する必要がある、ということだ。これには様々な機構が存在するが、複雑さや、転送サービス側におけるリソース要求が非常に多様である。

    2. Several popular MTAs can be forced from "alias" semantics to
       "mailing list" semantics by configuring an additional alias
       with "owner-" prepended to the original alias name (e.g., an
       alias of "friends: george@example.com, fred@example.org" would
       need another alias of the form "owner-friends:  localowner").

2. 広く使われているMTAの中には、元のエイリアス名の前に“owner-”という追加エイリアスを設定することで、「エイリアス」セマンティクスを強制的に「メーリングリスト」セマンティクスにできるものがある（たとえば、“friends: george@example.com, fred@example.org”というエイリアスには“owner-friends: localowner”という別のエイリアスが必要となる）。

[Page 33]