view release on metacpan or  search on metacpan

extra_docs/rfc4408.txt  view on Meta::CPAN

      include

   Designated sender mechanisms are used to designate a set of <ip>
   addresses as being permitted or not permitted to use the <domain> for
   sending mail.

      a
      mx
      ptr
      ip4
      ip6
      exists

   The following conventions apply to all mechanisms that perform a
   comparison between <ip> and an IP address at any point:

   If no CIDR-length is given in the directive, then <ip> and the IP
   address are compared for equality. (Here, CIDR is Classless Inter-
   Domain Routing.)

   If a CIDR-length is specified, then only the specified number of
   high-order bits of <ip> and the IP address are compared for equality.

   When any mechanism fetches host addresses to compare with <ip>, when
   <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
   address, AAAA records are fetched.  Even if the SMTP connection is
   via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
   2.5.5) MUST still be considered an IPv4 address.

   Several mechanisms rely on information fetched from DNS.  For these
   DNS queries, except where noted, if the DNS server returns an error
   (RCODE other than 0 or 3) or the query times out, the mechanism
   throws the exception "TempError".  If the server returns "domain does
   not exist" (RCODE 3), then evaluation of the mechanism continues as
   if the server returned no error (RCODE 0) and zero answer records.

5.1.  "all"

   all              = "all"

   The "all" mechanism is a test that always matches.  It is used as the
   rightmost mechanism in a record to provide an explicit default.

   For example:

      v=spf1 a mx -all

   Mechanisms after "all" will never be tested.  Any "redirect" modifier
   (Section 6.1) has no effect when there is an "all" mechanism.

5.2.  "include"

      include          = "include"  ":" domain-spec

   The "include" mechanism triggers a recursive evaluation of
   check_host().  The domain-spec is expanded as per Section 8.  Then
   check_host() is evaluated with the resulting string as the <domain>.
   The <ip> and <sender> arguments remain the same as in the current
   evaluation of check_host().

   In hindsight, the name "include" was poorly chosen.  Only the
   evaluated result of the referenced SPF record is used, rather than
   acting as if the referenced SPF record was literally included in the
   first.  For example, evaluating a "-all" directive in the referenced
   record does not terminate the overall processing and does not
   necessarily result in an overall "Fail".  (Better names for this
   mechanism would have been "if-pass", "on-pass", etc.)

   The "include" mechanism makes it possible for one domain to designate
   multiple administratively-independent domains.  For example, a vanity
   domain "example.net" might send mail using the servers of
   administratively-independent domains example.com and example.org.

   Example.net could say

      IN TXT "v=spf1 include:example.com include:example.org -all"

   This would direct check_host() to, in effect, check the records of
   example.com and example.org for a "Pass" result.  Only if the host
   were not permitted for either of those domains would the result be
   "Fail".

   Whether this mechanism matches, does not match, or throws an
   exception depends on the result of the recursive evaluation of
   check_host():

   +---------------------------------+---------------------------------+
   | A recursive check_host() result | Causes the "include" mechanism  |
   | of:                             | to:                             |
   +---------------------------------+---------------------------------+
   | Pass                            | match                           |
   |                                 |                                 |
   | Fail                            | not match                       |
   |                                 |                                 |
   | SoftFail                        | not match                       |
   |                                 |                                 |
   | Neutral                         | not match                       |
   |                                 |                                 |
   | TempError                       | throw TempError                 |
   |                                 |                                 |
   | PermError                       | throw PermError                 |
   |                                 |                                 |
   | None                            | throw PermError                 |
   +---------------------------------+---------------------------------+

   The "include" mechanism is intended for crossing administrative
   boundaries.  Although it is possible to use includes to consolidate
   multiple domains that share the same set of designated hosts, domains
   are encouraged to use redirects where possible, and to minimize the
   number of includes within a single administrative domain.  For
   example, if example.com and example.org were managed by the same
   entity, and if the permitted set of hosts for both domains was
   "mx:example.com", it would be possible for example.org to specify
   "include:example.com", but it would be preferable to specify
   "redirect=example.com" or even "mx:example.com".

5.3.  "a"

   This mechanism matches if <ip> is one of the <target-name>'s IP
   addresses.