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

Scott Kitterman <spf2@kitterman.com> Sat, 20 April 2013 22:06 UTC

Return-Path: <spf2@kitterman.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4116921F92CB for <spfbis@ietfa.amsl.com>; Sat, 20 Apr 2013 15:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzOsRLWD6Em2 for <spfbis@ietfa.amsl.com>; Sat, 20 Apr 2013 15:06:05 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A5F5621F8FB3 for <spfbis@ietf.org>; Sat, 20 Apr 2013 15:06:02 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C6D9E20E40D2; Sat, 20 Apr 2013 18:06:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366495561; bh=xjFY8cTAaO8nrhqc7+vH66pku4N5Dukt2Ydnupiu8HI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bsjOLn64zwGReQ9VN5OUut8xUrxeq73AOqJ83+AGRK6pnz21OmgYFgcEu69tch2S9 rBpTtARWxD+DwGNPrENgXiJZ25xRAKaJWjCL8dSgLgk+2/Kd7e28aVEkAnTTkXbffm uWEGoZzIgpcc8F0NGLTymMZcVPefyvmrUKkMjspM=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AA74C20E409E; Sat, 20 Apr 2013 18:06:01 -0400 (EDT)
From: Scott Kitterman <spf2@kitterman.com>
To: spfbis@ietf.org
Date: Sat, 20 Apr 2013 18:06:00 -0400
Message-ID: <5830786.tCECZPYMZs@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <517030ED.20501@tana.it>
References: <20130409062431.GK24624@mx1.yitter.info> <9424963.YHzqPUZEKJ@scott-latitude-e6320> <517030ED.20501@tana.it>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spfbis>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Apr 2013 22:06:07 -0000

On Thursday, April 18, 2013 07:44:13 PM Alessandro Vesely wrote:
> 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?

No.  April 17 is roughly half way between April 9 and April 24.

> 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.

I would rather not rewrite the abstract at this stage.  Yes, SPF has existed 
for a long time, but for many it's been "only an experiment", so I think the 
current text is good.

> 
> 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.

We did discuss including information about DKIM and how it related to SPF, but 
there was push back. I think that since anything about DKIM is out of scope, 
we ought not get into it.  No where in the existing text does it claim SPF is 
the only solution.

> 
> 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/?

That seems OK to me, but I didn't write that, so I'll wait for others to chime 
in to change it.
> 
> 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/?

Fixed locally. 
> 
> 3. *SPF Records*
> 
> Do we wish to give an example of multi-line format in the zone file?

No, I think zone file tutorials are out of scope.  There's plenty of 
documentation on making zone files and not everyone uses BIND anyway.
> 
> 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.

Fixed locally.
> 
> 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),

Fixed locally.  I kept DNS lookup instead of query, but it's all singular now.
> 
> 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.

above is the previous paragraph.

I'm not sure that helps.  I'd like to hear other opinions.
> 
> 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.)

I got rid of "Note that" and I also changed the word included to provided at 
the end of the paragraph (to avoid possible confusion about the include 
mechanism).
> 
> 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.)

Fixed using identify in place of designate.

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

Fixed locally.
> 
> 5.2. *"include"*
> 
> <vspace/>
>           <!-- FIXME: prevent automatic line break after '"mx:' -->
> 
> I have no suggestions.  Do we need it?

No.  Not needed, so removed. 
> 
> 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.

Added.
> 
> 5.6. *"ip4" and "ip6"*
> 
> Production rules can be set as mentioned in
> http://www.ietf.org/mail-archive/web/spfbis/current/msg03266.html

I think RFC 4291 is a better source for IPv6 than RFC 3986.  For IPv4, that 
looks like it might be a good idea.  I'd appreciate input from people with 
more ABNF experience than me before I change anything.
> 
> 
> 6.1. *redirect: Redirected Query*
> 
> There is no statement on whether redirect= can be applied by an
> "include" mechanism.

I don't understand the question?
> 
> 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.

When I first looked at this, I agreed with you, but you have to consider that 
when the document is referring to 'returning' the explanation, it's 
check_host() returning it to the calling application.  Check_host() doesn't 
know if the message will be rejected or not. 

I've added "... MUST be returned to the calling application." to the end of 
the paragraph to (hopefully) clarify this.

