spf-discuss
[Top] [All Lists]

For SPF council review: NOT RECOMMENDED

2005-05-07 10:40:28
Personally, I like NOT RECOMMENDED, but not at the expense of having an RFC.  
From the last council meeting:

Note:  freeside = Meng

21:57   <freeside> because wayne's spec goes out of its way to
                   antagonize the PRA use of records, yes.
21:57            * grumpy realized on the way home that he *added* an
                   hour to EDT instead of subtracted.
21:57   <freeside> specifically, the bit that says
21:57   <freeside> Checking other identities against SPF records is NOT
                   RECOMMENDED
21:57   <freeside> because there are cases (e.g. Section 9.3) that are
                   known to give
21:57   <freeside> incorrect results.
21:58            * grumpy tries to catch up
21:58   <freeside> it's not really necessary to say that, and if the SPF
                   spec remains silent on that point, then it really
                   increases the likelihood that we'll get an RFC out of
                   it.

Now I have no idea if Meng's right or wrong, but if this is the sticking point 
that keeps us from getting an RFC, then we ought not go down in flames over it 
because no matter what our RFC says, it isn't going to stop people doing what 
they want with v=spf1 records.  I have two questions for the council:

1.  If NOT RECOMMENDED will keep us from getting an RFC, should we change it?

2.  If so, how do we change it?

Here's my suggestion for #2....

schlit-01-pre5:

"Checking other identities against SPF records is NOT RECOMMENDED because there 
are cases (e.g.  Section 9.3) that are known to give incorrect results."

Alternative:

"If other identities are checked against SPF version 1 [I think this is the 
change Wayne said he already made] records, then that check MUST produce the 
same result as checks described in this draft."

This would be better for several reasons:

1.  It gets rid of NOT RECOMMENDED, but the MUST is actually stronger.

2.  It puts the burden on others to show they would get the same result.

3.  It's hard to argue with.  Domain owners published their records with 
certain expectations in mind.  Do whatever you want with them, but you have to 
meet those expectations.

4.  From what little I remember about Sender-ID (I've tried hard to forget), I 
can envision some caveats that MS could put in their draft about when PRA 
should be checked that would meet this requirement.  So, if they are in a mood 
to compromise, there is room for it without us having actually given up 
anything.


Scott Kitterman