draft-schlitt-spf-classic-02.txt

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

6.2.  exp: Explanation

   explanation      = "exp" "=" domain-spec

   If check_host() results in a "Fail" due to a mechanism match (such as
   "-all"), and the "exp" modifier is present, then the explanation
   string returned is computed as described below.  If no "exp" modifier
   is present, then either a default explanation string or an empty
   explanation string may be returned.

   The <domain-spec> is macro expanded (see Section 8) and becomes the
   <target-name>.  The DNS TXT record for the <target-name> is fetched.

   If <domain-spec> is empty, or there are any DNS processing errors
   (any RCODE other than 0), or if no records are returned, or if more
   than one record is returned, or if there are syntax errors in the
   explanation string, then proceed as if no exp modifier was given.

   The fetched TXT record's strings are concatenated with no spaces, and
   then treated as an <explain-string> which is macro-expanded.  This
   final result is the explanation string.  Implementations MAY limit
   the length of the resulting explanation string to allow for other
   protocol constraints and/or reasonable processing limits.  Since the
   explanation string is intended for an SMTP response and [RFC2821]
   section 2.4 says that responses are in [US-ASCII], the explanation
   string is also limited to US-ASCII.

   Software evaluating check_host() can use this string to communicate
   information from the publishing domain in the form of a short message
   or URL.  Software SHOULD make it clear that the explanation string
   comes from a third party.  For example, it can prepend the macro
   string "%{o} explains: " to the explanation, such as shown in
   Section 2.5.4.

   Suppose example.com has this record:

      v=spf1 mx -all exp=explain._spf.%{d}

   Here are some examples of possible explanation TXT records at



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


   explain._spf.example.com:
      "Mail from example.com should only be sent by its own servers."
         -- a simple, constant message

      "%{i} is not one of %{d}'s designated mail servers."
         -- a message with a little more info, including the IP address
            that failed the check

      "See http://%{d}/why.html?s=%{S}&i=%{I}"
         -- a complicated example that constructs a URL with the
            arguments to check_host() so that a web page can be
            generated with detailed, custom instructions

   Note: During recursion into an "include" mechanism, an exp= modifier
   from the <target-name> MUST NOT be used.  In contrast, when executing
   a "redirect" modifier, an exp= modifier from the original domain MUST
   NOT be used.


































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


7.  The Received-SPF header field

   It is RECOMMENDED that SMTP receivers record the result of SPF
   processing in the message headers.  If an SMTP receiver chooses to do
   so, it SHOULD use the "Received-SPF" header defined here for each
   identity that was checked.  This information is intended for the
   recipient.  (Information intended for the sender is described in
   Section 6.2, Explanation.)

   The Received-SPF header is a trace field (see [RFC2822] section
   3.6.7) and SHOULD be prepended to existing headers, above the
   Received: header that is generated by the SMTP receiver.  It MUST
   appear above any other Received-SPF headers in the message.  The
   header has the format:

   header           = "Received-SPF:" [CFWS] result FWS [comment FWS]
                      [ key-value-list ] CRLF

   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
                      "None" / "TempError" / "PermError"

   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
                      [";"]

   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )

   key              = "client-ip" / "envelope-from" / "helo" /
                      "problem" / "receiver" / "identity" /
                       mechanism / "x-" name / name

   identity         = "mailfrom"   ; for the "MAIL FROM" identity
                      / "helo"     ; for the "HELO" identity
                      / name       ; other identities

   dot-atom         = <unquoted word as per [RFC2822]>
   quoted-string    = <quoted string as per [RFC2822]>
   comment          = <comment string as per [RFC2822]>
   CFWS             = <comment or folding white space as per [RFC2822]>
   FWS              = <folding white space as per [RFC2822]>
   CRLF             = <standard end-of-line token as per [RFC2822]>

   The header SHOULD include a "(...)" style <comment> after the result,
   conveying supporting information for the result, such as <ip>,
   <sender> and <domain>.

   The following key-value pairs are designed for later machine parsing.
   SPF clients SHOULD give enough information so that the SPF results
   can be verified.  That is, at least the "client-ip", "helo", and, if



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


   the "MAIL FROM" identity was checked, the "envelope-from".

   client-ip      the IP address of the SMTP client

   envelope-from  the envelope sender mailbox

   helo           the host name given in the HELO or EHLO command

   mechanism      the mechanism that matched (if no mechanisms matched,
                  substitute the word "default".)

   problem        if an error was returned, details about the error

   receiver       the host name of the SPF client

   identity       the identity that was checked, see the <identity> ABNF
                  rule.

   Other keys may be defined by SPF clients.  Until a new key name
   becomes widely accepted, new key names should start with "x-".

   SPF clients MUST make sure that the Received-SPF header does not
   contain invalid characters, is not excessively long, and does not
   contain malicious data that has been provided by the sender.

   Examples of various header styles that could be generated:

   Received-SPF: Pass (mybox.example.org: domain of
    [e-mail] designates 192.0.2.1 as permitted sender)
       receiver=mybox.example.org; client-ip=192.0.2.1;
       envelope-from=<[e-mail]>; helo=foo.example.com;


   Received-SPF: Fail (mybox.example.org: domain of
                     [e-mail] does not designate
                     192.0.2.1 as permitted sender)
                     identity=mailfrom; client-ip=192.0.2.1;
                     envelope-from=<[e-mail]>;













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


