draft-schlitt-spf-classic-02.txt

来自「非常好的dns解析软件」· 文本 代码 · 共 1,763 行 · 第 1/5 页

Network Working Group                                            M. Wong
Internet-Draft                                                W. Schlitt
Expires: December 8, 2005                                   June 6, 2005


Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL,
                               version 1
                      draft-schlitt-spf-classic-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 8, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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 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.




Wong & Schlitt          Expires December 8, 2005                [Page 1]

Internet-Draft        Sender Policy Framework (SPF)            June 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  State of this draft  . . . . . . . . . . . . . . . . . . .  4
     1.2.  Protocol Status  . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  The HELO Identity  . . . . . . . . . . . . . . . . . . . .  6
     2.2.  The MAIL FROM Identity . . . . . . . . . . . . . . . . . .  6
     2.3.  Publishing Authorization . . . . . . . . . . . . . . . . .  6
     2.4.  Checking Authorization . . . . . . . . . . . . . . . . . .  7
     2.5.  Interpreting the Result  . . . . . . . . . . . . . . . . .  8
       2.5.1.  None . . . . . . . . . . . . . . . . . . . . . . . . .  8
       2.5.2.  Neutral  . . . . . . . . . . . . . . . . . . . . . . .  9
       2.5.3.  Pass . . . . . . . . . . . . . . . . . . . . . . . . .  9
       2.5.4.  Fail . . . . . . . . . . . . . . . . . . . . . . . . .  9
       2.5.5.  SoftFail . . . . . . . . . . . . . . . . . . . . . . .  9
       2.5.6.  TempError  . . . . . . . . . . . . . . . . . . . . . . 10
       2.5.7.  PermError  . . . . . . . . . . . . . . . . . . . . . . 10
   3.  SPF Records  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.1.  Publishing . . . . . . . . . . . . . . . . . . . . . . . . 11
       3.1.1.  DNS Resource Record Types  . . . . . . . . . . . . . . 11
       3.1.2.  Multiple DNS Records . . . . . . . . . . . . . . . . . 12
       3.1.3.  Multiple Strings in a Single DNS record  . . . . . . . 12
       3.1.4.  Record Size  . . . . . . . . . . . . . . . . . . . . . 12
       3.1.5.  Wildcard Records . . . . . . . . . . . . . . . . . . . 13
   4.  The check_host() Function  . . . . . . . . . . . . . . . . . . 14
     4.1.  Arguments  . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.2.  Results  . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.3.  Initial Processing . . . . . . . . . . . . . . . . . . . . 14
     4.4.  Record Lookup  . . . . . . . . . . . . . . . . . . . . . . 15
     4.5.  Selecting Records  . . . . . . . . . . . . . . . . . . . . 15
     4.6.  Record Evaluation  . . . . . . . . . . . . . . . . . . . . 15
       4.6.1.  Term Evaluation  . . . . . . . . . . . . . . . . . . . 16
       4.6.2.  Mechanisms . . . . . . . . . . . . . . . . . . . . . . 16
       4.6.3.  Modifiers  . . . . . . . . . . . . . . . . . . . . . . 17
     4.7.  Default Result . . . . . . . . . . . . . . . . . . . . . . 17
     4.8.  Domain Specification . . . . . . . . . . . . . . . . . . . 17
   5.  Mechanism Definitions  . . . . . . . . . . . . . . . . . . . . 19
     5.1.  "all"  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     5.2.  "include"  . . . . . . . . . . . . . . . . . . . . . . . . 20
     5.3.  "a"  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.4.  "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.5.  "ptr"  . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     5.6.  "ip4" and "ip6"  . . . . . . . . . . . . . . . . . . . . . 23
     5.7.  "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 24
   6.  Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 25
     6.1.  redirect: Redirected Query . . . . . . . . . . . . . . . . 25



Wong & Schlitt          Expires December 8, 2005                [Page 2]

