Mailing List Archive

On Thu, 14 Dec 2006, Scott Kitterman wrote:

> "If all DNS lookups that are made return a server failure..."
>
> the tests should be
>
> type TXT responds
> type SPF times out (servfail)
>
> result - whatever the TXT response dictates
>
> type SPF responds
> type TXT times out (servfail)
>
> result - whatever the SPF response dictates
>
> type TXT times out (servfail)
> type SPF times out (servfail)
>
> temperror

Already had 'em. One of the first entered. Cases are:

spftimeout, txttimeout, alltimeout

> Since querying both RR types is NOT required, if an implementation only
> queries one RR type, then temperror may be an appropriate response for either
> of the first two cases.

Yep.

Why do you bring it up? Which implementation flunks?

--
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 14 December 2006 16:50, Stuart D. Gathman wrote:
> On Thu, 14 Dec 2006, Scott Kitterman wrote:
> > "If all DNS lookups that are made return a server failure..."
> >
> > the tests should be
> >
> > type TXT responds
> > type SPF times out (servfail)
> >
> > result - whatever the TXT response dictates
> >
> > type SPF responds
> > type TXT times out (servfail)
> >
> > result - whatever the SPF response dictates
> >
> > type TXT times out (servfail)
> > type SPF times out (servfail)
> >
> > temperror
>
> Already had 'em. One of the first entered. Cases are:
>
> spftimeout, txttimeout, alltimeout
>
> > Since querying both RR types is NOT required, if an implementation only
> > queries one RR type, then temperror may be an appropriate response for
> > either of the first two cases.
>
> Yep.
>
> Why do you bring it up? Which implementation flunks?

None now, but Julian found an issue with Mail::SPF earlier today and it was
passing the test suite even though it would temperror on txttimeout with an
SPF response.

I guess we need to figure out why it passed that test condition when it didn't
actually do it.

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, 14 Dec 2006, Scott Kitterman wrote:
> > I think we need to add a case for para 4.4 where is says:
> > "If all DNS lookups that are made return a server failure..."
> > [...]
>
> Already had 'em. One of the first entered. Cases are:
>
> spftimeout, txttimeout, alltimeout
>
> [...]
>
> Why do you bring it up? Which implementation flunks?

We were talking on #spf.

FYI, I brought up there the fact that Mail::SPF was generally RFC-
conforming except for one odd case:

| Currently, Mail::SPF ignores DNS errors on the SPF-type look-up but fully
| escalates them on the TXT-type look-up. So if "all look-ups that are
| made" get a DNS error (other than NXDOMAIN) or time out, then Mail::SPF
| does the right thing because the TXT look-up will throw a TempError.
|
| If at least one record is returned by the SPF-type look-up, no TXT-type
| look-up is performed (so nothing can go wrong with the TXT-type look-up
| anyway).
|
| However, if the SPF-type look-up succeeds and returns 0 records, and the
| following TXT-type look-up errors or times out, then Mail::SPF throws a
| TempError even though it shouldn't.

I fixed this tiny bug already. Because it is so tiny, I won't make another
release immediately just for that.

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

iD8DBQFFgclmwL7PKlBZWjsRAngmAKCE2+O3gEIGMcKk8PkoiCHu0LpLhACgtqwj
UCCYf+rnsH6zyBIR6XeXhF0=
=J0Ah
-----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

Scott Kitterman wrote:
> [...] Julian found an issue with Mail::SPF earlier today and it was
> passing the test suite even though it would temperror on txttimeout with
> an SPF response.
>
> I guess we need to figure out why it passed that test condition when it
> didn't actually do it.

Mail::SPF passed because the bug appeared only when the SPF-type look-up
succeeded but returned 0 (zero) answer records. If some answer records
are returned, then no TXT-type look-up would be done anyway and thus it
could not fail in the first place.

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

iD8DBQFFgcp2wL7PKlBZWjsRAk2jAKCuDuxdwpIwwy7uX1Xx4b9LpLUUcgCfSzeE
ciTZwImAn2zGYxuncsGp+I8=
=poMj
-----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, 14 Dec 2006, Julian Mehnle wrote:

> | However, if the SPF-type look-up succeeds and returns 0 records, and the
> | following TXT-type look-up errors or times out, then Mail::SPF throws a
> | TempError even though it shouldn't.

This is a correct result - it is the result you would get from looking at
TXT only. However, I can add another test case for this condition,
and make None the preferred result (since you really should look at SPF
if you can). Then you should get a warning if you get permerror.

