draft-schlitt-spf-classic-02.txt

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

   reliable.  At least the "MAIL FROM" identity MUST be checked, but it
   is RECOMMENDED that the "HELO" identity also be checked beforehand.

   Without explicit approval of the domain owner, checking other
   identities against SPF version 1 records is NOT RECOMMENDED because
   there are cases that are known to give incorrect results.  For
   example, almost all mailing lists rewrite the "MAIL FROM" identity
   (see Section 9.2), but some do not change any other identities in the
   message.  The scenario described in Section 9.3.1.2 is another
   example.  Documents that define other identities should define the
   method for explicit approval.

   It is possible that mail receivers will use the SPF check as part of
   a larger set of tests on incoming mail.  The results of other tests
   may influence whether or not a particular SPF check is performed.
   For example, finding the sending host's IP address on a local white
   list may cause all other tests to be skipped and all mail from that
   host to be accepted.

   When a mail receiver decides to perform an SPF check, it MUST use a
   correctly-implemented check_host() function (Section 4) evaluated
   with the correct parameters.  While the test as a whole is optional,
   once it has been decided to perform a test it must be performed as
   specified so that the correct semantics are preserved between
   publisher and receiver.

   To make the test, the mail receiver MUST evaluate the check_host()
   function with the arguments set as follows:

   <ip>     - the IP address of the SMTP client that is emitting the
            mail, either IPv4 or IPv6.






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


   <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.

   <sender> - the "MAIL FROM" or "HELO" identity.

   Note that the <domain> argument may not be a well-formed domain name.
   For example, if the reverse-path was null, then the EHLO/HELO domain
   is used, with its associated problems (see Section 2.1).  In these
   cases, check_host() is defined in Section 4.3 to return a "None"
   result.

   While invalid, malformed, or non-existent domains cause SPF checks to
   return "None" because no SPF record can be found, it has long been
   the policy of many MTAs to reject e-mail from such domains,
   especially in the case of invalid "MAIL FROM".  In order to prevent
   the circumvention of SPF records, rejecting e-mail from invalid
   domains should be considered.

   Implementations must take care to correctly extract the <domain> from
   the data given with the SMTP MAIL FROM command as many MTAs will
   still accept such things as source routes (see [RFC2821] appendix C),
   the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).  These
   archaic features have been maliciously used to bypass security
   systems.

2.5.  Interpreting the Result

   This section describes how software that performs the authorization
   should interpret the results of the check_host() function.  The
   authorization check SHOULD be performed during the processing of the
   SMTP transaction that sends the mail.  This allows errors to be
   returned directly to the sending server by way of SMTP replies.

   Performing the authorization after the SMTP transaction has finished
   may cause problems, such as: 1) It may be difficult to accurately
   extract the required information from potentially deceptive headers.
   2) Legitimate e-mail may fail because the sender's policy may have
   since changed.

   Generating non-delivery notifications to forged identities that have
   failed the authorization check is generally abusive and against the
   explicit wishes of the identity owner.

2.5.1.  None

   A result of "None" means that no records were published by the
   domain, or that no checkable sender domain could be determined from
   the given identity.  The checking software cannot ascertain whether
   the client host is authorized or not.



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


2.5.2.  Neutral

   The domain owner has explicitly stated that they cannot or do not
   want to assert whether the IP address is authorized or not.  A
   "Neutral" result MUST be treated exactly like the "None" result; the
   distinction exists only for informational purposes.  Treating
   "Neutral" more harshly than "None" will discourage domain owners from
   testing the use of SPF records (see Section 9.1).

2.5.3.  Pass

   A "Pass" result means that the client is authorized to inject mail
   with the given identity.  The domain can now, in the sense of
   reputation, be considered responsible for sending the message.
   Further policy checks can now proceed with confidence in the
   legitimate use of the identity.

