Mailing List Archive

Summary of the controversy:

Paragraph 5/15 says,

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 RFC 3513, Section 2.5.5) MUST still be
considered an IPv4 address.

Party A says this paragraph should be clarified as follows:

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 RFC 3513, Section 2.5.5) MUST still be
considered an IPv4 address, and not as an IPv6 address.

Party B says this paragraph should be clarified as follows:

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 RFC 3513, Section 2.5.5) MUST still be
considered an IPv4 address, as well as an IPv6 address.

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

On Mon, 27 Nov 2006, Stuart D. Gathman wrote:

> Party A says this paragraph should be clarified as follows:
>
> IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
> considered an IPv4 address, and not as an IPv6 address.

The "mutual exclusion" party.

> Party B says this paragraph should be clarified as follows:
>
> IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
> considered an IPv4 address, as well as an IPv6 address.

The "both and" party.

Can people with an opinion let me know which party they currently belong
to? I am currently with the mutual exclusion party.

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

In <Pine.LNX.4.44.0611271432160.23977-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:

> On Mon, 27 Nov 2006, Stuart D. Gathman wrote:
>
>> Party A says this paragraph should be clarified as follows:
>>
>> IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
>> considered an IPv4 address, and not as an IPv6 address.
>
> The "mutual exclusion" party.

This was my understanding while I was editing the I-D. It is still my
understanding that a most, if not almost all, SPF implementations
follow this interpretation. One of my main guiding goals in the
development of the final RFC was to try to be backwards compatible
unless there was a *really* important reason to deviate. In cases
where the various implementations and the various prior specs
conflicted with each other, things weren't as easy to decide.

That said, I never viewed myself as the final word on the I-D and
tried to reach consensus. I would like to see us reach a consensus on
this also. All I'm saying is that when I wrote that sentence, I
thought it was clear enough that the ", and not as an IPv6 address"
part was not needed. I also still think that backwards compatibility
should be an important goal.



The language from the specs:

Paragraph 5/15 of RFC4408 says,

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 RFC 3513, Section 2.5.5) MUST still be
considered an IPv4 address.


Specs prior to draft-schlitt-spf-01 do not mention "IPv4-mapped IPv6
IP addresses" and the above sentence was added at this point. Note
that draft-schlitt-spf-01 was *earlier* than any of the I-Ds that I
submitted to the IETF. When that happened, I had to rename the drafts
to draft-schlitt-spf-classic-00, starting the numbering over again.


draft-lentczner-spf-00 section 4.2 says:

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.


draft-mengwong-spf-0[01] section 4.3 both say:

The following conventions apply to designated sender mechanisms:

If the optional <CIDR-length> is given, then only the upper
<CIDR-length> bits of each IP are compared to the <sending-host>.

If the SMTP connection is IPv6, read "AAAA lookup" for "A lookup",
except where "A" lookups are explicitly specified.



-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Wed, 15 Nov 2006, Julian Mehnle wrote:
> > In the Mail::SPF test-suite driver, I am currently skipping the
> > "cidr6-0-ip4" and "cidr6-ip4" test cases. They assume that IPv4
> > connec- tions must never match the "ip6" mechanism, even if the IPv4
> > connection comes in through an IPv6 interface. I discussed this with
> > Wayne and Scott on #spf extensively, and it seems we cannot agree on a
> > common interpreta- tion of RFC 4408. Here's my rationale:
> >
> > Nowhere does RFC 4408 say that the "ip6" mechanism must not match IPv4
> > addresses. 5/9 saying "Even if the SMTP connection is via IPv6, an
> > IPv4-mapped IPv6 IP address [...] MUST still be considered an IPv4
> > address" doesn't change that.
>
> Why do you make ip4 mapped ip6 connections match IP6, but not A or MX?
> To be consistent, you should fail tests like a-cidr6-0-ip4mapped as
> well:
>
> e2a.example.com:
> - AAAA: 1234::1
> - SPF: v=spf1 a//0 -all
>
> If ip4 mapped connections are considered as *both* ip4 and ip6, then
> they should match the above a//0 mech as well. But your SPF lib
> apparently passes the above test.

You are right. I really should do _both_ "A" and "AAAA" lookups for IPv4-
mapped IPv6 addresses in order to be consistent with my "ip6:" rationale.

However, I need to think more about (1) whether such dual address lookups
can be justified, and (2) whether there's perhaps a conceptual difference
between "ip6:" and "a:" that would justify NOT being consistent in this
regard. I'll let you know where my meditations lead me.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFa1FAwL7PKlBZWjsRAiBgAKCm5KWCe1w5uMcT94jRyt7qV5kGXQCg0Dxj
6BimMO8x0reEvMLykiO+jKg=
=GadF
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Mon, 27 Nov 2006, Stuart D. Gathman wrote:
> > Party A says this paragraph should be clarified as follows:
> >
> > IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST
> > still be considered an IPv4 address, and not as an IPv6 address.
>
> The "mutual exclusion" party.
>
> > Party B says this paragraph should be clarified as follows:
> >
> > IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST
> > still be considered an IPv4 address, as well as an IPv6 address.
>
> The "both and" party.
>
> Can people with an opinion let me know which party they currently belong
> to? I am currently with the mutual exclusion party.

