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

[Alessandro Vesely <[e-mail]>]

On Wed 17/Apr/2013 03:51:07 +0200 Scott Kitterman wrote:
> On Tuesday, April 09, 2013 02:24:32 AM Andrew Sullivan wrote:
> 
>> WGLC will close at 2014-04-24 00:00 UTC.
>> 
>> SM will be the shepherd for this document.
>> 
>> Best regards,
>> 
>> Andrew (for the chairs)
> 
> Just as a reminder, we're ~half way through the WGLC period

Oh, you mean the close date was a typo?

Here's my notes, mostly nits.  I pasted lots of text from the I-D, so
that issues can be evaluated even without getting at the document.


*Abstract*

 Email on the Internet can be forged in a number of ways.  In
 particular, existing protocols place no restriction on [...]

That was good in 2004, now SPF exists already.  A possible replacement
could be, e.g.:

 This document describes version 1 of the Sender Policy Framework
 (SPF) protocol, whereby an Administration Management Domain (ADMD)
 can explicitly authorize the hosts that are allowed to use its domain
 names.  A receiving host can check such authorization based on the IP
 address of the sending client and the "MAIL FROM" of a message or
 the domain given on the SMTP HELO/EHLO commands.


1. *Introduction*

   The current email infrastructure has the property that any host
   injecting mail into the system can use any DNS domain name it wants
   in each of the various identifiers specified by [RFC5321] and
   [RFC5322].

This sounds oldish too.  SPF is not the only email authentication
method.  Perhaps we could use the introduction to explain the differences.


1.2. *check_host()*

 Section 4 introduces an algorithm to evaluate an SPF policy against
 an arriving email transaction.

s/arriving email transaction/incoming email message/?


2.5. *Location of Checks*

 The authorization check SHOULD be performed during the processing of
 the SMTP transaction that sends the mail.

s/sends/receives/?


3. *SPF Records*

Do we wish to give an example of multi-line format in the zone file?


4.3. *Initial Processing*

                                        Internationalized domain names
 MUST be encoded as A-labels, as described in Section 2.3 of
 [RFC5890].on 2.3 of [RFC5890].

s/on 2.3 of [RFC5890].// once.


4.4. *Record Lookup*

 If all DNS lookups that are made return a server failure (RCODE 2),
 or other error (RCODE other than 0 or 3), or time out, then
 check_host() terminates immediately with the result "temperror".

That "all" seems to refer to the SPF and TXT types.  I'd say:

 If the query returns a server failure (RCODE 2),


4.6.4. *DNS Lookup Limits*

 These limits are per mechanism or macro in the record, and are in
 addition to the lookup limits specified above.

Hm... above where?  Perhaps splitting the section into, say:

   4.6.4.1 *Total Limits*, and
   4.6.4.2 *Particular cases*

would allow to specify it more clearly.  If you do so, then move the
following (last two) paragraphs up.


4.7. *Default Result*

OLD
   Note that records SHOULD always use either a "redirect" modifier or
   an "all" mechanism to explicitly terminate processing.
NEW
   The RECOMMENDED practice is to use either a "redirect" modifier or
   an "all" mechanism to explicitly terminate the record.

(A reader has no way to actually "note" that, and modifiers don't
always terminate processing.)


5. *Mechanism Definitions*

OLD
 Designated sender mechanisms are used to designate a set of <ip>
NEW
 Designated-sender mechanisms are used to qualify a set of <ip>

(Just avoiding to explain a term with itself.)

                                       SPF implementations on IPv6
 servers need to handle both "AAAA" and "A" secords, for clients on
 IPv4 mapped IPv6 addresses [RFC4291].

s/secords/records/


5.2. *"include"*

<vspace/>
          <!-- FIXME: prevent automatic line break after '"mx:' -->

I have no suggestions.  Do we need it?



5.5. *"ptr" (do not use)*

                           After many years of SPF deployment
 experience it has been concluded it is unnecessary and more reliable
 alternatives used instead.