Internet-Draft        Sender Policy Framework (SPF)            June 2005


     6.2.  exp: Explanation . . . . . . . . . . . . . . . . . . . . . 26
   7.  The Received-SPF header field  . . . . . . . . . . . . . . . . 28
   8.  Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     8.1.  Macro definitions  . . . . . . . . . . . . . . . . . . . . 30
     8.2.  Expansion Examples . . . . . . . . . . . . . . . . . . . . 33
   9.  Implications . . . . . . . . . . . . . . . . . . . . . . . . . 34
     9.1.  Sending Domains  . . . . . . . . . . . . . . . . . . . . . 34
     9.2.  Mailing Lists  . . . . . . . . . . . . . . . . . . . . . . 34
     9.3.  Forwarding Services and Aliases  . . . . . . . . . . . . . 34
     9.4.  Mail Services  . . . . . . . . . . . . . . . . . . . . . . 36
     9.5.  MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 37
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 38
     10.1. Processing Limits  . . . . . . . . . . . . . . . . . . . . 38
     10.2. SPF-Authorized E-Mail May Be UBE . . . . . . . . . . . . . 39
     10.3. Spoofed DNS and IP Data  . . . . . . . . . . . . . . . . . 40
     10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 40
     10.5. Untrusted Information Sources  . . . . . . . . . . . . . . 40
     10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 41
   11. Contributors and Acknowledgements  . . . . . . . . . . . . . . 42
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 43
     12.1. The SPF DNS Record Type  . . . . . . . . . . . . . . . . . 43
     12.2. The Received-SPF mail header . . . . . . . . . . . . . . . 43
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 44
     13.2. Informative References . . . . . . . . . . . . . . . . . . 44
   Appendix A.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 46
   Appendix B.  Extended Examples . . . . . . . . . . . . . . . . . . 48
     B.1.  Simple Examples  . . . . . . . . . . . . . . . . . . . . . 48
     B.2.  Multiple Domain Example  . . . . . . . . . . . . . . . . . 49
     B.3.  DNSBL Style Example  . . . . . . . . . . . . . . . . . . . 50
     B.4.  Multiple Requirements Example  . . . . . . . . . . . . . . 50
   Appendix C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 51
     C.1.  Changes in Version -02 . . . . . . . . . . . . . . . . . . 51
     C.2.  Changes in Version -01 . . . . . . . . . . . . . . . . . . 52
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55
   Intellectual Property and Copyright Statements . . . . . . . . . . 56















Wong & Schlitt          Expires December 8, 2005                [Page 3]

Internet-Draft        Sender Policy Framework (SPF)            June 2005


1.  Introduction

   The current e-mail infrastructure has the property that any host
   injecting mail into the mail system can identify itself as any domain
   name it wants.  Hosts can do this at a variety of levels: in
   particular, the session, the envelope, and the mail headers.  While
   this feature is desirable in some circumstances, it is a major
   obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam").
   Furthermore, many domain name holders are understandably concerned
   about the ease with which other entities may make use of their domain
   names, often with malicious intent.

   This document defines a protocol by which domain owners may authorize
   hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
   Compliant domain holders publish SPF records specifying which hosts
   are permitted to use their names, and compliant mail receivers use
   the published SPF records to test the authorization of sending MTAs
   using a given "HELO" or "MAIL FROM" identity during a mail
   transaction.

   An additional benefit to mail receivers is that after the use of an
   identity is verified, local policy decisions about the mail can be
   made based on the sender's domain, rather than the host's IP address.
   This is advantageous because reputation of domain names is likely to
   be more accurate than reputation of host IP addresses.  Furthermore,
   if a claimed identity fails verification, local policy can take
   stronger action against such e-mail, such as rejecting it.

1.1.  State of this draft

   This draft version attempts to resolve all known issues and address
   all comments received from the IESG review of 2005/02/17, as well
   reviews from the namedroppers, ietf-smtp, ietf-822 and spf-discuss
   mailing lists both in January and in May.

   Please check the Change log in Appendix C before proposing changes,
   as it is possible that your idea has already been discussed.  Please
   post comments on the [e-mail] mailing list or
   e-mail them directly to the author.

   I am sorry for the length of this I-D; I have not had time to make it
   shorter.

   RFC Editor Note: Please remove this section for the final publication
   of the document.  It has been inspired by
   draft-ietf-tools-draft-submission-09.txt.