Thanks for your nice summary. Needless to mention, I'm in the "both and"
camp.

As I have said before, I'm certainly not going to request an exclusive
change in the test suite to the end of the "both and" interpretation
because I do see and respect Wayne's intention in writing the I-D. The
original intention cannot and should not be ignored, and thus should
remain valid.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFa1LqwL7PKlBZWjsRAvj3AKCcQ16HECEeQg+qpWD0N1IqZeF6UACgsSbf
qpIRDGiDrpwfZbQK06Sw02U=
=nAQ/
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

On Monday 27 November 2006 14:36, Stuart D. Gathman wrote:
> On Mon, 27 Nov 2006, Stuart D. Gathman wrote:
> > Party A says this paragraph should be clarified as follows:
> >
> > IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still
> > be considered an IPv4 address, and not as an IPv6 address.
>
> The "mutual exclusion" party.
>
> > Party B says this paragraph should be clarified as follows:
> >
> > IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still
> > be considered an IPv4 address, as well as an IPv6 address.
>
> The "both and" party.
>
> Can people with an opinion let me know which party they currently belong
> to? I am currently with the mutual exclusion party.

I'm not sure I care....

The main thing is that IPv4 has to be able to operate in an IPv6 ignorant
manner (modulo not generating errors on the IPv6 mechanisms when they appear
in records). IPv6 needs to understand that IPv4 exists (i.e. the
interoperability burden goes to the new protocol).

What needs to happen is that if I send mail via 72.81.252.18 and I have
ip4:72.81.252.18 in my record (I do) then it MUST match regardless if the
receiver is on an IPv4 or IPv6 network. If an implementer chooses to also
make that match to an equivalent IP6: mechanism, I'm not sure I care. As an
IPv6 ignorant sender I'll never put that in my record.

If I am reading the discussion correctly, this is a distinction that can never
make a difference. Would somebody please explain why we need to argue over
this?

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

In <200611271629.48766.scott@kitterman.com> Scott Kitterman <scott@kitterman.com> writes:

>> Can people with an opinion let me know which party they currently belong
>> to? I am currently with the mutual exclusion party.
>
> I'm not sure I care....
>
> The main thing is that IPv4 has to be able to operate in an IPv6 ignorant
> manner (modulo not generating errors on the IPv6 mechanisms when they appear
> in records). IPv6 needs to understand that IPv4 exists (i.e. the
> interoperability burden goes to the new protocol).

Yes, I agree with this, and I think as a result, this dictates the
mutually exclusive interpretation.


> What needs to happen is that if I send mail via 72.81.252.18 and I have
> ip4:72.81.252.18 in my record (I do) then it MUST match regardless if the
> receiver is on an IPv4 or IPv6 network. If an implementer chooses to also
> make that match to an equivalent IP6: mechanism, I'm not sure I care. As an
> IPv6 ignorant sender I'll never put that in my record.
>
> If I am reading the discussion correctly, this is a distinction that can never
> make a difference. Would somebody please explain why we need to argue over
> this?

The questions are along the lines of:

What should this match:

"v=spf1 ip6:::FFFF:72.81.252.18 -all"

My answer is:

* This should always fail. An ip6: mechanism that lists an
IPv4-mapped IPv6 address is effectively a no-op.


Other possibilities are:

* This should always pass if the connection is from the equivalent of the
IPv4 address of 72.81.252.18, even if the SPF implementation is "IPv6
ignorant".

* This should pass if the SMTP connection came in on an IPv6 socket,
but not if it came in on an IPv4 socket. (This can only happen if
the host is dual-homed in both IPv4 and IPv6 connections.)


As Stuart points out, there may be other cases where treating IPv4
addresses as being appart of the IPv6 space can cause different
results. His example was "a//0" would then have to match all IPv4
addresses, just like "a/0" would.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

In <200611272104.42473.julian@mehnle.net> Julian Mehnle <julian@mehnle.net> writes:

> As I have said before, I'm certainly not going to request an exclusive
> change in the test suite to the end of the "both and" interpretation
> because I do see and respect Wayne's intention in writing the I-D. The
> original intention cannot and should not be ignored, and thus should
> remain valid.

Again, I don't think it should be so much of "what was my intention?",
but rather "what is likely to be the most backwards compatable?".


OH, and to give credit where credit is due, I'm pretty sure it was
Julian that first brought many of the finer points of IPv6 and RFC4408
would be much worse off without his insight and knowledge.


I suspect that Meng, when designing the IPv6 stuff just said "uh, I'm
sure I'm going to need to do stuff here, let's throw in an ip6:
mechanism and an IPv6 CIDR", without giving any really deep thought to
it. I suspect that most implementors, including myself, just said
"uh, if we are dealing with an IPv4 connection, we can ignore all the
IPv6 sutff". I seem to recall asking about "ipv4-mapped" and
"ipv4-compatible" stuff, but not really understanding it.


I'll go dig through the archives to see what stuff I can come up with.



-wayne


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

