Mailing List Archive

Hi!

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 198.179.16.73
>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
><http://www.openspf.org/SPF_Record_Syntax#a>:

Perhaps read the RFC instead.

Section 5.3:

5.3. "a"

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

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


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

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:

5.4. "mx"

This mechanism matches if <ip> is one of the MX hosts for a domain
name.

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

Kind regards,

Hannah.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

On 23 Mar 2010, at 10:42 AM, Hannah Schroeter wrote:

>> I've always figured that was what I wanted for the host SPF
>> record, but reading the description of the "a" mechanism on
>> <http://www.openspf.org/SPF_Record_Syntax#a>:
>
> Perhaps read the RFC instead.

Ah, yes, that was my mistake. I somehow got the impression that the documentation at openspf.org was official.

Thank you very much for your informed analysis and pointers. I feel much better, now.

So, the misleadingly incomplete documentation on the openspf.org site should probably be cleanup up a little. I suspect the maintainer(s) are on this list. Would proposed amended language be helpful?

- Geoff

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

On Tue, Mar 23, 2010 at 15:37, Geoff Adams <gsa-spf2@minos.avernus.com> wrote:
>
> Ah, yes, that was my mistake. I somehow got the impression that the documentation at openspf.org was official.
>
> Thank you very much for your informed analysis and pointers. I feel much better, now.
>
> So, the misleadingly incomplete documentation on the openspf.org site should probably be cleanup up a little. I suspect the maintainer(s) are on this list. Would proposed amended language be helpful?

I think I have access to make changes (I did once, but I haven't used
it in a very long time). Propose changes and I'll see if I can make
changes to make it clearer (I'll also add a note that the RFC is
definitive and that this page is simply a handy guide).

--
Please keep list traffic on the list.

Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

"Geoff Adams" <gsa-spf2@minos.avernus.com> wrote:

>On 23 Mar 2010, at 10:42 AM, Hannah Schroeter wrote:
>
>>> I've always figured that was what I wanted for the host SPF
>>> record, but reading the description of the "a" mechanism on
>>> <http://www.openspf.org/SPF_Record_Syntax#a>:
>>
>> Perhaps read the RFC instead.
>
>Ah, yes, that was my mistake. I somehow got the impression that the documentation at openspf.org was official.
>
>Thank you very much for your informed analysis and pointers. I feel much better, now.
>
>So, the misleadingly incomplete documentation on the openspf.org site should probably be cleanup up a little. I suspect the maintainer(s) are on this list. Would proposed amended language be helpful?

Yes. Please.

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

On 23 Mar 2010, at 1:08 PM, Scott Kitterman wrote:

>> So, the misleadingly incomplete documentation on the openspf.org site should probably be cleanup up a little. I suspect the maintainer(s) are on this list. Would proposed amended language be helpful?
>
> Yes. Please.

OK. I'll put something together, and if Rob MacGregor doesn't beat me to it, I'll submit what I come up with back here.

Thanks,
- Geoff

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com