Mailing List Archive

On Thu, 15 Mar 2007, Roberto Alsina wrote:

> I am confused by this test.
>
> It says it's about 8.1/6 which would be:
>
> The following macro letters are expanded in term arguments:
>
> s = <sender>
> l = local-part of <sender>
> o = domain of <sender>
> d = <domain>
> i = <ip>
> p = the validated domain name of <ip>
> v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
> h = HELO/EHLO domain
>
> And in this case, HELO domain is OEMCOMPUTER.
>
> Now, what is the implementation supposed to do? Check if h expands to
> OEMCOMPUTER? I am guessing not?

Partially, but mostly not.

> Should I just check that HELO/EHLO domain is valid according to RFC 2822?

No.

> Or is it really about 2.1 in rfc4408 and the recommended check of the HELO
> identity?

No.

> Or about giving a syntax error on "a:OEMCOMPUTER" ? Because that kind of
> things can happen just as well with valid helo domains, and then the test's
> name is confusing.

Bingo. The test is based on a real life complex policy that requires
a valid HELO name (hence the name). If you get it wrong, you are unlikely
to get other complex policies correct. I'll have to add a few more
complex policies if people start "coding to the test". It tests
a lot tricky things at once. Permerror in an included domain.
Syntax error after macro expansion, ...

BTW, a:%{h} is never a syntax error for a valid HELO FQDN. (A literal
IP is not a FQDN.)

--
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 Thu 15 Mar 2007 14:09:04 Stuart D. Gathman wrote:
> On Thu, 15 Mar 2007, Roberto Alsina wrote:
> > I am confused by this test.
> >
> > It says it's about 8.1/6 which would be:
> >
> > The following macro letters are expanded in term arguments:
> >
> > s = <sender>
> > l = local-part of <sender>
> > o = domain of <sender>
> > d = <domain>
> > i = <ip>
> > p = the validated domain name of <ip>
> > v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
> > h = HELO/EHLO domain
> >
> > And in this case, HELO domain is OEMCOMPUTER.
> >
> > Now, what is the implementation supposed to do? Check if h expands to
> > OEMCOMPUTER? I am guessing not?
>
> Partially, but mostly not.

Ok, that part works anyway.

> > Or about giving a syntax error on "a:OEMCOMPUTER" ? Because that kind of
> > things can happen just as well with valid helo domains, and then the
> > test's name is confusing.
>
> Bingo. The test is based on a real life complex policy that requires
> a valid HELO name (hence the name). If you get it wrong, you are unlikely
> to get other complex policies correct.

Well, I am sharing 99% of the PySPF logic, usually this kind of things is just
a little implementation detail on my side.

> I'll have to add a few more
> complex policies if people start "coding to the test".

That'd be awesome.

> It tests a lot tricky things at once. Permerror in an included domain.
> Syntax error after macro expansion, ...

Right, so the thing that should happen is like this (correct me if I am
wrong):

1) The SPF record for e10.example.com is

v=spf1 -include:_spfh.%{d2} ip4:1.2.3.0/24 -all

2) That expands to

v=spf1 -include:_spfh.example.com ip4:1.2.3.0/24 -all

3) So, use the SPF record for _spfh.example.com:

v=spf1 -a:%{h} +all

4) Which expands to

v=spf1 -a:OEMCOMPUTER +all

5) And then we have an invalid domain-end (OEMCOMPUTER) =>
invalid domain-spec =>invalid "a" mechanism=>fail.

Did I get it right? If yes, all I am missing is validating the domain-spec
**after** expanding macros (which strangely seems to be done the same way in
PySPF).

> BTW, a:%{h} is never a syntax error for a valid HELO FQDN. (A literal
> IP is not a FQDN.)

Yes, you are right, I was confused with the HELO "1.2.3.4" form.

BTW: what's one supposed to do on the mail server if a client uses that kind
of HELO? Not important, but I am a curious guy :-)