On Monday 27 November 2006 16:42, wayne wrote:
> In <200611271629.48766.scott@kitterman.com> Scott Kitterman
<scott@kitterman.com> writes:
> >> Can people with an opinion let me know which party they currently belong
> >> to? I am currently with the mutual exclusion party.
> >
> > I'm not sure I care....
> >
> > The main thing is that IPv4 has to be able to operate in an IPv6 ignorant
> > manner (modulo not generating errors on the IPv6 mechanisms when they
> > appear in records). IPv6 needs to understand that IPv4 exists (i.e. the
> > interoperability burden goes to the new protocol).
>
> Yes, I agree with this, and I think as a result, this dictates the
> mutually exclusive interpretation.

I'm still not following on the practical distinction.

> > What needs to happen is that if I send mail via 72.81.252.18 and I have
> > ip4:72.81.252.18 in my record (I do) then it MUST match regardless if the
> > receiver is on an IPv4 or IPv6 network. If an implementer chooses to
> > also make that match to an equivalent IP6: mechanism, I'm not sure I
> > care. As an IPv6 ignorant sender I'll never put that in my record.
> >
> > If I am reading the discussion correctly, this is a distinction that can
> > never make a difference. Would somebody please explain why we need to
> > argue over this?
>
> The questions are along the lines of:
>
> What should this match:
>
> "v=spf1 ip6:::FFFF:72.81.252.18 -all"

My question would be why would this ever appear in a record? If I'm writing
the record from an IPv4 perspective, I'd never put that in. I'd use:

"v=spf1 ip4:72.81.252.18 -all"

So my question is still why do we care if it matches?
>
> My answer is:
>
> * This should always fail. An ip6: mechanism that lists an
> IPv4-mapped IPv6 address is effectively a no-op.

Agreed it's effectively a no-op, but if it's a no-op what does it hurt if it
matches? I can see from an implementation perspective it might be simpler
not to have to make this a special case. If it's easier to implement, why
not?
>
> Other possibilities are:
>
> * This should always pass if the connection is from the equivalent of the
> IPv4 address of 72.81.252.18, even if the SPF implementation is "IPv6
> ignorant".
>
> * This should pass if the SMTP connection came in on an IPv6 socket,
> but not if it came in on an IPv4 socket. (This can only happen if
> the host is dual-homed in both IPv4 and IPv6 connections.)
>
>
> As Stuart points out, there may be other cases where treating IPv4
> addresses as being appart of the IPv6 space can cause different
> results. His example was "a//0" would then have to match all IPv4
> addresses, just like "a/0" would.

I can see that, but I'm equally uncertain of any harm that could result...

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

In <200611271652.08455.scott@kitterman.com> Scott Kitterman <scott@kitterman.com> writes:

>> The questions are along the lines of:
>>
>> What should this match:
>>
>> "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>
> My question would be why would this ever appear in a record? If I'm writing
> the record from an IPv4 perspective, I'd never put that in. I'd use:
>
> "v=spf1 ip4:72.81.252.18 -all"

I suspect that this will change as IPv6 becomes more common. People
will stop thinking in terms of IPv4 and start thinking in terms of
IPv6.

I suspect that as IPv6 becomes more common, you will also get various
errors such as "ip6:0000:1234:5678::/8" instead of
"ip6:0000:1234:5678::/48". If this matches all IPv4 addresses in some
implementations, but is effectively a no-op in others, then this error
will not show up without a lot of testing. Likewise with incorrect
IPv6 cidrs on other mechanisms. I guess maybe our validators should
check this kind of thing and give a warning.


Your point, however, is well taken. If the choice of interpretations
makes no practical difference, then either interpretation is backwards
compatible.

One thing we might do is stress that publishers SHOULD not publish
IPv4-mapped addresses as ip6: mechanisms since it is not clear how all
SPF implementations will interpret them. We have some similar
wordings in RFC4408 already.

> So my question is still why do we care if it matches?

In large part, the test suite is attempting to split hairs and
attempting to give as consistent a defintion of what "SPF" is as can
reasonably be done. I think it is reasonable to try and nail down the
spec as close as we can.



-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

On Mon, 27 Nov 2006, Scott Kitterman wrote:

> What needs to happen is that if I send mail via 72.81.252.18 and I have
> ip4:72.81.252.18 in my record (I do) then it MUST match regardless if the
> receiver is on an IPv4 or IPv6 network. If an implementer chooses to also
> make that match to an equivalent IP6: mechanism, I'm not sure I care. As an
> IPv6 ignorant sender I'll never put that in my record.

IPv4 only senders are safe with either interpretation.

> If I am reading the discussion correctly, this is a distinction that can
> never make a difference. Would somebody please explain why we need to argue
> over this?

So that IP6 senders can get consistent results. If there is no consensus,
then we will have to tell IP6 senders to avoid any IP6, A, or MX mechanisms
that might match ::FFFF:*, otherwise they will get inconsistent results
from receivers. This is unfriendly because it is not always obvious
that the mechanism will match ::FFFF:*.

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

In <x4psb8h88d.fsf@footbone.schlitt.net> wayne <wayne@schlitt.net> writes:

> I suspect that Meng, when designing the IPv6 stuff just said "uh, I'm
> sure I'm going to need to do stuff here, let's throw in an ip6:
> mechanism and an IPv6 CIDR", without giving any really deep thought to
> it. [...]
>
> I'll go dig through the archives to see what stuff I can come up with.


Well, I'm still digging, but I did find this gem:

http://archives.listbox.com/735/200310/0449.html

In it, about three years ago, Meng wrote:

: We need someone to represent IPv6 --- I know nothing about it!

And

: Surely we don't want to have the RFC go through and then three years
: down the road suddenly all the IPv6 people hate us.

yep. three years later, and the IPv6 people hate us. ;-)



-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

On Mon, 27 Nov 2006, wayne wrote:

> > The main thing is that IPv4 has to be able to operate in an IPv6 ignorant
> > manner (modulo not generating errors on the IPv6 mechanisms when they appear
> > in records). IPv6 needs to understand that IPv4 exists (i.e. the
> > interoperability burden goes to the new protocol).
>
> Yes, I agree with this, and I think as a result, this dictates the
> mutually exclusive interpretation.

In case anybody didn't catch it, Wayne and I are not contradicting each
other. Wayne is talking about IP4 only *receivers* evaluating SPF
records that might contain IP6 mechs or reference AAAA RRs. They are likely
ignoring ip6 mechs and ignoring AAAA RRs. If we decide that ip4 mapped
connections are BOTH ip4 AND ip6, then for ip4 only receivers to get
the same results as an IP6 receiver for IP4 connections, they would have to
also treat IP4 connections as ::FFFF:ip4 connections and match
ip6 mechs and look for AAAA records. No legacy implementation does this.
Therefore, the BOTH AND interpretation will break all ip4 only implemtations
(at least when there are IP6,A,MX mechs that match ::FFFF:*).

Julian, that alone should convince you that the mutual exclusion camp
is the only backwards compatible one. Are you ready to change parties?

I was talking about IP4 only *senders*, who are safe as long as they don't
use IP6 or reference any AAAA in A or MX.

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

On Mon, 27 Nov 2006, Stuart D. Gathman wrote:

> ip6 mechs and look for AAAA records. No legacy implementation does this.
> Therefore, the BOTH AND interpretation will break all ip4 only implemtations
> (at least when there are IP6,A,MX mechs that match ::FFFF:*).
>
> Julian, that alone should convince you that the mutual exclusion camp
> is the only backwards compatible one. Are you ready to change parties?

I think most of us will agree that the "both and" interpretation
Would Have Been Nice if it had been put in from the beginning. But backward
compatibility with ip4 implementations that were promised they could "just
ignore" ip6 demands the "mutually exclusive" interpretation - for better or for
worse.

Therefore, ip6:::FFFF:0/96 will never match anything. Ugly, but the
only way to keep our promise to the ip4 only people. (Otherwise, IP4
folks would have to actually parse and interpret ip6 to detect and
match that case.)

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

> -----Original Message-----
> From: wayne [mailto:wayne@schlitt.net]
> Sent: maandag 27 november 2006 22:43
> To: SPF Development
> Subject: Re: [spf-devel] IP4 mapped IP6 connection controversy
>
>
> What should this match:
>
> "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>
> My answer is:
>
> * This should always fail. An ip6: mechanism that lists
> an IPv4-mapped IPv6 address is effectively a no-op.

Purely from a sender perspective, is not the sole purpose of publishing an
ip6 mechanism to indicate that it should only have meaning/relevance on an
IPv6 socket?

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

All fine and dandy. But again, what is the relevance of "seeing" an IPv4
address on an IPv6 connection? The socket-type, IPv4 or IPv6, should
determine which of the namesake mechs has (mutual exclusive) relevance. So
as to say that "v=spf1 ip6:::FFFF:72.81.252.18 -all", while, according to
our RFC, MUST still be considered an IPv4 address, STILL should have no
relevance as IPv4 address in the context of evaluating an ip6 mech on an
IPv6 connection. As if saying: "You have the right key, but you're trying
to open the wrong door with it."

> Other possibilities are:
>
> * This should always pass if the connection is from the
> equivalent of the IPv4 address of 72.81.252.18, ...

I'd say that on an IPv4 socket, matching an IP address via an ip6 mech
that just happens to have an IPv4-mapped IPv6 IP address, is really
questionable. The more cleaner solution were to not evaluate the ip6 mech
on an IPv4 socket at all.

> * This should pass if the SMTP connection came in on an IPv6 socket,
> but not if it came in on an IPv4 socket.

I'd still say that's questionable.

Section 4.6.2 of our RFC ("Mechanisms") says that "Each mechanism is
considered in turn from left to right." So, I don't think RFC 4408 really
allows room to literally skip either ip4 or ip6; but I certainly see
nothing to prevent us from saying that the evaluation of ip6 always
results in "not match" on an IPv4 socket, and vice versa.

- Mark

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark wrote:
> Section 4.6.2 of our RFC ("Mechanisms") says that "Each mechanism is
> considered in turn from left to right." So, I don't think RFC 4408
> really allows room to literally skip either ip4 or ip6; but I certainly
> see nothing to prevent us from saying that the evaluation of ip6 always
> results in "not match" on an IPv4 socket, and vice versa.