I have committed the new test case. FWIW, pyspf also gets temperror
(and gets a WARN from the test suite) in that condition. It checks TXT first,
and doesn't check SPF in case of temperror (already wasted too much time).
That is a legal result. The only efficient way to handle it is to
query in parallel.

--
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 14 December 2006 17:59, Stuart D. Gathman wrote:
> On Thu, 14 Dec 2006, Julian Mehnle wrote:
> > | However, if the SPF-type look-up succeeds and returns 0 records, and
> > | the following TXT-type look-up errors or times out, then Mail::SPF
> > | throws a TempError even though it shouldn't.
>
> This is a correct result - it is the result you would get from looking at
> TXT only. However, I can add another test case for this condition,
> and make None the preferred result (since you really should look at SPF
> if you can). Then you should get a warning if you get permerror.

I would say that TempError is a correct result. It wasn't correct for
Mail::SPF because it did look for TXT type.

> I have committed the new test case. FWIW, pyspf also gets temperror
> (and gets a WARN from the test suite) in that condition. It checks TXT
> first, and doesn't check SPF in case of temperror (already wasted too much
> time). That is a legal result. The only efficient way to handle it is to
> query in parallel.

That's an RFC correct result because it looks at TXT and does not look at SPF
if it gets a TempError. In that case it gets an error result for all queries
(what RFC 4408 demands).

Scott K

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

On Thu, 14 Dec 2006, Scott Kitterman wrote:

> I would say that TempError is a correct result. It wasn't correct for
> Mail::SPF because it did look for TXT type.

Getting the right result for the wrong reason is not something the
test suite can help with.

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

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

Julian Mehnle wrote on spf-devel:
> We were talking on #spf.
>
> FYI, I brought up there the fact that Mail::SPF was generally RFC-
> conforming except for one odd case:
>
> | Currently, Mail::SPF ignores DNS errors on the SPF-type look-up but
> | fully escalates them on the TXT-type look-up. So if "all look-ups
> | that are made" get a DNS error (other than NXDOMAIN) or time out, then
> | Mail::SPF does the right thing because the TXT look-up will throw a
> | TempError.
> |
> | If at least one record is returned by the SPF-type look-up, no
> | TXT-type look-up is performed (so nothing can go wrong with the
> | TXT-type look-up in the first place).
> |
> | However, if the SPF-type look-up succeeds and returns 0 records, and
> | the following TXT-type look-up errors or times out, then Mail::SPF
> | throws a TempError even though it shouldn't.
>
> I fixed this tiny bug already. Because it is so tiny, I won't make
> another release immediately just for that.

FYI, this has now been fixed with the 2.003 release of Mail::SPF. From the
changelog:

| * Fixed a very minor bug where a "TempError" result would incorrectly be
| returned in the very rare case when the SPF-type look-up succeeded but
| returned 0 records, and the following TXT-type look-up errored or timed
| out. Now a "None" result is correctly returned in that case as
| demanded by RFC 4408.

While I'm sure this is what the spec requires, I'm no longer sure this is a
sensible behavior. Which means that there is probably a bug in the spec.

Any comments?

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

iD8DBQFFpDaswL7PKlBZWjsRAnSWAKDDjUNhIRlFJ8nzbproqT1k4xyaDwCfRUr/
Ziv9vG9lz75PiacJpoSpZbU=
=OTX0
-----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 Wed, 10 Jan 2007, Julian Mehnle wrote:

> > | If at least one record is returned by the SPF-type look-up, no
> > | TXT-type look-up is performed (so nothing can go wrong with the
> > | TXT-type look-up in the first place).
> > |
> > | However, if the SPF-type look-up succeeds and returns 0 records, and
> > | the following TXT-type look-up errors or times out, then Mail::SPF
> > | throws a TempError even though it shouldn't.
> >
> > I fixed this tiny bug already. Because it is so tiny, I won't make
> > another release immediately just for that.
...
>
> While I'm sure this is what the spec requires, I'm no longer sure this is a
> sensible behavior. Which means that there is probably a bug in the spec.
>
> Any comments?

Yes. You are condemning Mail::SPF for impure motives. The external
behaviour (of throwing TempError) is perfectly all right by the spec.
This is because you all allowed to lookup only TXT records. If you
lookup only TXT records, and get an error, you should throw TempError.
So TempError is a perfectly valid result for that situation. The fact
that you feel the internal motivation for the result is wrong (since you
had already looked to type SPF records), doesn't make the result invalid.

