Mailing List Archive

James Couzens wrote:

> ;; ANSWER SECTION:
> spf.midwestcs.com. 600 IN TXT "v=spf1 a:232/29.%{d} -all"

> hrm... '%{d}' would expand to 'spf.midwestcs.com' that gives
> us 'a:232/29.spf.midwestcs.com' thats most certainly not valid.

"v=spf1 a:232/29.%{d} -all" is a valid domain name and an A lookup gives:
206.222.212.234
206.222.212.237

So "spfquery -i 206.222.212.234 -s foo@spf.midwestcs.com" should return
"pass".

This is not really a bug in your library but a fault in the SPF
specifications. Currently it is ambiguous. You don't know if "a:foo.com/24"
means "the first 24 bits of the IP address of foo.com" or if it means "all
32 bits of the IP address of foo.com/24". The solution would be to escape
"/" in a domain-spec by "%!". For example: "v=spf1 a:232%!29.%{d} -all".

So in your library you have to program a work-around this error in the
specification and first parse and strip the dual-cidr-len.

Roger

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

In <030701c47484$a34f3a00$01030101@pamho.net> "Roger Moser" <rkd_spf@greenmail.ch> writes:

> "v=spf1 a:232/29.%{d} -all" is a valid domain name [...]
>
> This is not really a bug in your library but a fault in the SPF
> specifications. Currently it is ambiguous. You don't know if "a:foo.com/24"
> means "the first 24 bits of the IP address of foo.com" or if it means "all
> 32 bits of the IP address of foo.com/24". The solution would be to escape
> "/" in a domain-spec by "%!". For example: "v=spf1 a:232%!29.%{d} -all".

I agree that the current ABNF in the SPF spec is ambiguous, and there
was a good post about the subject on the MARID list. However, in this
case, there is no ambiguity since the misidentified CIDR notation is
not at the end of the domain.


> So in your library you have to program a work-around this error in the
> specification and first parse and strip the dual-cidr-len.

Yes, and I think the SPF RFC needs to be updated. I looked into what
it would take to actually make an unambiguous ABNF grammar, and it
doesn't look trivial. (But then, I'm not that experienced with ABNF
in specs like this.)


-wayne

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

wayne wrote:

> Yes, and I think the SPF RFC needs to be updated. I looked into what
> it would take to actually make an unambiguous ABNF grammar, and it
> doesn't look trivial. (But then, I'm not that experienced with ABNF
> in specs like this.)

The space terminates the mechanism or modifier, therefore a space within it
is written as "%_".
Similarly a slash terminates the domain-spec, therefore a slash within the
domain-spec should be written as "%!".
It is not too late to introduce that additional macro character.

Roger

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

On Wed, 2004-07-28 at 02:24, Roger Moser wrote:

> So "spfquery -i 206.222.212.234 -s foo@spf.midwestcs.com" should return
> "pass".
>
> This is not really a bug in your library but a fault in the SPF
> specifications. Currently it is ambiguous. You don't know if "a:foo.com/24"
> means "the first 24 bits of the IP address of foo.com" or if it means "all
> 32 bits of the IP address of foo.com/24". The solution would be to escape
> "/" in a domain-spec by "%!". For example: "v=spf1 a:232%!29.%{d} -all".
>
> So in your library you have to program a work-around this error in the
> specification and first parse and strip the dual-cidr-len.
>
> Roger

Ah excellent. Thank you Roger. Quite frankly, I think the above stated
syntax is stupid, and given the fact that SPF was written with the
intent to be "human readable" I find the above query rather disturbing,
even after having it explained it just seems to go against the very
nature of "human readable spf query language". :-)

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

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

On Wed, 2004-07-28 at 04:15, wayne wrote:

> I agree that the current ABNF in the SPF spec is ambiguous, and there
> was a good post about the subject on the MARID list. However, in this
> case, there is no ambiguity since the misidentified CIDR notation is
> not at the end of the domain.

That doesn't explain why your library doesn't parse it either Wayne.

I thought that "through your hard work as author of the test suite you
attained a superior grasp of SPF". Tsk Tsk.

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

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

In <000d01c47498$21335600$01030101@pamho.net> "Roger Moser" <rkd_spf@greenmail.ch> writes:

> wayne wrote:
>
>> Yes, and I think the SPF RFC needs to be updated. I looked into what
>> it would take to actually make an unambiguous ABNF grammar, and it
>> doesn't look trivial. (But then, I'm not that experienced with ABNF
>> in specs like this.)
>
> The space terminates the mechanism or modifier, therefore a space within it
> is written as "%_".

This is true because the ABNF doesn't allow a space to be within the
mech or mod.

> Similarly a slash terminates the domain-spec, therefore a slash within the
> domain-spec should be written as "%!".
> It is not too late to introduce that additional macro character.

I disagree that a slash terminates the domain-spec. The relevant ABNF
is:

mechanism = name [ ":" macro-string ] *[ "/" *DIGIT ]
macro-string = *( macro-char / VCHAR )
VCHAR = %x21-7E
; visible (printing) characters