Wong & Schlitt          Expires December 8, 2005                [Page 4]

Internet-Draft        Sender Policy Framework (SPF)            June 2005


1.2.  Protocol Status

   SPF has been in development since the Summer of 2003, and has seen
   deployment beyond the developers beginning in December, 2003.  The
   design of SPF slowly evolved until the spring of 2004 and has since
   stabilized.  There have been quite a number of forms of SPF, some
   written up as documents, some submitted as Internet Drafts, and many
   discussed and debated in development forums.

   The goal of this document is to clearly document the protocol defined
   by earlier draft specifications of SPF as used in existing
   implementations.  This conception of SPF is sometimes called "SPF
   Classic".  It is understood that particular implementations and
   deployments may differ from, and build upon, this work.  It is hoped
   that we have nonetheless captured the common understanding of SPF
   version 1.

1.3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document is concerned with the portion of a mail message
   commonly called "envelope sender", "return path", "reverse path",
   "bounce address", "2821 FROM", or "MAIL FROM".  Since these terms are
   either not well defined, or often used casually, this document
   defines the "MAIL FROM" identity in Section 2.2.  Note that other
   terms that may superficially look like the common terms, such as
   "reverse-path", are used only with the defined meanings from
   normative documents.




















Wong & Schlitt          Expires December 8, 2005                [Page 5]

Internet-Draft        Sender Policy Framework (SPF)            June 2005


2.  Operation

2.1.  The HELO Identity

   The "HELO" identity derives from either the SMTP HELO or EHLO command
   (see [RFC2821]).  These commands supply the SMTP client (sending
   host) for the SMTP session.  Note that requirements for the domain
   presented in the EHLO or HELO command are not always clear to the
   sending party, and SPF clients must be prepared for the "HELO"
   identity to be malformed or an IP address literal.  At the time of
   this writing, many legitimate e-mails are delivered with invalid HELO
   domains.

   It is RECOMMENDED that SPF clients check not only the "MAIL FROM"
   identity, but also separately check the "HELO" identity by applying
   the check_host() function (Section 4) to the "HELO" identity as the
   <sender>.

2.2.  The MAIL FROM Identity

   The "MAIL FROM" identity derives from the SMTP MAIL command (see
   [RFC2821]).  This command supplies the "reverse-path" for a message,
   which generally consists of the sender mailbox, and is the mailbox to
   which notification messages are to be sent if there are problems
   delivering the message.

   [RFC2821] allows the reverse-path to be null (see Section 4.5.5).  In
   this case, there is no explicit sender mailbox, and such a message
   can be assumed to be a notification message from the mail system
   itself.  When the reverse-path is null, this document defines the
   "MAIL FROM" identity to be the mailbox composed of the localpart
   "postmaster" and the "HELO" identity (which may or may not have been
   checked separately before).

   SPF clients MUST check the "MAIL FROM" identity.  SPF clients check
   the "MAIL FROM" identity by applying the check_host() function to the
   "MAIL FROM" identity as the <sender>.

2.3.  Publishing Authorization

   An SPF-compliant domain MUST publish a valid SPF record as described
   in Section 3.  This record authorizes the use of the domain name in
   the "HELO" and "MAIL FROM" identities by the MTAs it specifies.

   If domain owners choose to publish SPF records, it is RECOMMENDED
   that they end in "-all", or redirect to other records that do, so
   that a definitive determination of authorization can be made.




Wong & Schlitt          Expires December 8, 2005                [Page 6]

Internet-Draft        Sender Policy Framework (SPF)            June 2005


   Domain holders may publish SPF records that explicitly authorize no
   hosts if mail should never originate using that domain.

   When changing SPF records, care must be taken to ensure that there is
   a transition period so that the old policy remains valid until all
   legitimate e-mail has been checked.

2.4.  Checking Authorization

   A mail receiver can perform a set of SPF checks for each mail message
   it receives.  An SPF check tests the authorization of a client host
   to emit mail with a given identity.  Typically, such checks are done
   by a receiving MTA, but can be performed elsewhere in the mail
   processing chain so long as the required information is available and