I think you're mistaking the nature of "an IPv6 socket". An IPv6 listen
socket can very well accept IPv4 connections. That's exactly when the
listening process sees an IPv4-mapped IPv6 address. This was introduced
to allow applications to use just a single (IPv6) socket (as opposed to
having to use both an IPv4 and an IPv6 socket) and still be able to talk
to IPv4 endpoints. (This is also why I think that, for all intents and
purposes, the IPv4 address space is embedded in the IPv6 address space.)

Thus you simply cannot say "never match 'ip4:' on an IPv6 socket". IPv6-
enabled applications aren't even normally supposed to know _what_ an IPv4-
mapped IPv6 address is -- they should just use it like any other IPv6
address.

However, this debate is about the _other_ weird "IPv6 socket" case, i.e.
can 'ip6:' match an IPv4 connection if it comes through an IPv6 socket?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFa47/wL7PKlBZWjsRAoarAKDUq96LoOYh34nWjdjKcebK8SkvtACglNJJ
PQ6Tzs83GloXpjBXQl7gvdU=
=VDLP
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

In <200611272347.kARNlEqG047492@asarian-host.net> Mark <admin@asarian-host.net> writes:

>
> Purely from a sender perspective, is not the sole purpose of publishing an
> ip6 mechanism to indicate that it should only have meaning/relevance on an
> IPv6 socket?

I think that is what is being debated.

> ... 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.
>
> All fine and dandy. But again, what is the relevance of "seeing" an IPv4
> address on an IPv6 connection? The socket-type, IPv4 or IPv6, should
> determine which of the namesake mechs has (mutual exclusive) relevance. So
> as to say that "v=spf1 ip6:::FFFF:72.81.252.18 -all", while, according to
> our RFC, MUST still be considered an IPv4 address, STILL should have no
> relevance as IPv4 address in the context of evaluating an ip6 mech on an
> IPv6 connection. As if saying: "You have the right key, but you're trying
> to open the wrong door with it."


Ok, I'm far from an IPv6 expert, but my understanding is as follows:

Besides the case that Julian mentioned, where an OS may translate all
sockets, whether they are IPv4 or IPv6, into IPv6 sockets so that
applications just have to deal with one format, there are other cases.



It is quite possible to have a host that has IPv6 connectivity only,
just like it is possible to have only IPv4 connectivity. Such an IPv6
host will, for the next few decades, almost certainly need to use an
IPv4 gateway to access IPv4-only hosts. Such a gateway will act very
much like NAT gateways and the RFC1918 private addresses, such as the
10.x.y.z space. This includes having things similar to
port-forwarding where a connection on a certain IPv4 address on port
80 will get translated by the IPv6<->IPv4 gateway into a connection on
the IPv6-only host on port 80.

So, some IPv4-only machine goes off and tries to send mail to
ipv6-only.net. It will connect on some "IPv4" address and use port
80, which will automatically get run through the gateway.
ipv6-only.net will now see an IPv6 socket connection using an
IPv4-mapped IPv6 address.


Another case is that even if a host has both IPv4 and IPv6
connectivity, it may be the case that the fastest/best routing is to
use a IPv4<->IPv6 gateway and end up in a similar situation as above.
While this is almost never the case today, that could easily change in
another 10 years.


Corrections and/or questions are welcome. As I said, I'm not an IPv6
expert and I may misunderstand this and I certainly could be doing a
poor job of explaining it.



-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

Stuart D. Gathman wrote:

> I am currently with the mutual exclusion party.

+1 Julian's position runs into contradictions wrt A vs. AAAA and
dualcidr.

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

It is not IP6 enabled MTAs that drive the decision (between BOTH and
EITHER), but IP4 only MTAs. While not explicit in the RFC, there was
an understanding that an IP4 only MTA could ignore IP6 and be a fully
conforming SPF implementation.

If the BOTH AND party wins, this will NOT be the case. IP4 only
implementations will have to evaluate IP6 mechs and lookup AAAA records,
just in case they might match ::FFFF:*. If you don't have this requirement,
then the SPF result for the same sender and connect ip will depend on whether
an IP4 or an IP6 MTA evaluates it - defeating the purpose of SPF
(to provide a consistent result based on sender and connect IP only).

Only the MUTUAL EXCLUSION party allows IP4 only hosts to ignore IP6 issues.
The vast majority of installed SPF checkers are IP4 only. A victory by
the BOTH AND party will make these formerly mostly compliant implementations
LESS compliant.

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

On Tuesday 28 November 2006 11:39, Stuart D. Gathman wrote:
> It is not IP6 enabled MTAs that drive the decision (between BOTH and
> EITHER), but IP4 only MTAs. While not explicit in the RFC, there was
> an understanding that an IP4 only MTA could ignore IP6 and be a fully
> conforming SPF implementation.
>
> If the BOTH AND party wins, this will NOT be the case. IP4 only
> implementations will have to evaluate IP6 mechs and lookup AAAA records,
> just in case they might match ::FFFF:*. If you don't have this
> requirement, then the SPF result for the same sender and connect ip will
> depend on whether an IP4 or an IP6 MTA evaluates it - defeating the purpose
> of SPF
> (to provide a consistent result based on sender and connect IP only).
>
> Only the MUTUAL EXCLUSION party allows IP4 only hosts to ignore IP6 issues.
> The vast majority of installed SPF checkers are IP4 only. A victory by
> the BOTH AND party will make these formerly mostly compliant
> implementations LESS compliant.

