spf-discuss
[Top] [All Lists]

Re: NOT RECOMMENDED

2005-05-07 05:09:16
Frank Ellermann wrote:
Julian Mehnle wrote:
| Checking other identities against v=spf1 records is NOT RECOMMENDED.

Oops, okay, same idea.  Any reason why want to get rid of the pointer to
9.3 ?  Wayne has explicitly added it to prevent the next assault of the
Sender-ID faction (i.e. Meng). 

Uhm, no, I didn't want to get rid of that part, I just took the text you 
falsely quoted as the original wording...

* "Checking other identities against SPF records is NOT RECOMMENDED"

...and modified it.  I erroneously added a closing full-stop at the end, 
which apparently caused the impression that I wanted to drop the rest of 
the sentence.  I don't.

Wayne, is it ok to patch -01pre5 like this?

           Checking other identities against
-          SPF records is NOT RECOMMENDED because there are cases
+          v=spf1 records is NOT RECOMMENDED because there are cases
           (e.g. <xref target="forwarding"/>) that are known to give
           incorrect results.

If yes, I'll include it in my collective -01pre5 patch in a day or two.

========================================================================

[...]
In essence SPF recreates the old source-route idea.

Huh?  You could say that about SRS, but _SPF_?

========================================================================

If a client issues two DNS queries (TXT and SPF), it should wait for
both responses, and if they don't match, throw an error

I'd never implement it this way, as soon as I get an answer I use it and
don't wait for any trouble in the form of a second different answer.

Hey, you're lucky!  The spec allows this:

| An SPF compliant check SHOULD try to look up and use a record of the
| SPF type first, before falling back to the TXT type.  However, the
| client MAY also perform lookup of both types in parallel.  If for a
| domain both types are obtained but their contents do not match, the
| SPF client SHOULD return a "PermError" result.

Note the wording "if both types are obtained".  IIRC this deliberately 
fuzzy (AKA diplomatic) wording is the result of some earlier discussions 
about exactly this issue.

Your original question just was how to do lookups "in parallel", and I 
explained how, so please don't complain.  The spec doesn't mandate it that 
way.

[...]  But that's no recipe for a straight forward SPF implementation, so
I still don't see the SHOULD. 

...because it's not there.