8.  Macros

8.1.  Macro definitions

   Many mechanisms and modifiers perform macro expansion on part of the
   term.

   domain-spec      = macro-string domain-end
   domain-end       = ( "." toplabel ) / macro-expand

   toplabel         = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
                      ; LDH rule (See [RFC3696])
   alphanum         = ALPHA / DIGIT

   explain-string   = *( macro-string / SP )

   macro-string     = *( macro-expand / macro-literal )
   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
                      / "%%" / "%_" / "%-"
   macro-literal    = %x21-24 / %x26-7E
                      ; visible characters except "%"
   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
                      "c" / "r" / "t"
   transformers     = *DIGIT [ "r" ]
   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="

   A literal "%" is expressed by "%%".

      "%_" expands to a single " " space.
      "%-" expands to a URL-encoded space, viz. "%20".

   The following macro letters are expanded in term arguments:

      s = <sender>
      l = local-part of <sender>
      o = domain of <sender>
      d = <domain>
      i = <ip>
      p = the validated domain name of <ip>
      v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
      h = HELO/EHLO domain

   The following macro letters are only allowed in "exp" text:

      c = SMTP client IP (easily readable format)
      r = domain name of host performing the check
      t = current timestamp




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


   A '%' character not followed by a '{', '%', '-', or '_' character is
   a syntax error.  So,

      -exists:%(ir).sbl.spamhaus.example.org

   is incorrect and will cause check_host() to return a "PermError".
   Instead, say

      -exists:%{ir}.sbl.spamhaus.example.org

   Optional transformers are:

      *DIGIT = zero or more digits
      'r'    = reverse value, splitting on dots by default

   If transformers or delimiters are provided, the replacement value for
   a macro letter is split into parts.  After performing any reversal
   operation and/or removal of left-hand parts, the parts are rejoined
   using "." and not the original splitting characters.

   By default, strings are split on "." (dots).  Note that no special
   treatment is given to leading, trailing or consecutive delimiters,
   and so the list of parts may contain empty strings.  Macros may
   specify delimiter characters which are used instead of ".".

   The 'r' transformer indicates a reversal operation: if the client IP
   address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"
   and the macro %{ir} would expand to "1.2.0.192".

   The DIGIT transformer indicates the number of right-hand parts to
   use, after optional reversal.  If a DIGIT is specified, the value
   MUST be nonzero.  If no DIGITs are specified, or if the value
   specifies more parts than are available, all the available parts are
   used.  If the DIGIT was 5, and only 3 parts were available, the macro
   interpreter would pretend the DIGIT was 3.  Implementations MUST
   support at least a value of 128, as that is the maximum number of
   labels in a domain name.

   The "s" macro expands to the <sender> argument.  It is an e-mail
   address with a localpart, an "@" character, and a domain.  The "l"
   macro expands to just the localpart.  The "o" macro expands to just
   the domain part.  Note that these values remain the same during
   recursive and chained evaluations due to "include" and/or "redirect".
   Note also that if the original <sender> had no localpart, the
   localpart was set to "postmaster" in initial processing (see
   Section 4.3).

   For IPv4 addresses, both the "i" and "c" macros expand to the



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


   standard dotted-quad format.

   For IPv6 addresses, the "i" macro expands to a dot-format address; it
   is intended for use in %{ir}.  The "c" macro may expand to any of the
   hexadecimal colon-format addresses specified in [RFC3513] section
   2.2.  It is intended for humans to read.

   The "p" macro expands to the validated domain name of <ip>.  The
   procedure for finding the validated domain name is defined in
   Section 5.5.  If the <domain> is present in the list of validated
   domains, it SHOULD be used.  Otherwise, if a subdomain of the
   <domain> is present, it SHOULD be used.  Otherwise, any name from the
   list may be used.  If there are no validated domain names or if a DNS
   error occurs, the string "unknown" is used.

   The "r" macro expands to the name of the receiving MTA.  This SHOULD
   be a fully qualified domain name, but if one does not exist (as when
   the checking is done by a MUA) or if policy restrictions dictate
   otherwise, the word "unknown" SHOULD be substituted.  The domain name
   may be different than the name found in the MX record that the client
   MTA used to locate the receiving MTA.

   The "t" macro expands to the decimal representation of the
   approximate number of seconds since the Epoch (Midnight, January 1st