VCHAR includes the "/" character and digits. If ABNF follows the same
as regular expressions, it should use a greedy match and the CIDR part
should always be empty, which isn't right. The grammar is ambiguous
because strings like "/1/2/3////4/5/6" match '*[ "/" *DIGIT ]', so
even if ABNF is not a greedy matcher, it will match the wrong stuff.

In neither case will a simple "/" terminate the domain name.

Here are some tests when the ABNF is translated into regular
expressions:


(wayne@footbone) $ echo "232/29.%{d}" | sed 's;^\([!-~]*\)\(/[0-9]*\)*$;domain: \1 cidr: \2;'
domain: 232/29.%{d} cidr:
(wayne@footbone) $ echo "foo.com/29" | sed 's;^\([!-~]*\)\(/[0-9]*\)*$;domain: \1 cidr: \2;'
domain: foo.com/29 cidr:
(wayne@footbone) $ echo "foo.com/29" | sed 's;^\([!-~]*\)\(/[0-9]*\)$;domain: \1 cidr: \2;'
domain: foo.com cidr: /29


-wayne

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

In <1091017865.17502.401.camel@code3> James Couzens <jcouzens@6o4.ca> writes:

> That doesn't explain why your library doesn't parse it either Wayne.
>
> I thought that "through your hard work as author of the test suite you
> attained a superior grasp of SPF". Tsk Tsk.


Uh, libspf2 does parse it correctly, and has since the initial release.

(wayne@footbone) $ spfquery -i 206.222.212.234 -s foo@spf2.midwestcs.com -h asdf
pass

spfquery: domain of spf2.midwestcs.com designates 206.222.212.234 as permitted sender
Received-SPF: pass (spfquery: domain of spf2.midwestcs.com designates 206.222.212.234 as permitted sender) client-ip=206.222.212.234; envelope-from=foo@spf2.midwestcs.com; helo=asdf;


-wayne

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

wayne wrote:

> I disagree that a slash terminates the domain-spec. The relevant ABNF
> is:
>
> mechanism = name [ ":" macro-string ] *[ "/" *DIGIT ]
> macro-string = *( macro-char / VCHAR )
> VCHAR = %x21-7E
> ; visible (printing) characters
>
> VCHAR includes the "/" character and digits.

VCHAR also includes "%", "{" and "}". So according to above ABNF what is for
example "%{o}", a macro or four VCHARs?

Currently all SPF implementation ignore above definition of VCHAR and use
"visible characters except %" instead. So why not use "visible characters
except % and /" and indroduce the macro "%!" (which expands to a slash)?

Roger

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

In <003901c474a6$201d97e0$01030101@pamho.net> "Roger Moser" <rkd_spf@greenmail.ch> writes:

> wayne wrote:
>
>> I disagree that a slash terminates the domain-spec. The relevant ABNF
>> is:
>>
>> mechanism = name [ ":" macro-string ] *[ "/" *DIGIT ]
>> macro-string = *( macro-char / VCHAR )
>> VCHAR = %x21-7E
>> ; visible (printing) characters
>>
>> VCHAR includes the "/" character and digits.
>
> VCHAR also includes "%", "{" and "}". So according to above ABNF what is for
> example "%{o}", a macro or four VCHARs?

Yes, but the macro-char stuff defines the macro variables. Again,
yes, the SPF RFC is ambiguous about how it should be parsed.


> Currently all SPF implementation ignore above definition of VCHAR and use
> "visible characters except %" instead. So why not use "visible characters
> except % and /" and indroduce the macro "%!" (which expands to a slash)?

I don't really think %! is needed. As long as you chop off valid CIDR
notations off the end of the token and use the rest as the domain, you
are fine. Complexity should be put into the spec, not into what
domain owners need to use. Considering that the use of a slash is
suggested in one of the RFCs, the use of slashes in domain names
should not be a surprise to anyone.


-wayne

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

On Wed, 2004-07-28 at 05:53, wayne wrote:
> In <1091017865.17502.401.camel@code3> James Couzens <jcouzens@6o4.ca> writes:
>
> > That doesn't explain why your library doesn't parse it either Wayne.
> >
> > I thought that "through your hard work as author of the test suite you
> > attained a superior grasp of SPF". Tsk Tsk.
>
>
> Uh, libspf2 does parse it correctly, and has since the initial release.
>
> (wayne@footbone) $ spfquery -i 206.222.212.234 -s foo@spf2.midwestcs.com -h asdf
> pass
>
> spfquery: domain of spf2.midwestcs.com designates 206.222.212.234 as permitted sender
> Received-SPF: pass (spfquery: domain of spf2.midwestcs.com designates 206.222.212.234 as permitted sender) client-ip=206.222.212.234; envelope-from=foo@spf2.midwestcs.com; helo=asdf;

I dunno wayne, 1.04 certainly doesn't.

from ./libspf2-1.0.4/src/spfquery

