Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14

[Scott Kitterman <[e-mail]>]

On Saturday, April 20, 2013 07:46:10 PM John Levine wrote:
> These are mostly nits.  I'm not worrying about typos and minor
> grammatical issues, since the skilled staff at the RFC production
> center will find them better than I do.
> 
> 2.1 HELO identity
> 
>    Checking "HELO" promotes consistency of results and can reduce DNS
> resource usage.
> 
> I understand the consistency, but how does doing two lookups rather
> than one reduce DNS resource usage?  Suggest just removing the second
> clause.

Generally, the SPF record for HELO requires at most one additional DNS lookup, 
so even if you have a relatively low rejection rate base on these records, you 
can come out ahead on resource expenditure because it's generally an 
inexpensive check compared to Mail From records.

> 2.4  Checking Authorization
> 
>   Without explicit approval of the domain owner, checking other
>   identities against SPF version 1 records is NOT RECOMMENDED because
>   there are cases that are known to give incorrect results. For example,
>   almost all mailing lists rewrite the "MAIL FROM" identity (see Section
>   10.3), but some do not change any other identities in the message.
>   Documents that define other identities will have to define the method
>   for explicit approval.
> 
> I realize that this paragraph translates to "Sender-ID sucks", but as
> it stands it raises more questions than it answers, e.g., how would a
> receiver know what a domain owner approves, and what should I check
> then.  Since Sender-ID is dead, I suggest removing it.

That's certainly the original reason it got included, but the issue keeps 
coming up.  DMARC was forced to work around this issue very carefully (I think 
they got it right, but it was non-trivial to get there).

There are any number of schemes people have come up with to leverage the 
information in SPF records and I think it's useful to keep the words in there 
about record reuse being a bad idea.  Even though there are no internet 
police, sometimes it actually does help to be able to point to an RFC and say 
"See - it says that's wrong right here".

I'd prefer to keep it.  Let's see what others say.

>   When a mail receiver decides to perform an SPF check, it MUST use a
>   correctly-implemented check_host() function (Section 4) evaluated with
>   the correct parameters. Although the test as a whole is optional, once
>   it has been decided to perform a test it has to be performed as
>   specified so that the correct semantics are preserved between
>   publisher and receiver.
> 
> If people haven't already figured out that they have to implement the
> spec correctly, this won't help.  I suggest removing it.

It was in RFC 4408 that way, so keeping it is consistent, but I'm OK with 
removing it if we keep the other language in your previous point.

> 2.6. Results of Evaluation
> 
>   An SPF verifier implements something semantically identical to the
>   function defined there.
> 
> Suggest "semantically equivalent" to match langauge in Sec 4.

Fixed locally.

> 3. SPF Records
> 
>    The SPF record is a single string of text.
> 
> Suggest "The SPF record is interpreted as a single string of text" since in
> fact the record may well have several strings.

Fixed locally.

> 8.4. Fail
> 
> Suggest moving everything after the first paragraph to App. H.2. since
> it's basically an example.
> 
> 8.5. Softfail
> 
> Suggest moving everything after the first paragraph to a new
> subsection of App. H.  Please do our users a favor and remove the bad
> advice about highlighting failures in MUAs.

For both your comments on Fail and Softfail, my perspective is the same:

We have been through what goes in the main body and what goes into an appendix 
several times and finally got to something people are roughly happy with.  I 
would propose not having the 4408bis organization discussion again.  If people 
are really unhappy with the organization, I have several comments against it 
as well that I'll submit, but I think that we're better off to leave well 
enough alone.

> 9.2. SPF Results in the Authentication-Results Header Field
> 
> Odd bug in the xml, the last para and example are switched in
> the html output.

I found one oddity in the XML.  The output now looks like:

> 9.2.  SPF Results in the Authentication-Results Header Field
> 
>    As mentioned in Section 9, the Authentication-Results header field is
>    designed to communicate lists of tests a border MTA did and their
>    results.  The specified elements of the field provide less
>    information than the Received-SPF field:
>    
>    Authentication-Results: myhost.example.org; spf=pass
>      smtp.mailfrom=example.net
>    
>    Received-SPF: pass (myhost.example.org: domain of
>     [e-mail] designates 192.0.2.1 as permitted sender)
>        receiver=mybox.example.org; client-ip=192.0.2.1;
>        envelope-from="[e-mail]"; helo=foo.example.com;
>    
>    It is, however, possible to add CFWS in the "reason" part of an
> 
>    Authentication-Results header field and provide the equivalent
>    information, if desired.
>    
>    As an example, an expanded Authentication-Results header field might
>    look like (for a "MAIL FROM" check in this example):
>    
>    Authentication-Results: myhost.example.org; spf=pass
>      reason="client-ip=192.0.2.1; smtp.helo=foo.example.com"
>      smtp.mailfrom=[e-mail]

Is that more like what you were expecting?

Thanks for the review.

Scott K