> 
> 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.

The statement is generally true, but as you state not 100% correct.  I've 
added the word comprehensive so that it now reads, "... comprehensive 
normative requirement ..." to make it clearer that this is generally true even 
though there are a few exceptions.

> This not holds for 10.2. Receivers too.

I tried to clarify it there too.  The relevant sentence now reads:

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

I think that clears it up.
> 
> 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".

Done locally.
> 
> 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.

Done locally.

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

No.  Exp is a message from the sending domain back to senders of mail from the 
domain that fails SPF checks.  It's appropriate for receivers to send sensible 
text back with the 550 if they reject due to permerror, but that's not the 
case that exp supports.

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

Fixed.  I do think we need to keep it as has been discussed in reply to your 
later message.
> 
> 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/?

msk: I think you provided this text.  Would you please comment?
> 
> 10. Effects on Infrastructure
> 
>  a comprehensive list of what such entities SHOULD do in light of this
>  document.
> 
> Is that /meant/ to be normative?

I think you missed the not.  "... not a comprehensive list of what such 
entities SHOULD do ..."  No.  It's not 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 x@relay.example.com can be used as an
> address even if there's no corresponding MX.

I'm not sure what you're after here, would you please provide text so I can 
better understand?  Also, due to the implicit MX fallback to A, any host with 
an A record can receiver mail, so I don't understand why "evern if there's no 
MX" is relevant to anything.

> 
> 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.
> 
Fixed.  See above.

> 11.1. *Processing Limits*
> 
>                          Using SPF clients also allows the attacker to
>     hide the true source of the attack.
> 
> s/clients/verifiers/.

Fixed locally.
> 
> 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.

Made it can.
> 
> 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.

Yes.  I think it needs to be in the appendix as discussed in the other thread.

> Considerations for temperror are missing, anyway.

OK.  Fixed.  I took the permerror considerations and modeled words for 
temperror on them.  I aimed to avoid novelty or controversy.  Let's see if I 
succeeded.  Here's what I added locally:

> H.4.  Policy For SPF Temperror
> 
>    The "temperror" result (see Section 2.6.6) indicates the SPF
>    processing module at the receiver could not retrieve and SPF policy
>    record due to a (probably) transient condition.  This gives no true
>    indication about the authorized use of the data found in the
>    envelope.
>    
>    As with all results, implementers have a choice to make regarding
>    what to do with a message that yields this result.  SMTP allows only
>    a few basic options.
> 
>    Deferring the message is an option, in that it is the one thing a
>    receiver can do to draw attention to the difficulty encountered while
>    protecting itself from messages that do not have a definite SPF
>    result of some kind.  However, if the SPF implementation is defective
>    and returns spurious "temperror" results, only the sender is actively
>    notified of the defect (in the form of mail rejected after it times
>    out of the sending queue), and not the receiver making use of SPF.
>    
>    Because of long queue lifetimes, it is possible that mail will be
>    repeatedly deferred for several days and so any awareness by the
>    sender of a problem could be quite delayed.  If "temperrors" persist
>    for multiple delivery attempts, it might be perferable to treat the
>    error as permanent and reduce the amount of time the message is in
>    transit.
>    
>    The less intrusive handling choice is to deliver the message, perhaps
>    with some kind of annotation of the difficulty encountered and/or
>    logging of a similar nature.  However, this will not be desirable to
>    operators that wish to implement SPF checking as strictly as
>    possible, nor is this sort of passive problem reporting typically
>    effective.
>    
>    There is of course the option placing this choice in the hands of the
>    operator rather than the implementer since this kind of choice is
>    often a matter of local policy rather than a condition with a
>    universal solution, but this adds one more piece of complexity to an
>    already non-trivial environment.
>    
>    Both implementers and operators need to be cautious of all choices
>    and outcomes when handling SPF results.

How's that?

> Appendix I. *Protocol Status*
> 
> s/techincal/technical/

Fixed locally.

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

As I recall, the two cases where we invoked widely deployed to include things 
in 4408bis (per the charter) are use of Authentication Results in place of 
Received SPF and the "void lookup" processing limit.
> 
> 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/.

Fixed locally.

Thanks for the detailed review.

Scott K