Subject: Re: [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.txt

From: S Moonesamy <[email-masked]>
Date: Mon, 29 Apr 2013 07:05:57 -0700

Hi Cyrus,

Thanks for the review.  I am forwarding it to the 
SPFBIS mailing list for the working group to 
discuss.  I'll follow-up on apps-discuss@ after that.

Regards,
S. Moonesamy (as document shepherd)

>I have been selected as the Applications Area 
>Directorate reviewer for this draft (for 
>background on appsdir, please see 
>â€‹http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
>
>Please resolve these comments along with any 
>other Last Call comments you may receive. Please 
>wait for direction from your document shepherd 
>or AD before posting a new version of the draft.
>
>Document: draft-ietf-spfbis-4408bis-14.txt
>Title: Sender Policy Framework (SPF) for 
>Authorizing Use of Domains in Email, Version 1
>Reviewer: Cyrus Daboo
>Review Date: 2013-04-29
>
>Summary: This draft is almost ready for 
>publication as an RFC, subject to some minor issues that should be resolved.
>
>Overview: This document is an update to RFC4408 
>that seeks to upgrade the specification from 
>experimental status, clarifying a number of 
>issues in the original specification, providing 
>in depth detail of actual deployment experience, 
>and documenting various extensions now in common 
>use. The new draft achieves these aims and 
>provides a good reference for implementors.
>
>Major Issues: None
>
>Minor Issues:
>
>         Section 4.6.1 ABNF terms "A / MX / PTR 
> / IP4 / IP6" are upper case but terminal terms 
> are lower case in Section 5 (but uppercase in 
> Appendix A). Looks like these need fixing in Section 5.
>
>         Section 6.2 Paragraph 6 There is a 
> reference to Section 2.6.4 but that section 
> does not contain anything relevant. Either 
> remove the reference or point to a relevant section.
>
>         Section 7.1 Paragraph 2 States "subject 
> to LDH rule" - that needs a reference to 
> RFC3696 Section 2 (reference was in RFC 4408).
>
>Section 11.3 Why no mention of DNSSEC as a way 
>to alleviate this issue? Has anyone been using 
>DNSSEC with SPF? If not, why not?
>
>Nits:
>
>         Section 2.4 (argument list) and Section 
> 4.1 appear to duplicate similar information - 
> consider removing the list of args in Section 2.4 and add a reference to $4.1.
>
>         Section 2.5 Paragraph 2 First part of 
> sentence hard to read - break it up with commas.
>
>         Section 2.6 and Section 8 appear to 
> duplicate a lot of similar information. Please 
> consider trimming down Section 2.6 and have it 
> refer to Section 8 for full details.
>
>         Section 3.5 Paragraph 1 Has the word 
> "discouraged". Shouldn't this use a 2119 term, e.g.: "NOT RECOMMENDED"?
>
>         Section 6.1 Paragraph 1 Remove second 
> sentence - pretty much the same as the first one.
>
>         Section 6.2 Paragraph 4 Put exp in double-quotes.
>
>         Section 10 Paragraph 1 SHOULD - in this 
> context it is not really appropriate to use a 2119 term. Please rephrase.
>
>         Various places: permerror is sometimes 
> used without double-quotes around it - I think 
> all uses should have double-quotes.
>
>
>--
>Cyrus Daboo
>

---

From: Hector Santos <[email-masked]>
Date: Mon, 29 Apr 2013 16:49:52 -0400

On 4/29/2013 10:05 AM, Cyrus Daboo wrote:
>          Section 2.6 and Section 8 appear to duplicate a lot of similar
> information. Please consider trimming down Section 2.6 and have it refer
> to Section 8 for full details.

I agree with this and suggested this in recent comments myself.  I 
suggest to include as well Section 8 with Appendix H, coupled the 
security Section 11.7.  All these can be merged to Section 8 for "full 
details."

The ambiguous verbosity is not necessary for two basic protocol actions 
the protocol MUST take for SPF FAIL Domain published policies:

      FAIL + SMTP REJECT
      FAIL + SMTP ACCEPT + MDA/MUA Separation by back end.
                           -------------------------------
                                 Section 11.7

In other words, section 11.7 was only written based on the issue report 
(by me) to highlight the security repercussions and protocol damaging of 
not doing what is expected in section 2.6 by SMTP for SPF FAIL published 
policies - rejection. It you don't reject, but accept the mail, then you 
MUST at least separate the mail.

If anything, security Section 11.7 should only need to say:

       You MUST NOT deliver the SPF failed, unauthorized
       domain mail to users without a clear separation of
       security status of the mail!

And nothing else more is needed to be said.

--
HLS