james@code3 spfquery $ ./spfquery -i 206.222.212.234 -s
foo@spf2.midwestcs.com -h asdf
fail
Please see
http://spf.pobox.com/why.html?sender=foo%40spf2.midwestcs.com&ip=206.222.212.234&receiver=spfquery
spfquery: domain of spf2.midwestcs.com does not designate
206.222.212.234 as permitted sender
Received-SPF: fail (spfquery: domain of spf2.midwestcs.com does not
designate 206.222.212.234 as permitted sender)
client-ip=206.222.212.234; envelope-from=foo@spf2.midwestcs.com;
helo=asdf;

james@code3 spfquery $ ls -la
total 536
drwxr-xr-x 4 james james 304 Jul 27 23:05 .
drwxr-xr-x 9 james james 320 Jul 27 23:05 ..
drwxr-xr-x 2 james james 80 Jul 27 23:05 .deps
drwxr-xr-x 2 james james 104 Jul 28 00:15 .libs
-rw-r--r-- 1 james james 17749 Jul 27 23:05 Makefile
-rw-r--r-- 1 james james 406 Jun 27 04:44 Makefile.am
-rw-r--r-- 1 james james 18178 Jul 8 10:18 Makefile.in
-rwxr-xr-x 1 james james 4722 Jul 27 23:05 spfquery
-rw-r--r-- 1 james james 18859 Jun 27 07:46 spfquery.c
-rw-r--r-- 1 james james 39264 Jul 27 23:05 spfquery.o
-rwxr-xr-x 1 james james 433517 Jul 27 23:05 spfquery_static

root@code3 spfquery # ldd /usr/local/bin/spfquery
linux-gate.so.1 => (0xffffe000)
libspf2.so.1 => /usr/local/lib/libspf2.so.1 (0x40015000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40047000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4005c000)
libc.so.6 => /lib/libc.so.6 (0x4006d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

And since you did not acknowledge my previous statement that you are
clobbering my binaries of spfquery and spfquery_static, will you please
acknowledge that they will be renamed appropriately in future versions.

In case you didn't notice wayne, this is yet another reason why you do
not name your library similarly to that of another.

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

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

In <1091031375.6286.6.camel@code3> James Couzens <jcouzens@6o4.ca> writes:

> On Wed, 2004-07-28 at 05:53, wayne wrote:
>> In <1091017865.17502.401.camel@code3> James Couzens <jcouzens@6o4.ca> writes:
>>
>> Uh, libspf2 does parse it correctly, and has since the initial release.
>
> I dunno wayne, 1.04 certainly doesn't.

Indeed you are correct. Something broke between 1.0.3 and 1.0.4.
Shevek has done the last few releases and I'm a couple of releases
back.

Thank you for reporting this bug. While I have reported many bugs to
you, this is the first time you have done anything to help me.


> And since you did not acknowledge my previous statement that you are
> clobbering my binaries of spfquery and spfquery_static, will you please
> acknowledge that they will be renamed appropriately in future versions.

No, I will not rename spfquery.

When I created the spfquery program for your implementation, I
deliberately made sure that it was compatible with the perl spfquery
program so that the exact same test suite could be run on both. When
I created my implementation, I of course created an spfquery command
that was also compatible with the perl spfquery.

If it concerns you that you have the same binary names as both my
implementation and the perl implementation, then I suggest you rename
them. This is even more important since you have now replaced the
spfquery program that I wrote for you with one that you wrote and
yours is no longer compatible with the perl spfquery program


-wayne

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

On Wed, 2004-07-28 at 11:23, wayne wrote:

> Indeed you are correct. Something broke between 1.0.3 and 1.0.4.
> Shevek has done the last few releases and I'm a couple of releases
> back.

I could say something here, but i'm sure everyone is already thinking
it, so I won't.

> Thank you for reporting this bug. While I have reported many bugs to
> you, this is the first time you have done anything to help me.

You are quite welcome.

> No, I will not rename spfquery.

> When I created the spfquery program for your implementation, I
> deliberately made sure that it was compatible with the perl spfquery
> program so that the exact same test suite could be run on both. When
> I created my implementation, I of course created an spfquery command
> that was also compatible with the perl spfquery.
>
> If it concerns you that you have the same binary names as both my
> implementation and the perl implementation, then I suggest you rename
> them. This is even more important since you have now replaced the
> spfquery program that I wrote for you with one that you wrote and
> yours is no longer compatible with the perl spfquery program

I shall rename my SPF query test tool to spfqtool as of RC5 since I do
not plan to make my tool work with the perl test suite since I've
already finished about half of my own testing suite as part of
spftools.net. See how easy that was Wayne?

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

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

> > There are potential bugs and real bugs. The libspf RC4 release still
> > doesn't get such things this right (it fails, when it should pass):
>
> There is putting your foot in your mouth, and then there is really
> putting your foot in your mouth.

Oh quit it :)

--
Matt Sealey <matt@genesi.co.uk>
Genesi, Manager, Developer Relations

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

On Wed, 2004-07-28 at 19:36, Matt Sealey wrote:
> > > There are potential bugs and real bugs. The libspf RC4 release still
> > > doesn't get such things this right (it fails, when it should pass):
> >
> > There is putting your foot in your mouth, and then there is really
> > putting your foot in your mouth.
>
> Oh quit it :)

Heh. I'm terribly sorry I just couldn't resist that one, I don't think
anyone could have :-)

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

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