Maybe it's me, or the page break, but I think a comma after
"experience" would make it more readable.


5.6. *"ip4" and "ip6"*

Production rules can be set as mentioned in
http://www.ietf.org/mail-archive/web/spfbis/current/msg03266.html



6.1. *redirect: Redirected Query*

There is no statement on whether redirect= can be applied by an
"include" mechanism.


6.2. *exp: Explanation*

 If check_host() results in a "fail" due to a mechanism match (such as
 "-all"), and the "exp" modifier is present, then [...]

This is incomprehensible after the reorganization.  I'd add "and the
verifier is going to reject the message", and a link to Section 8.4 Fail.


8. Result Handling

                     As such, there is no normative requirement for
 message handling in response to any particular result.  This section
 is provided to present a complete picture of the likely cause of each
 result, and where available, the experience gained during
 experimental deployment.

Please remove those two sentences, as they are not true.  We could say
there is no normative requirement for rejecting a message.  But, for
example, for softfail we correctly have normative requirements:

 Receiving software SHOULD NOT reject the message based solely on this
 result, but MAY subject the message to closer scrutiny than normal.

This not holds for 10.2. Receivers too.


8.2. *Neutral*

 A "neutral" result indicates that although a policy for the identity
 was discovered, there is no definite assertion about the (positive or
 negative) about the client.

Remove the first "about the".


8.7. *Permerror*

                                                  It is also possible
 that this result is generated by certain SPF clients due to the input
 arguments having an unexpected format; see Section 4.8.

I'd s/client/verifiers/.  Raw "client" throughout the document refers
to SMTP clients.  "SPF client" is mentioned a few times and could
cause confusion.

There is no mention of "exp".  Is its usage permitted/recommended?

Missing reference to Appendix H.3, but see below.


9.2. *SPF Results in the Authentication-Results Header Field*

 It is, however, possible to add CFWS in the "reason" part of an
 Authentication-Results header field and provide the equivalent
 information, if desired.

s/CFWS/key-value pairs/?


10. Effects on Infrastructure

 a comprehensive list of what such entities SHOULD do in light of this
 document.

Is that /meant/ to be normative?


10.1.2. Administrator's Considerations

 changes are common, it is better to use the less resource intensive
 mechanisms like "ip4" and "ip6" over "a" or "a" or "mx".

s/"a" or "mx"/"a" over "mx"/

 The hostname is generally the identity used in the 5321.HELO/.EHLO
 command.  In the case of messages with a null 5321.MailFrom, this is
 used as the domain for 5321.MailFrom SPF checks, in addition to being
 used in 5321.HELO/.EHLO based SPF checks.

"hostname" is called "domain" in the previous paragraph, and the long
slash-dot form of the names is used.  In addition to reword that, it
may be worth to note that [e-mail] can be used as an
address even if there's no corresponding MX.


10.2. *Receivers*

                       As stated elsewhere in this document, there is
 no normative requirement for specific handling of a message based on
 any SPF result.

See 8. Result Handling above.


11.1. *Processing Limits*

                         Using SPF clients also allows the attacker to
    hide the true source of the attack.

s/clients/verifiers/.


11.5.1. *Recorded Results*

 This information, passed to the receiver in the Received-SPF: or
 Authentication-Results: trace fields, may be returned to the client
 MTA as an SMTP rejection message.  If such an SMTP rejection message

s/may/can/ if needed.


Appendix H. *Local Policy Considerations*

Do we still need to have this text in an appendix?  It seems to be
possible to insert each subsection within the relevant subsection of
Section 8.  IMHO that would improve clarity.

Considerations for temperror are missing, anyway.


Appendix I. *Protocol Status*

s/techincal/technical/

P.S.: what widely deployed extensions to SPF?


Appendix J. *Change History*

    Resolved Section 2.5.7 PermError on invalid domains after macro
    expansion errata in favor of documenting that different clients
    produce different results.

s/clients/verifiers/.