Pyspf *deliberately* return TempError in that situation. Whether you
feel your program returns TempError for a bad reason, or whether
I feel my program returns TempError for a good reason is a subjective
judgement. Whether the result is valid or invalid is an objective
determination. The TempError result is valid, and allowed by the spec.

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

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

Stuart D. Gathman wrote:
> Yes. You are condemning Mail::SPF for impure motives. The external
> behaviour (of throwing TempError) is perfectly all right by the spec.
> This is because you all allowed to lookup only TXT records. If you
> lookup only TXT records, and get an error, you should throw TempError.
> So TempError is a perfectly valid result for that situation. The fact
> that you feel the internal motivation for the result is wrong (since you
> had already looked to type SPF records), doesn't make the result
> invalid.
>
> Pyspf *deliberately* return TempError in that situation. Whether you
> feel your program returns TempError for a bad reason, or whether
> I feel my program returns TempError for a good reason is a subjective
> judgement. Whether the result is valid or invalid is an objective
> determination. The TempError result is valid, and allowed by the spec.

According to your reasoning it would be OK to check both SPF and TXT types
and, if either returns zero records, return an overall result of "None".
After all, I could just pretend I only made _one_ lookup -- the one that
returned zero records.

Sorry for this sounding slightly sarcastic. But I think this is really an
issue with the spec not caring enough for keeping the composite (SPF+TXT)
lookup results sufficiently coherent with the single-type lookup results.

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

iD8DBQFFpO4EwL7PKlBZWjsRAkB9AKDsovRGTfPBrfEkdRwSBQeBJSZvrwCgid1I
na2h+7TzBM2G+1tcuB7jVGA=
=P1Lp
-----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 Wed, 10 Jan 2007, Julian Mehnle wrote:

> > Pyspf *deliberately* return TempError in that situation. Whether you
> > feel your program returns TempError for a bad reason, or whether
> > I feel my program returns TempError for a good reason is a subjective
> > judgement. Whether the result is valid or invalid is an objective
> > determination. The TempError result is valid, and allowed by the spec.
>
> According to your reasoning it would be OK to check both SPF and TXT types
> and, if either returns zero records, return an overall result of "None".
> After all, I could just pretend I only made _one_ lookup -- the one that
> returned zero records.

You are exactly correct. That would be an (objectively) valid result. However,
I would certainly (subjectively) consider that a bug, since having *some* SPF
record is desireable (whereas I would rather reject for TEMPERROR and
reduce the spam flow than deal with a NONE).

> Sorry for this sounding slightly sarcastic. But I think this is really an
> issue with the spec not caring enough for keeping the composite (SPF+TXT)
> lookup results sufficiently coherent with the single-type lookup results.

The spec leaves much of the behaviour of conflicting TXT/SPF records
undefined (the only thing defined is that if there are any SPF records
you ignore the TXT records). You will notice in the test suite that
there are 2 valid results for every TXT/SPF conflict situation. There
are 3 implementation choices - TXT only, SPF only, BOTH. You can choose
your implementation on the fly depending on what is convenient.

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

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

Stuart D. Gathman wrote:
> On Wed, 10 Jan 2007, Julian Mehnle wrote:
> > Sorry for this sounding slightly sarcastic. But I think this is
> > really an issue with the spec not caring enough for keeping the
> > composite (SPF+TXT) lookup results sufficiently coherent with the
> > single-type lookup results.
>
> The spec leaves much of the behaviour of conflicting TXT/SPF records
> undefined (the only thing defined is that if there are any SPF records
> you ignore the TXT records). You will notice in the test suite that
> there are 2 valid results for every TXT/SPF conflict situation. There
> are 3 implementation choices - TXT only, SPF only, BOTH. You can choose
> your implementation on the fly depending on what is convenient.

I don't think this is a sane notion -- no offense! An implementation
should exhibit some defined and _consistent_ behavior, not decide on the
fly whatever result is "convenient".

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

iD8DBQFFpQz7wL7PKlBZWjsRAuDsAJ9mxbZh5deauWN7rEOGMRMnReZY7gCgrJru
pUBaaCMiPIXiFWyJ0czqQqA=
=4kcM
-----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 Wed, 10 Jan 2007, Julian Mehnle wrote:

> I don't think this is a sane notion -- no offense! An implementation
> should exhibit some defined and _consistent_ behavior, not decide on the
> fly whatever result is "convenient".

It *does* have a defined and consistent behavior - that dynamically adapts
to the situation.

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