--
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  ralsina@kde.org
 (_Y_.)' ._   ) `._`.  " -.-'   KDE Developer (MFCH)
  _..`-'_..-_/ /-'_.'
(l)-'' ((i).' ((!.'   Buenos Aires - Argentina

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. --Brian W. Kernighan

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

On Thu, 15 Mar 2007, Roberto Alsina wrote:

> Right, so the thing that should happen is like this (correct me if I am
> wrong):
>
> 1) The SPF record for e10.example.com is
>
> v=spf1 -include:_spfh.%{d2} ip4:1.2.3.0/24 -all
>
> 2) That expands to
>
> v=spf1 -include:_spfh.example.com ip4:1.2.3.0/24 -all
>
> 3) So, use the SPF record for _spfh.example.com:
>
> v=spf1 -a:%{h} +all
>
> 4) Which expands to
>
> v=spf1 -a:OEMCOMPUTER +all
>
> 5) And then we have an invalid domain-end (OEMCOMPUTER) =>
> invalid domain-spec =>invalid "a" mechanism=>fail.

6) Continue to +all and return PASS

7) include (which should be called if-pass) matches, so return FAIL


Side note:

There was a huge debate about whether to check for syntax errors
before or after macro expansion. It is easy enough to expand all macros in the
SPF record before checking syntax - all the macros have fixed values at the
time the record is fetched. However, the RFC incorporates macro-string
explicitly in the mechanisms, so that a:%{h} is syntactically correct
regardless of the value of %{h} according to the RFC. Also, people
didn't want a PermError that depended on who was doing the querying.

--
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 Thu 15 Mar 2007 14:55:32 Stuart D. Gathman wrote:
> On Thu, 15 Mar 2007, Roberto Alsina wrote:
> > Right, so the thing that should happen is like this (correct me if I am
> > wrong):
> >
> > 1) The SPF record for e10.example.com is
> >
> > v=spf1 -include:_spfh.%{d2} ip4:1.2.3.0/24 -all
> >
> > 2) That expands to
> >
> > v=spf1 -include:_spfh.example.com ip4:1.2.3.0/24 -all
> >
> > 3) So, use the SPF record for _spfh.example.com:
> >
> > v=spf1 -a:%{h} +all
> >
> > 4) Which expands to
> >
> > v=spf1 -a:OEMCOMPUTER +all
> >
> > 5) And then we have an invalid domain-end (OEMCOMPUTER) =>
> > invalid domain-spec =>invalid "a" mechanism=>fail.
>
> 6) Continue to +all and return PASS

Right.

> 7) include (which should be called if-pass) matches, so return FAIL

And here's the real bug. I am not continuing with the original record if
include passes.

Thanks!

> Side note:
>
> There was a huge debate about whether to check for syntax errors
> before or after macro expansion. It is easy enough to expand all macros in
> the SPF record before checking syntax - all the macros have fixed values at
> the time the record is fetched. However, the RFC incorporates macro-string
> explicitly in the mechanisms, so that a:%{h} is syntactically correct
> regardless of the value of %{h} according to the RFC. Also, people didn't
> want a PermError that depended on who was doing the querying.

Ok, so that's not it.
 
--
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  ralsina@kde.org
 (_Y_.)' ._   ) `._`.  " -.-'   KDE Developer (MFCH)
  _..`-'_..-_/ /-'_.'
(l)-'' ((i).' ((!.'   Buenos Aires - Argentina

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. --Brian W. Kernighan

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

On Thu 15 Mar 2007 15:16:43 Roberto Alsina wrote:

> 7) include (which should be called if-pass) matches, so return FAIL
>
> And here's the real bug. I am not continuing with the original record if
> include passes.

As expected, a silly bug in the C translation. Now only exp-syntax-error
fails, and nospftxttimeout and p-macro-multiple give warnings.

At least nospftxttimeout I expect to be a driver bug.
 
--
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  ralsina@kde.org
 (_Y_.)' ._   ) `._`.  " -.-'   KDE Developer (MFCH)
  _..`-'_..-_/ /-'_.'
(l)-'' ((i).' ((!.'   Buenos Aires - Argentina

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. --Brian W. Kernighan

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

On Thu, 15 Mar 2007, Roberto Alsina wrote:

> As expected, a silly bug in the C translation. Now only exp-syntax-error
> fails, and nospftxttimeout and p-macro-multiple give warnings.

Warnings mean your library is RFC compliant, but resolves an
ambiguity in the spec in a way that goes against a SHOULD in the RFC
or is not considered best practice by most in the spf community. Pyspf gets 5
warnings. Some are deliberate, like not checking for SPF if a TXT record is
found (since so few people have SPF records compared to TXT, and those that do
should have the same info in SPF).

> At least nospftxttimeout I expect to be a driver bug.

Can your test driver be used for libspf2?

--
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 Thu 15 Mar 2007 15:54:35 Stuart D. Gathman wrote:
> On Thu, 15 Mar 2007, Roberto Alsina wrote:
> > As expected, a silly bug in the C translation. Now only exp-syntax-error
> > fails, and nospftxttimeout and p-macro-multiple give warnings.
>
> Warnings mean your library is RFC compliant, but resolves an
> ambiguity in the spec in a way that goes against a SHOULD in the RFC
> or is not considered best practice by most in the spf community. Pyspf
> gets 5 warnings. Some are deliberate, like not checking for SPF if a TXT
> record is found (since so few people have SPF records compared to TXT, and
> those that do should have the same info in SPF).
>
> > At least nospftxttimeout I expect to be a driver bug.
>
> Can your test driver be used for libspf2?

Maybe with some massaging.

Basically, a python script generates a text file containing the zone data for
the scenario, and then I implemented dummy DNS functions that load that file
into dictionaries and use it for the lookups.

I am not familiar enough with libspf2 to do it myself, though.

--
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  ralsina@kde.org
 (_Y_.)' ._   ) `._`.  " -.-'   KDE Developer (MFCH)
  _..`-'_..-_/ /-'_.'
(l)-'' ((i).' ((!.'   Buenos Aires - Argentina

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. --Brian W. Kernighan

-------
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:
> BTW, a:%{h} is never a syntax error for a valid HELO FQDN. (A literal
> IP is not a FQDN.)

"a:%{h}" is _never_ a syntax error, because it is valid syntax according to
the RFC 4408 grammar. To what value the %{h} expands is completely
irrelevant as far as RFC 4408 is concerned.

Yes, this may very well be considered a design flaw in SPFv1, but that's
how things are. There is no macro string expansion result validation in
SPFv1.

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

iD8DBQFGBccGwL7PKlBZWjsRAlM+AKD3ZzJJzqVBFd85ev+25fZ00m4imQCgs9Cw
EOuxKPFoqfrMJiNHlvctr38=
=j1K+
-----END PGP SIGNATURE-----

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