Mailing List Archive

dual-cidr
Here is another test that pyspf flunks. Does your implementation pass?

tests:
a-dual-cidr:
description: |
A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
comment: >-
Although /33 is invalid for ip4, it is perfectly valid for A and MX
mechanisms when used with ip6. Even when not supporting ip6, an
implementation must not report permerror for a/33 (or a/128).
spec: 5.3/2
helo: mail.example.com
host: 1.2.3.4
mailfrom: foo@e6.example.com
result: fail
zonedata:
mail.example.com:
- A: 1.2.3.4
e6.example.com:
- SPF: v=spf1 a/33 -all

Or should a/33 give permerror if no AAAA record is present?

--
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/?listname=spf-devel@v2.listbox.com
Re: dual-cidr [ In reply to ]
Another good test is (which different testers get a little confused)
v=spf1 a/0 -all

spam.co.nz's: passes (have to check if this is really what its doing)
pyspf gives: PermError SPF Permanent Error: Unknown mechanism found: a/0
(wrong permerror reason even if you don't think /0 is a valid netmask)
dnsstuff gives: Fail (doesn't think a/0 matches anything)
vamsoft gives: permerror

a/24 means anything in the same /24 as the A
so a/16 means anything in the /16 as the A
so in theory a/0 should pass anything (if the A is IPV4 and coming from an
IPV4 address) or (the A is IPV6 and coming from an IPV6 address)
so 1.1.1.1/0 is valid and should be treated the same as 0.0.0.0/0 etc so as
long as the email is coming from an IPV4 address the a/0 or ip4:1.1.1.1/0
should pass

Another good question is if:

blah.com A 1.1.1.1
blah.com A 2.2.2.2

v=spf1 a/24 -all would mean anything it passses if it comes from 1.1.1.0/24
or 2.2.2.0/24 ?

Thanks

Thanks
Craig

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: dual-cidr [ In reply to ]
Stuart D. Gathman wrote:

> Or should a/33 give permerror if no AAAA record is present?

Better not, it could be a cache / timing thing. Maybe the
spec. was a bit too minimalistic with its "one length fits
all" approach.

Years too late to improve this, I vaguely recall a discussion
when Mark convinced me that /x only for ipv4 (one slash) and
//y only for ipv6 (two slashes) is unnecessary. Maybe a point
for a hypothetical "2.1" spec. (?)

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: dual-cidr [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> tests:
> a-dual-cidr:
> description: |
> A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
> dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
> comment: >-
> Although /33 is invalid for ip4, it is perfectly valid for A and MX
> mechanisms when used with ip6. Even when not supporting ip6, an
> implementation must not report permerror for a/33 (or a/128).
> [...]
>
> Or should a/33 give permerror if no AAAA record is present?

I beg your pardon?

The CIDR length of "33" in "a/33" can _never_ apply to IPv6.

It can't be a << "/" ip6-cidr-length >>, because ip6-cidr-length is defined
as << "/" 1*DIGIT >>, so it would have to read "//33". "a/33" is meaning-
less (even though it is syntactically valid).

Frank Ellermann wrote:
> Years too late to improve this, I vaguely recall a discussion when Mark
> convinced me that /x only for ipv4 (one slash) and //y only for ipv6 (two
> slashes) is unnecessary. Maybe a point for a hypothetical "2.1" spec.(?)

But that's exactly how RFC 4408 defines it! I don't think MarkL ever
promoted "a/32/128" as the way to go. It is "a/32//128". Basta!

Guys, please read the spec more thoroughly. ;-)

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

iD8DBQFE9d++wL7PKlBZWjsRAiQqAJ96FoKfSykuhL3KY5HtWyDXtYB2TgCfVuV5
0MlN3tt5OnaWJNUNhSH+yUA=
=ebUI
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: dual-cidr [ In reply to ]
Julian Mehnle wrote:

> I don't think MarkL ever promoted "a/32/128" as the way to
> go. It is "a/32//128". Basta!

Yes, for dual-cidr-length. I confused "a" and "ip6", and my
old idea was to have two slashes for all cases of ip6 CIDRs.

That's where MarkL convinced me that it's unnecessary...

> Guys, please read the spec more thoroughly. ;-)

...you're the expert for "IPv6", I only know that it works,
but obviously I forgot why for "a" and <dual-cidr-length>.

In light of that a/33 is still no syntax error, but it's
semantical crap, certainly not the same as a sound a//33.

If you want to Permerror the a/33 go for it. Ditto a//129.

Or don't test it, hard to decide. When I talked about crap
like "leading zeros" what I had in mind was the output of a
stupid "policy preprocessor" script, where we hope (= should
check) that a/010 isn't octal.

But a/33 or anything with more than three digits just can't
be good, even if the syntax allows it.

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Re: dual-cidr [ In reply to ]
On Thu, 31 Aug 2006, Frank Ellermann wrote:

> But a/33 or anything with more than three digits just can't
> be good, even if the syntax allows it.

example.com IN SPF "v=spf1 a/33 -all"
IN AAAA 1234:5678:8000::

(I am new to IP6, so forgive minor syntax errors - you get the point.)

--
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/?listname=spf-devel@v2.listbox.com
Re: Re: dual-cidr [ In reply to ]
On Wed, 30 Aug 2006, Julian Mehnle wrote:

> > A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
> > dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
> > comment: >-
> > Although /33 is invalid for ip4, it is perfectly valid for A and MX
> > mechanisms when used with ip6. Even when not supporting ip6, an
> > implementation must not report permerror for a/33 (or a/128).
>
> I beg your pardon?
>
> But that's exactly how RFC 4408 defines it! I don't think MarkL ever
> promoted "a/32/128" as the way to go. It is "a/32//128". Basta!
>
> Guys, please read the spec more thoroughly. ;-)

I am embarassed. Somehow I kept seeing (until you see me straight):

dual-cidr-length = ip4-cidr-length / ip6-cidr-length

In reality, it says:

dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

Those brackets and quotes are important! :-(

I am fixing the test cases pronto.

--
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/?listname=spf-devel@v2.listbox.com
Re: dual-cidr [ In reply to ]
Stuart D. Gathman wrote:

> example.com IN SPF "v=spf1 a/33 -all"
> IN AAAA 1234:5678:8000::

> (I am new to IP6, so forgive minor syntax errors - you get
> the point.)

I've also no clue about IPv6. The reserved example IPs are
different. What you have above is only 1234:5678:8000:: for
IPv6, and a bogus /33 for IPv4. Otherwise FAIL.

In other words a Permerror for semantical reasons, the /33 is
crap or a missing slash. However a single slash would be okay
for "v=spf1 ip6:1234:5678:8000::/33". A double slash would
be wrong in "v=spf1 ip6:1234:5678:8000:://33". That's the
detail I've discussed with MarkL more than two years ago - not
the valid "a//33" vs. bogus "a/33", I confused that in my 1st
reply here to you, sorry.

Frank


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