2.5.4.  Fail

   A "Fail" result is an explicit statement that the client is not
   authorized to use the domain in the given identity.  The checking
   software can choose to mark the mail based on this, or to reject the
   mail outright.

   If the checking software chooses to reject the mail during the SMTP
   transaction, then it SHOULD use an SMTP reply code of 550 (see
   [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
   (DSN) code (see [RFC3464]), in addition to an appropriate reply text.
   The check_host() function may return either a default explanation
   string, or one from the domain that published the SPF records (see
   Section 6.2).  If the information doesn't originate with the checking
   software, it should be made clear that the text is provided by the
   sender's domain.  For example:

       550-5.7.1 SPF MAIL FROM check failed:
       550-5.7.1 The domain example.com explains:
       550 5.7.1 Please see http://www.example.com/mailpolicy.html

2.5.5.  SoftFail

   A "SoftFail" result should be treated as somewhere between a "Fail"
   and a "Neutral".  The domain believes the host isn't authorized but
   isn't willing to make that strong of a statement.  Receiving software
   SHOULD NOT reject the message based solely on this result, but MAY
   subject the message to closer scrutiny than normal.

   The domain owner wants to discourage the use of this host and so they
   desire limited feedback when a "SoftFail" result occurs.  For



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


   example, the recipient's MUA could highlight the "SoftFail" status,
   or the receiving MTA could give the sender a message using a
   technique called "greylisting" whereby the MTA can issue an SMTP
   reply code of 451 (4.3.0 DSN code) with a note the first time the
   message is received, but accept it the second time.

2.5.6.  TempError

   A "TempError" result means that the SPF client encountered a
   transient error while performing the check.  Checking software can
   choose to accept or temporarily reject the message.  If the message
   is rejected during the SMTP transaction for this reason, the software
   SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
   code.

2.5.7.  PermError

   A "PermError" result means that the domain's published records
   couldn't be correctly interpreted.  This signals an error condition
   that requires manual intervention to be resolved, as opposed to the
   TempError result.  Be aware that if the domain owner uses macros
   (Section 8), it is possible that this result is due to the checked
   identities having an unexpected format.




























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


3.  SPF Records

   An SPF record is a DNS Resource Record (RR) that declares which hosts
   are, and are not, authorized to use a domain name for the "HELO" and
   "MAIL FROM" identities.  Loosely, the record partitions all hosts
   into permitted and not-permitted sets.  (Though some hosts might fall
   into neither category.)

   The SPF record is a single string of text.  An example record is:

      v=spf1 +mx a:colo.example.com/28 -all

   This record has a version of "spf1" and three directives: "+mx",
   "a:colo.example.com/28" (the + is implied), and "-all".

3.1.  Publishing

   Domain owners wishing to be SPF compliant must publish SPF records
   for the hosts that are used in the "MAIL FROM" and "HELO" identities.
   The SPF records are placed in the DNS tree at the host name it
   pertains to, not a subdomain under it, such as is done with SRV
   records.  This is the same whether the TXT or SPF RR type is used.

   The example above in Section 3 might be published via this lines in a
   domain zone file:

      example.com.          TXT "v=spf1 +mx a:colo.example.com/28 -all"
      smtp-out.example.com. TXT "v=spf1 a -all"

   When publishing via TXT records, beware of other TXT records
   published there for other purposes.  They may cause problems with
   size limits (see Section 3.1.4).

3.1.1.  DNS Resource Record Types

   This document defines a new DNS RR of type SPF, type code to be
   determined.  The format of this type is identical to the TXT RR
   [RFC1035].  For either type, the character content of the record is
   encoded as [US-ASCII].

   RFC Editor Note: Please add the DNS RR type code once it has been
   allocated by the IANA.

   It is recognized that the current practice (using a TXT record) is
   not optimal, but it is necessary because there are a number of DNS
   server and resolver implementations in common use that cannot handle
   the new RR type.  The two-record-type scheme provides a forward path
   to the better solution of using an RR type reserved for this purpose.



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


   An SPF-compliant domain name SHOULD have SPF records of both RR
   types.  A compliant domain name MUST have a record of at least one
   type.  If a domain has records of both types, they MUST have
   identical content.  For example, instead of just publishing one
   record as in Section 3.1 above, it is better to publish:

      example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
      example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"

   Example RRs in this document are shown with the TXT record type,
   however they could be published with the SPF type or with both types.

3.1.2.  Multiple DNS Records

   A domain name MUST NOT have multiple records that would cause an
   authorization check to select more than one record.  See Section 4.5
   for the selection rules.

3.1.3.  Multiple Strings in a Single DNS record

   As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
   record (either TXT and SPF RR types) can be composed of more than one
   string.  If a published record contains multiple strings, then the
   record MUST be treated as if those strings are concatenated together
   without adding spaces.  For example:

      IN TXT "v=spf1 .... first" "second string..."

   MUST be treated as equivalent to

      IN TXT "v=spf1 .... firstsecond string..."

   SPF or TXT records containing multiple strings are useful in order to
   construct records which would exceed the 255 byte maximum length of a
   string within a single TXT or SPF RR record.

3.1.4.  Record Size

   The published SPF record for a given domain name SHOULD remain small
   enough that the results of a query for it will fit within 512 octets.
   This will keep even older DNS implementations from falling over to
   TCP.  Since the answer size is dependent on many things outside the
   scope of this document, it is only possible to give this guideline:
   If the combined length of the DNS name and the text of all the
   records of a given type (TXT or SPF) is under 450 characters, then
   DNS answers should fit in UDP packets.  Note that when computing the
   sizes for queries of the TXT format, one must take into account any
   other TXT records published at the domain name.  Records that are too



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


   long to fit in a single UDP packet MAY be silently ignored by SPF
   clients.

3.1.5.  Wildcard Records

   Use of wildcard records for publishing is not recommended.  Care must
   be taken if wildcard records are used.  If a domain publishes
   wildcard MX records, it may want to publish wildcard declarations,
   subject to the same requirements and problems.  In particular, the
   declaration must be repeated for any host that has any RR records at
   all, and for subdomains thereof.  For example, the example given in
   [RFC1034], Section 4.3.3, could be extended with:

       X.COM.          MX      10      A.X.COM
       X.COM.          TXT     "v=spf1 a:A.X.COM -all"

       *.X.COM.        MX      10      A.X.COM
       *.X.COM.        TXT     "v=spf1 a:A.X.COM -all"

       A.X.COM.        A       1.2.3.4
       A.X.COM.        MX      10      A.X.COM
       A.X.COM.        TXT     "v=spf1 a:A.X.COM -all"

       *.A.X.COM.      MX      10      A.X.COM
       *.A.X.COM.      TXT     "v=spf1 a:A.X.COM -all"

   Notice that SPF records must be repeated twice for every name within
   the domain: once for the name, and once with a wildcard to cover the
   tree under the name.

   Use of wildcards is discouraged in general as they cause every name