[spfbis] A standards track document defining SPF

[S Moonesamy <[e-mail]>]

Hello,

The second and last deliverable for the working group is to produce a 
standards track document defining SPF by December 2012.  The SPFBIS 
Charter mentions features.  Instead of commenting about features I'll 
look at this from another angle.

  (i)   RFC 4408 has not been reviewed by the IETF

  (ii)  There are multiple implementations of RFC 4408

  (iii) The Errata for RFC 4408 does not mention Issue #9

draft-ietf-spfbis-4408bis is unusual work as Experimental RFCs 
generally go through (i).  It can be argued that the draft can be 
published as a RFC with (iii) as the significant change and some 
editorial changes.  Murray Kucherawy mentioned the following [1]:

    "If I were sitting on SECDIR, I'd make some noise about this 
during Last Call,
     for example."

draft-ietf-spfbis-4408bis will be reviewed by the IETF Security 
Directorate (SECDIR).  It is expected that the working group will 
give some serious thought to the security considerations aspect 
before the Last Call.

Scott Kitterman raised an interesting point: backward incompatibility 
[2].  The question that comes to my mind is whether 
draft-ietf-spfbis-4408bis has to be backward compatible with RFC 4408.

Section 4 of RFC 4408 has the following requirement:

   "Mail receivers that perform this check MUST correctly evaluate
    the check_host() function as described here."

There is a reference in that Section 4 to Section 2.5.  In Section 
2.5.5, there is:

   'A "SoftFail" result should be treated as somewhere between a "Fail"
    and a "Neutral".'

Depending on how one interprets RFC 2119 there may or may not be a 
recommendation in that sentence.  Assuming that it is a 
recommendation (SHOULD) the "somewhere between" two possible results 
is ambiguous.

Section 5 defines the mechanisms.  Section 6 defines the 
modifiers.  I'll assume that a change in these sections can affect 
the results (Section 4).  The macros defined in Section 8 indirectly 
affects mechanisms and modifiers.

In my individual opinion RFC 4408 is not ready for publication as a 
Proposed Standard as an IESG Evaluation would generate DISCUSSes 
(issues the working group must fix).

Kurt Andersen commented about why "management elected to discontinue 
the use of all SPF records [3].  Derek Diget mentioned that 'as a 
email admin, I am starting to feel that the more that is deprecated 
or removed, the more that I will run into issues with a sender saying 
one thing (either a "legacy" 4408 SPF record or an updated 4408bis 
SPF record) and my (receiver) software evaluating it differently than 
the publisher wanted' [4].

draft-ietf-spfbis-experiment did not generate any DISCUSSes as the 
working group discussed the issues and possible issues.  My suggestions are:

   1. Demonstrate that a RFC 4408 implementation and a 
draft-ietf-spfbis-4408bis
      implementation will produce the same results

   2. If (1) is not possible, provide an explanation for the change

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg01879.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg01888.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01889.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg01902.html