hannah at schlund
Mar 23, 2010, 7:42 AM
Post #2 of 6
On Mon, Mar 22, 2010 at 02:13:00PM -0400, Geoff Adams wrote:
>Hello all, and thanks for the help you've been providing folks here.
>I've been using SPF successfully for years now, and I've also been using
>IPv6 for years. But I just recently realized that I may have a problem
>with my SPF records, depending on the definition of the mechanisms.
>In particular, I have the following records for my primary mail host:
>punctilious.kempt.net. IN A 22.214.171.124
>punctilious.kempt.net. IN AAAA 2001:470:e05c:2::c0ff:ee:2
>punctilious.kempt.net. IN TXT "v=spf1 a -all"
>I've always figured that was what I wanted for the host SPF
>record, but reading the description of the "a" mechanism on
Perhaps read the RFC instead.
This mechanism matches if <ip> is one of the <target-name>'s IP
A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
An address lookup is done on the <target-name>. The <ip> is compared
to the returned address(es). If any address matches, the mechanism
And for the general definition of what is to be done for "address
lookup", see the general language at the beginning of section 5:
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-
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.
So the SPF implementation never has to lookup *both* IPv4 *and* IPv6
addresses, but can decide based on the type of the client connection.
But it *has* to handle IPv6 for a "true" (not IPv4 mapped) IPv6
connection, i.e. a: has to lookup AAAA then, and the same for the
address lookup after the MX lookup for the mx: mechanism.
>I guess I always thought of "a" as "address," including both IPv4 and
>IPv6 addresses, but the documentation quoted above specifically mentions
>the A record, which of course is the IPv4 half of that.
The RFC says you're basically right.
>avernus.com. IN TXT "v=spf1 mx a:mail.fgm.com -all"
>There, I use the "mx" mechanism (the a:mail.fgm.com is a simple case,
>since it only has an IPv4 address), and two of the three MX hosts
>involved have an IPv4 address as well as at least one IPv6 address. I
>know I could simply specify all those addresses using "ip4" and "ip6"
>mechanisms and reduce DNS traffic in the process, but, especially with
>IPv6, the addresses are very long, numerous, and subject to change every
>once in a while. I don't want to end up with an out-of-date SPF record.
Same as above. You still might be better off with ip4 and ip6, as that
saves DNS lookups, but mx and a have to work for conforming SPF
implementations for IPv6 too.
>The "mx" mechanism specifies:
The RFC says in section 5.4:
This mechanism matches if <ip> is one of the MX hosts for a domain
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
check_host() first performs an MX lookup on the <target-name>. Then
it performs an address lookup on each MX name returned. The <ip> is
compared to each returned IP address. To prevent Denial of Service
(DoS) attacks, more than 10 MX names MUST NOT be looked up during the
evaluation of an "mx" mechanism (see Section 10). If any address
matches, the mechanism matches.
Note regarding implicit MXs: If the <target-name> has no MX records,
check_host() MUST NOT pretend the target is its single MX, and MUST
NOT default to an A lookup on the <target-name> directly. This
behavior breaks with the legacy "implicit MX" rule. See [RFC2821],
Section 5. If such behavior is desired, the publisher should specify
an "a" directive.
The general language about address lookups for the purpose of comparing
IP addresses applies here, too, in my eyes.
>[... quote from non-normative documentation deleted ...]
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com