As I understand the issue, I agree. I think that the response that doing the
match is trivial ignores the fact that it's a concept that's not implemented
in the current IPv4 centric implementations and so holds no water.

Even if BOTH AND is theoretically more correct, the backward compatibility
issue trumps the theory in my book.

That said, if an IPv6 implementation wants to match ::FFFF:*, then I think
it's no harm. So I think that the IPv6 implementation MUST match ip4 and *
and MAY match ip6: ::FFFF:*. Record publishers MUST NOT depend on matching
ip6: ::FFFF:*.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

On Tue, 28 Nov 2006, Scott Kitterman wrote:
> On Tuesday 28 November 2006 11:39, Stuart D. Gathman wrote:
> > It is not IP6 enabled MTAs that drive the decision (between BOTH and
> > EITHER), but IP4 only MTAs. While not explicit in the RFC, there was
> > an understanding that an IP4 only MTA could ignore IP6 and be a fully
> > conforming SPF implementation.
> >
> > If the BOTH AND party wins, this will NOT be the case. IP4 only
> > implementations will have to evaluate IP6 mechs and lookup AAAA records,
> > just in case they might match ::FFFF:*. If you don't have this
> > requirement, then the SPF result for the same sender and connect ip will
> > depend on whether an IP4 or an IP6 MTA evaluates it - defeating the purpose
> > of SPF
> > (to provide a consistent result based on sender and connect IP only).
> >
> > Only the MUTUAL EXCLUSION party allows IP4 only hosts to ignore IP6 issues.
> > The vast majority of installed SPF checkers are IP4 only. A victory by
> > the BOTH AND party will make these formerly mostly compliant
> > implementations LESS compliant.
>
> As I understand the issue, I agree. I think that the response that doing the
> match is trivial ignores the fact that it's a concept that's not implemented
> in the current IPv4 centric implementations and so holds no water.
>
> Even if BOTH AND is theoretically more correct, the backward compatibility
> issue trumps the theory in my book.
>
> That said, if an IPv6 implementation wants to match ::FFFF:*, then I think
> it's no harm. So I think that the IPv6 implementation MUST match ip4 and *
> and MAY match ip6: ::FFFF:*. Record publishers MUST NOT depend on matching
> ip6: ::FFFF:*.

+1, this is where I sit on the issue.

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

In <200611281150.10749.scott@kitterman.com> Scott Kitterman <scott@kitterman.com> writes:

> Even if BOTH AND is theoretically more correct, the backward compatibility
> issue trumps the theory in my book.

I also think that backwards compatibility is very important.

> That said, if an IPv6 implementation wants to match ::FFFF:*, then I think
> it's no harm. So I think that the IPv6 implementation MUST match ip4 and *
> and MAY match ip6: ::FFFF:*. Record publishers MUST NOT depend on matching
> ip6: ::FFFF:*.

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?

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?


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

On Tuesday 28 November 2006 12:02, wayne wrote:
> In <200611281150.10749.scott@kitterman.com> Scott Kitterman
<scott@kitterman.com> writes:
> > Even if BOTH AND is theoretically more correct, the backward
> > compatibility issue trumps the theory in my book.
>
> I also think that backwards compatibility is very important.
>
> > That said, if an IPv6 implementation wants to match ::FFFF:*, then I
> > think it's no harm. So I think that the IPv6 implementation MUST match
> > ip4 and * and MAY match ip6: ::FFFF:*. Record publishers MUST NOT depend
> > on matching ip6: ::FFFF:*.
>
> 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?
>
> Personally, I would rather not allow for inconsistent SPF results.

Agreed, but I also think that the chances of such a record ever being written
are low enough that it may not be worth worrying about.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Stuart D. Gathman wrote:
> > I am currently with the mutual exclusion party.
>
> +1 Julian's position runs into contradictions wrt A vs. AAAA and
> dualcidr.

How so?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbHEIwL7PKlBZWjsRAqOgAKD9gWVbFAfpOuAZ5K78VcLa9a12DQCg9xto
aUkCo6evffN9XdfhC8D9WII=
=bnab
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

> 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

Julian Mehnle wrote:

>>> I am currently with the mutual exclusion party.

>> +1 Julian's position runs into contradictions wrt A vs. AAAA and
>> dualcidr.

> How so?

As you've explained it yesterday in...
<http://permalink.gmane.org/gmane.mail.spam.spf.devel/1246>
...and as we've discussed it two weeks ago in...
<http://permalink.gmane.org/gmane.mail.spam.spf.devel/1231>

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > > Julian's position runs into contradictions wrt A vs. AAAA and
> > > dualcidr.
> >
> > How so?
>
> As you've explained it yesterday in...
> <http://permalink.gmane.org/gmane.mail.spam.spf.devel/1246>
> ...and as we've discussed it two weeks ago in...
> <http://permalink.gmane.org/gmane.mail.spam.spf.devel/1231>