>> Adding that to your table I'd say:
>> | SPF type |
>> +-----------+-----------+-----------+--------------+
>> | no v=spf1 | no record | time-out | RCODE != 0/3 |
>> ----+--------------+-----------+-----------+-----------+--------------+
>> [...]

> I'm not sure that starting to make that distinction is a good idea.
> That concept is entirely new to SPF.

It's an excellent test case for this thread with about 100 articles.
In the simplified 3*3 table we get two interesting cases:

| SPF type |
+-----------+-----------+------------+
| no v=spf1 | no record | timeout |
| | | or not 0/3 |
----+------------+-----------+-----------+------------+
| no v=spf1 | None | None | None |
+------------+-----------+-----------+============*
| no record | None | None ! None !
+------------+-----------*===========*============*
TXT | timeout | None ! TempError ! TempError |
| or not 0/3 | ! ! |
----+------------+-----------*===========*------------+

The first relevant case is "no TXT record, and timeout or error for
SPF". That's probably a braindead name server, and then the result
should be NONE.

The 2nd interesting case is "no SPF record, and timeout or error
for TXT". Then the server at least isn't braindead, but maybe the
sender has not published a SPF RR (e.g. my ISP). Therefore the TXT
result TempError might be better than NONE (?)

Or maybe I'm wrong, but we should have these two scenarios in the
test suite if that's possible.

Frank


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

On Wed, 10 Jan 2007, Frank Ellermann wrote:


> Or maybe I'm wrong, but we should have these two scenarios in the
> test suite if that's possible.

Those scenarios have been in the test suite. Your table does not
include whether the implementation is TXT only, SPF only, or BOTH.
Because of that, many of your table entries actually have two
valid answers:
| SPF type |
+-----------+-----------+------------+
| no v=spf1 | no record | timeout |
| | | or not 0/3 |
----+------------+-----------+-----------+------------+
| no v=spf1 | None | None |None/TempErr|
+------------+-----------+-----------+============*
| no record | None | None !None/TempErr!
+------------+-----------*===========*============*
TXT | timeout | None/ ! TempError ! TempError |
| or not 0/3 | TempError ! /None ! |
----+------------+-----------*===========*------------+

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

Stuart D. Gathman wrote:

> Your table does not include whether the implementation is
> TXT only, SPF only, or BOTH.

TXT only is only the first column, SPF only is only the first
row. The rest of my 3*3 table (four cells) is only for BOTH.

Frank


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

On Thu, 11 Jan 2007, Frank Ellermann wrote:

> Stuart D. Gathman wrote:
>
> > Your table does not include whether the implementation is
> > TXT only, SPF only, or BOTH.
>
> TXT only is only the first column, SPF only is only the first
> row. The rest of my 3*3 table (four cells) is only for BOTH.

Your table enumerates cases of DNS state. I'm talking about implementation
choices. RFC 4408 gives you 3. You could think of it an a 3x3x3 cube.
Or, I just project the cube onto DNS state to show all valid results
for a given DNS state (as I did in the previous email).

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

Stuart D. Gathman wrote:

>> TXT only is only the first column, SPF only is only the first
>> row. The rest of my 3*3 table (four cells) is only for BOTH.

> Your table enumerates cases of DNS state. I'm talking about
> implementation choices. RFC 4408 gives you 3.

Yes. My 3*3 table is for BOTH. A TXT only implementation would
only see what's in the first column, and SPF only would only see
what's in the first row. And of course my first column and my
first row are identical: NONE (no v=spf1) + NONE (no record) +
TempError (timeout or error).

However the 2nd / 3rd row / column are not identical (which might
be wrong, but it's an interesting test case for implementations
doing BOTH), because "no SPF record + TXT error" might be not the
same as "no TXT record + SPF error".

Because you said here months ago that "SPF error" can be caused
by braindead servers, while "no SPF record" can be a harmless
case of "TXT policy published before type=99 was introduced".

You probably won't like to annoy publishers forced to use such
braindead servers with TempErrors, but if there server is okay
(no SPF record) you'd report issues with their TXT record as a
TempError. Or maybe that's not how you implemented it, but the
"correct" way isn't obvious for me, therefore having it in the
test suite is good.

You said it's already there => ready. Probably I misunderstood
the subject of this thread, don't worry, shit happens... :-)

And if you see "no v=spf1" (no matter on which side, TXT or SPF),
then you'd be sure (?) that the result is NONE if the other side
results in a timeout or error, because it makes no sense to have
good TXT (or SPF) records without v=spf1, plus an SPF (or TXT)
with v=spf1. If both RRs exist and work, they either both have
v=spf1, or they both don't have it.

Frank


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