Page 2

Participants in the Sender-ID experiment need to be aware that the
way Resent-* header fields are used will result in failure to receive
legitimate email when interacting with standards-compliant systems
(specifically automatic forwarders which comply with the standards by
not adding Resent-* headers, and systems which comply with RFC 822
but have not yet implemented RFC 2822 Resent-* semantics).  It would
be inappropriate to advance Sender-ID on the standards track without
resolving this interoperability problem.

Sender-ID実験の参加者は、Resent-*ヘッダフィールドを使う方法では、標準に準拠したシステム（特に、Resent-*ヘッダを追加しない方法で標準に準拠している自動転送器や、RFC822には準拠しているがRFC2822のResent-*セマンティクスを実装していないシステム）との対話時に正しい電子メールを受信できない結果になることに注意が必要だ。

The community is invited to observe the success or failure of the two
approaches during the two years following publication, in order that
a community consensus can be reached in the future.

将来的に意見の一致に至らせるため、インターネットコミュニティに対して、今後の2年間で本RFCの2種類の方法が成功するか失敗するかを観察するよう求める。

Abstract

E-mail on the Internet can be forged in a number of ways.  In
particular, existing protocols place no restriction on what a sending
host can use as the reverse-path of a message or the domain given on
the SMTP HELO/EHLO commands.  This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby a domain may
explicitly authorize the hosts that are allowed to use its domain
name, and a receiving host may check such authorization.

要約

インターネット電子メールは様々な方法で偽称できる。特に、送信ホストがメッセージのReverse-pathやSMTP HELO/EHLOコマンドに記載するドメインに使える対象については、既存プロトコルに制限がない。本文書では、送信者ポリシフレームワーク（SPF）プロトコル第1版について記述する。このプロトコルによって、ドメインは自ドメイン名の使用を許可するホストに明示的に権限を与えられ、受信ホストはその権限を検査できる。

 

Table of Contents

1. Introduction ....................................................4
   1.1. Protocol Status ............................................4
   1.2. Terminology ................................................5
2. Operation .......................................................5
   2.1. The HELO Identity ..........................................5
   2.2. The MAIL FROM Identity .....................................5
   2.3. Publishing Authorization ...................................6
   2.4. Checking Authorization .....................................6
   2.5. Interpreting the Result ....................................7
        2.5.1. None ................................................8
        2.5.2. Neutral .............................................8
        2.5.3. Pass ................................................8
        2.5.4. Fail ................................................8
        2.5.5. SoftFail ............................................9
        2.5.6. TempError ...........................................9
        2.5.7. PermError ...........................................9
3. SPF Records .....................................................9
   3.1. Publishing ................................................10
        3.1.1. DNS Resource Record Types ..........................10
        3.1.2. Multiple DNS Records ...............................11
        3.1.3. Multiple Strings in a Single DNS record ............11
        3.1.4. Record Size ........................................11
        3.1.5. Wildcard Records ...................................11

[Page 2]