Well, yeah. But how is that a contradiction? The "A/AAAA dual look-up"
solution (which I haven't been advocating, by the way) may not be nice,
but it would certainly be doable and not contradictory in itself.

The dual prefix length syntax (we shouldn't have called it "CIDR length",
which is a bogus term) is really just a convenience feature. With SPFv1
generally supporting IPv6, we could just as well have said that there is
always only _one_ prefix length and that it is IPv6, and that for IPv4
addresses, ip6-cidr-length minus 96 should be used as the prefix length.

For practical purposes (we don't want to lose the readability of the dual
syntax after all, do we?), we could (and probably should) have said that
any IPv4/IPv6 prefix length combo must satisfy "ip4-cidr-length = ip6-
cidr-length - 96" or an error would be thrown. (Yes, some very odd setups
could no longer be expressed that way, but you already have the equivalent
problem with "v=spf1 a:foo/24", foo. A 192.168.0.1, foo. A 10.0.0.1.)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbMMJwL7PKlBZWjsRAvZjAKDyfd9kG0tOu7OzMnilAz3vjRkcHwCgqkI4
bo4Z2TkP43/3NOFvgCBg42Y=
=TXq+
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Julian Mehnle wrote:
> Stuart D. Gathman wrote:
> > On Wed, 15 Nov 2006, Julian Mehnle wrote:
> > > In the Mail::SPF test-suite driver, I am currently skipping the
> > > "cidr6-0-ip4" and "cidr6-ip4" test cases. They assume that IPv4
> > > connections must never match the "ip6" mechanism, even if the IPv4
> > > connection comes in through an IPv6 interface. I discussed this
> > > with Wayne and Scott on #spf extensively, and it seems we cannot
> > > agree on a common interpretation of RFC 4408. Here's my
> > > rationale:
> > >
> > > Nowhere does RFC 4408 say that the "ip6" mechanism must not match
> > > IPv4 addresses. 5/9 saying "Even if the SMTP connection is via
> > > IPv6, an IPv4-mapped IPv6 IP address [...] MUST still be considered
> > > an IPv4 address" doesn't change that.
> >
> > Why do you make ip4 mapped ip6 connections match IP6, but not A or MX?
> > To be consistent, you should fail tests like a-cidr6-0-ip4mapped as
> > well:
> >
> > e2a.example.com:
> > - AAAA: 1234::1
> > - SPF: v=spf1 a//0 -all
> >
> > If ip4 mapped connections are considered as *both* ip4 and ip6, then
> > they should match the above a//0 mech as well. But your SPF lib
> > apparently passes the above test.
>
> You are right. I really should do _both_ "A" and "AAAA" lookups for
> IPv4-mapped IPv6 addresses in order to be consistent with my "ip6:"
> rationale.
>
> However, I need to think more about (1) whether such dual address
> lookups can be justified, and (2) whether there's perhaps a conceptual
> difference between "ip6:" and "a:" that would justify NOT being
> consistent in this regard. I'll let you know where my meditations lead
> me.

Here's my final position after having pondered all of this for a few days.

1. "ip6:::/0", "ip6:::ffff:n.n.n.n", and similar constructs in SPF records
should NOT be no-ops but should match connections from IPv4 addresses.
I acknowledge that RFC 4408 is not sufficiently explicit about what to
do, and I maintain that it DOES permit this interpretation of mine and
that...
a. otherwise, RFC 4408 would have had to explicitly state that "ip6:
::ffff:n.n.n.n/len" or "ip6:::ffff:x:x/len" are no-ops (bad!), or
even better, do throw a PermError. Note that the "ip6:::ffff:
n.n.n.n" syntax _is_ allowed by RFC 4408, and that
b. NOT having holes in "ip6:"'s IPv6 address space is "the right thing
to do" because it does what the IPv6-savvy SPF publisher expects.

2. It is sufficiently unlikely that domain owners would publish IPv4
addresses using AAAA records, so requiring SPF implementations to do
both A and AAAA look-ups for IPv4 connections, while theoretically the
most correct thing to do, is _way_ out of proportion and NOT necessary
in order to maintain consistency with the view that "IPv4-mapped IPv6
addresses are IPv6 addresses, too".

3. I thus request that the test-suite be changed to _require_, or at least
_allow_, that "ip6:" can match connections from IPv4 addresses, regard-
less (obviously!) whether the MTA implementing SPF uses an IPv4 socket
or an IPv6 socket. As I have said multiple times, this request is NOT
motivated by the desire to save some small percentage of development
effort, but because I believe it to be the right thing to do.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbuHhwL7PKlBZWjsRAq4GAKCdIluUps6q4IU6Y0CZOZ7D7pAkqQCcDx88
irJvDbs8A4vPpwSH4Fvx3EE=
=0Nnh
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

On Thu, 30 Nov 2006, Julian Mehnle wrote:

> 3. I thus request that the test-suite be changed to _require_, or at least
> _allow_, that "ip6:" can match connections from IPv4 addresses, regard-
> less (obviously!) whether the MTA implementing SPF uses an IPv4 socket
> or an IPv6 socket. As I have said multiple times, this request is NOT
> motivated by the desire to save some small percentage of development
> effort, but because I believe it to be the right thing to do.

The 2006-11 test suite already does this. Since ip6:::FFFF:* is a noop
in the majority opinion, and is the preferred result, publishers won't have
any reason to use it, and there won't be any compatibility problems. :-)
I.e., you can maintain that ip6:::FFFF:* *ought* to match something,
but you can't depend on it until SPFv3 - when Julian will hopefully
ensure more elegant IP6 semantics for the next version.

Note that "can't depend on it" is *not* because I mulishly won't make Julians
interpretation the only one. It is because that is how all the existing
implementations save one work. It is how all IP4 only implementations work.

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

On Thursday 30 November 2006 08:51, Julian Mehnle wrote:

> Here's my final position after having pondered all of this for a few days.
...

I disagree. Nothing new to be said, but I 'vote' against.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Thu, 30 Nov 2006, Julian Mehnle wrote:
> > 3. I thus request that the test-suite be changed to _require_, or at
> > least _allow_, that "ip6:" can match connections from IPv4 addresses,
> > regard- less (obviously!) whether the MTA implementing SPF uses an
> > IPv4 socket or an IPv6 socket. As I have said multiple times, this
> > request is NOT motivated by the desire to save some small percentage
> > of development effort, but because I believe it to be the right thing
> > to do.
>
> The 2006-11 test suite already does this. Since ip6:::FFFF:* is a noop
> in the majority opinion, and is the preferred result, publishers won't
> have any reason to use it, and there won't be any compatibility
> problems. :-) I.e., you can maintain that ip6:::FFFF:* *ought* to match
> something, but you can't depend on it until SPFv3 - when Julian will
> hopefully ensure more elegant IP6 semantics for the next version.
>
> Note that "can't depend on it" is *not* because I mulishly won't make
> Julians interpretation the only one. It is because that is how all the
> existing implementations save one work. It is how all IP4 only
> implementations work.

Please change or don't change the test suite as you see fit, given what has
been said in this thread. If you change it back to disallowing "ip6:"
matching IPv4 addresses, I will then either change Mail::SPF to conform or
keep overriding the relevant test cases (I haven't decided yet).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFbvsgwL7PKlBZWjsRAitiAKCpObm0b9n0rY33FyINlIhFIw/9ewCgn+XT
p3AKaV1dtszBCbIHQZncqKo=
=xM1f
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

In <200611301351.29872.julian@mehnle.net> Julian Mehnle <julian@mehnle.net> writes:

> Julian Mehnle wrote:
> Here's my final position after having pondered all of this for a few days.
>
> 1. "ip6:::/0", "ip6:::ffff:n.n.n.n", and similar constructs in SPF records
> should NOT be no-ops but should match connections from IPv4 addresses.
> I acknowledge that RFC 4408 is not sufficiently explicit about what to
> do, and I maintain that it DOES permit this interpretation of mine and
> that...
> a. otherwise, RFC 4408 would have had to explicitly state that "ip6:
> ::ffff:n.n.n.n/len" or "ip6:::ffff:x:x/len" are no-ops (bad!), or
> even better, do throw a PermError. Note that the "ip6:::ffff:
> n.n.n.n" syntax _is_ allowed by RFC 4408, and that

No, RFC would *not* have to explicitly say that something is a no-op.
The second "all" in "v=spf1 ?all ?all" is a no-op. RFC4408 even
mentions "tracking exists: mechanisms" which never change the SPF
result, although they aren't entirely no-ops. Having a "redirect="
with an "all" mechanism is also a no-op.

Heck, all multi-cast addresses in either ip4: or ip6: are no-ops too,
and that is much closer to this case.


> b. NOT having holes in "ip6:"'s IPv6 address space is "the right thing
> to do" because it does what the IPv6-savvy SPF publisher expects.

Sorry, but there are already many holes in the IPv6 address space.


> 2. It is sufficiently unlikely that domain owners would publish IPv4
> addresses using AAAA records, so requiring SPF implementations to do
> both A and AAAA look-ups for IPv4 connections, while theoretically the
> most correct thing to do, is _way_ out of proportion and NOT necessary
> in order to maintain consistency with the view that "IPv4-mapped IPv6
> addresses are IPv6 addresses, too".

Do a google search on "IPv4-mapped AAAA" and see how many people
disagree with this claim.


> 3. I thus request that the test-suite be changed to _require_, or at least
> _allow_, that "ip6:" can match connections from IPv4 addresses, regard-
> less (obviously!) whether the MTA implementing SPF uses an IPv4 socket
> or an IPv6 socket. As I have said multiple times, this request is NOT
> motivated by the desire to save some small percentage of development
> effort, but because I believe it to be the right thing to do.

I think that creating a gratuitous ambiguity for no gain is wrong. I
think requiring your intperetation of the spec would be horrible.

I can not support anything other than saying that for SPF, IPv4 and
IPv6 addresses spaces are mutually exclusive.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007