> Ok, so back to my question of what should this match:
>
> "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>
> You are saying that it is ok to sometimes give a Pass and sometimes to
> give a Fail?
That is what he said.
> Personally, I would rather not allow for inconsistent SPF results.
> Are there any SPF implementations that will give a pass on this, other
> than Julian's very recent one?
None that I am aware of.
Here is my judgement for the MUTUAL EXCLUSION position:
The language of the RFC says, "*Even* *if* the SMTP connection is via
IPv6, an IPv4 mapped IPv6 address MUST still be considered an
IPv4 address" (emphasis mine). The "even if" tells us to set aside
our natural inclination to regard the connection as IPv6, and regard it
as IPv4 *instead*. If the intention of the RFC was BOTH AND, the word
"even" would have been omitted. Wayne, the composer of the sentence
in question concurs.
Furthermore, the preceding sentence does not allow fetching BOTH
A and AAAA records - which is logically required by the BOTH AND
position. Therefore, the BOTH AND position, while theoretically
attractive from an IPv6 standpoint,
1) is incompatible with IP4 implementations that ignore IP6.
2) is logically inconsistent in matching ip6, but not fetching AAAA.
3) goes against the language of the RFC, specifically the "Even if" phrase.
4) has only one implementation and it was just completed this week.
5) seems to have only one proponent on SPF mailing lists.
The COMPROMISE party position is that implementations may choose whether
ip6:::FFFF:* should match an IP4 address. This position is untenable
because SPF results should be well defined, and not the receivers choice.
The receiver can choose what action to take in consequence, but not
the actual SPF result. Existing alternate results in the test-suite stem
from an explicit MAY or SHOULD in the RFC, or from precisely when DOS limits
are detected. The RFC does not have an explicit MAY or SHOULD for the
BOTH AND position, and IP6 is not a DOS situation.
It is important to nail down this issue since new SPF implementations
will be supporting IPv6. IP6 is gaining momentum in government at least,
and SPF needs to have solid support for it. An ugly, but predictable
IP6 policy is better than a more elegant, but randomly implemented
IP6 policy. So, while BOTH AND would have been prettier if it had
been thought of soon enough, we are stuck with RFC4408. I suggest that
the BOTH AND party make sure that SPFv3 gets it right.
Therefore, as test-suite czar, I declare the MUTUAL EXCLUSION party the
winner, and will remove the alternate (BOTH AND) results from the test
suite. This will likely make the just completed Mail::SPF Perl library
not in compliance, but preserves compliance for all other implementations.
(Unless someone can point out another BOTH AND implementation.)
All opposed, make your final arguments.
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
>
> "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>
> You are saying that it is ok to sometimes give a Pass and sometimes to
> give a Fail?
That is what he said.
> Personally, I would rather not allow for inconsistent SPF results.
> Are there any SPF implementations that will give a pass on this, other
> than Julian's very recent one?
None that I am aware of.
Here is my judgement for the MUTUAL EXCLUSION position:
The language of the RFC says, "*Even* *if* the SMTP connection is via
IPv6, an IPv4 mapped IPv6 address MUST still be considered an
IPv4 address" (emphasis mine). The "even if" tells us to set aside
our natural inclination to regard the connection as IPv6, and regard it
as IPv4 *instead*. If the intention of the RFC was BOTH AND, the word
"even" would have been omitted. Wayne, the composer of the sentence
in question concurs.
Furthermore, the preceding sentence does not allow fetching BOTH
A and AAAA records - which is logically required by the BOTH AND
position. Therefore, the BOTH AND position, while theoretically
attractive from an IPv6 standpoint,
1) is incompatible with IP4 implementations that ignore IP6.
2) is logically inconsistent in matching ip6, but not fetching AAAA.
3) goes against the language of the RFC, specifically the "Even if" phrase.
4) has only one implementation and it was just completed this week.
5) seems to have only one proponent on SPF mailing lists.
The COMPROMISE party position is that implementations may choose whether
ip6:::FFFF:* should match an IP4 address. This position is untenable
because SPF results should be well defined, and not the receivers choice.
The receiver can choose what action to take in consequence, but not
the actual SPF result. Existing alternate results in the test-suite stem
from an explicit MAY or SHOULD in the RFC, or from precisely when DOS limits
are detected. The RFC does not have an explicit MAY or SHOULD for the
BOTH AND position, and IP6 is not a DOS situation.
It is important to nail down this issue since new SPF implementations
will be supporting IPv6. IP6 is gaining momentum in government at least,
and SPF needs to have solid support for it. An ugly, but predictable
IP6 policy is better than a more elegant, but randomly implemented
IP6 policy. So, while BOTH AND would have been prettier if it had
been thought of soon enough, we are stuck with RFC4408. I suggest that
the BOTH AND party make sure that SPFv3 gets it right.
Therefore, as test-suite czar, I declare the MUTUAL EXCLUSION party the
winner, and will remove the alternate (BOTH AND) results from the test
suite. This will likely make the just completed Mail::SPF Perl library
not in compliance, but preserves compliance for all other implementations.
(Unless someone can point out another BOTH AND implementation.)
All opposed, make your final arguments.
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007