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

"Murray S. Kucherawy" <superuser@gmail.com> Tue, 23 April 2013 18:03 UTC

Return-Path: <superuser@gmail.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 C2F0121F96EF for <spfbis@ietfa.amsl.com>; Tue, 23 Apr 2013 11:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.71
X-Spam-Level:
X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 mgBrFBMAdp4q for <spfbis@ietfa.amsl.com>; Tue, 23 Apr 2013 11:03:39 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7E21F96EE for <spfbis@ietf.org>; Tue, 23 Apr 2013 11:03:38 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id a12so426332wgh.11 for <spfbis@ietf.org>; Tue, 23 Apr 2013 11:03:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oTICJ4ydINBLu5LVFqgOjfnjpZUlG5d8RG6TNdwBWKE=; b=u/TscuGiGJSFYRjkuzGu9y03Zw+M0J57O5qEP1qE/wiialem685e5FOcQ6zuKCjixI j1zWMRB5BMrhwgDt9xkJSKmsfImI1ntIYkGT+7kLSI4qZ9kAc4HvX+AVJwN3KSn5yYMH qMv/cqzYCVsQZg9/vcBowFbP4WcGQJBOSSTiqSYqi2aBhEawVZZiXNPlEq5I6aJ3f1B2 A6j3EsjhSgqpKQQhkpgLVyhHimxIGOt4NTgzfD+dGxLqqObNjCrGpY/IEM7gkATGKXzh uIgJBA7gq3723LZ2zaRVdI8W37Hxht5FyAYKwqd5I67NWHizozLcqmqSWVlf9FDG9i4d 7W7A==
MIME-Version: 1.0
X-Received: by 10.180.79.69 with SMTP id h5mr40143021wix.14.1366740218155; Tue, 23 Apr 2013 11:03:38 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Tue, 23 Apr 2013 11:03:37 -0700 (PDT)
In-Reply-To: <20130409062431.GK24624@mx1.yitter.info>
References: <20130409062431.GK24624@mx1.yitter.info>
Date: Tue, 23 Apr 2013 11:03:37 -0700
Message-ID: <CAL0qLwYkudUHYrGmsHyOLsB76j=Zrn5NCCacVnd1ncG=sQNmyg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary="f46d043c062e341ab104db0b01bb"
Cc: "spfbis@ietf.org" <spfbis@ietf.org>
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: Tue, 23 Apr 2013 18:03:40 -0000

On Mon, Apr 8, 2013 at 11:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com>wrote:

> Dear colleagues,
>
> This message initiates a two-week working group last call on
> draft-ietf-spfbis-4408bis-14, our only work item.
>
> The draft has been through 14 revisions, and all open issues in the
> tracker are closed.  Please review the document and indicate any
> comments you have by sending a note to the mailing list.  If you have
> no comments, it is valuable nevertheless to learn that you have read
> the document and support its publication.
>
> WGLC will close at 2014-04-24 00:00 UTC.
>
> SM will be the shepherd for this document.
>

Most of this is nits; except as noted, you could ignore it all and I'd be
happy.  Nevertheless:

Section 1:

The last paragraph makes the claim that domain reputation is likely to be
more accurate than IP reputation.  Is it worthwhile to add a sentence or
two explaining why this is true?

Section 1.1.2:

Suggest replacing the first sentence with "ABNF is defined in [RFC5234], as
are the tokens ALPHA, ..."  As it is now, "ABNF" is not expanded on first
use.

Section 1.1.3:

Replace the last sentence with: "Note that other terms that might
superficially look like the common terms, such as 'reverse-path', are used
only as they are specified in their defining documents."

Section 2.1:

I think someone else already mentioned this, but how does encouraging a
second check decrease DNS resource use?

Also, suggest replacing the first sentence of the second paragraph with
"Note that requirements for the domain presented in the EHLO or HELO
command are not always clear to the sending party, and SPF verifiers MUST
be prepared for is identity to be an IP address literal, or simply be
malformed."   We might even reference the IP address literal ABNF in
RFC5321 here.

Section 2.2:

Add to the first paragraph "...or no HELO check was done." or something of
that ilk.

Section 2.3:

The second paragraph is loaded with negatives "no... neither... nor."
Suggest: "ADMDs can publish SPF records that authorize no hosts to use
their DNS domain names in HELO or MAIL FROM commands during SMTP sessions."

Section 2.4:

Isn't the fourth paragraph implicit in any standards specification?  That
is, do we really need it?

Section 2.5:

I can't remember if I suggested it previously, but an appendix of RFC5451
gives a pretty thorough treatment of the notion of doing mail
authentication checks during the SMTP session versus later.  It might be
helpful as an informative reference here.

Section 2.6.7:

Does "permerror" also result when permanent DNS errors occur?

Section 3.1:

s/alternate/alternative/

Section 4.1:

The list of check_host() inputs have been repeated here as in Section 2.4.
Do we need both lists?

Section 4.4:

s/suggests on an algorithm/suggests an algorithm/

Section 4.6.4:

I imagine you're going to say that 10 is the limit imposed by most
implementations, but shouldn't we say that there should be a finite,
perhaps configurable limit, and operational experience has shown that 10 is
a reasonable default?

Why 20 seconds for the overall run time?

Section 4.8:

In the third paragraph, a couple of sentences start with "Domain" when you
actually mean it as a literal parameter name.  I suggest using "domain"
(including the quotes) instead.

The "Some implementations ..." sentence seems to be malformed.  I can't
parse it.

Section 5.2:

s/Check_host/check_host/ (it's not a word that starts sentences and thus
needs capitalization)

Missing end-quote at the end of bullet 3.

The second-last paragraph is weirdly wrapped.  Is the XML ok there?

Section 5.4:

Should the limits stuff in here be removed, and simply reference Section
4.6.4 instead?

Section 5.5:

The SHOULD NOT in here is puzzling.  Does it interfere with
interoperability to use it?  It was my impression that it's possible to get
the same functionality some other way, but not that using "ptr" actually
was a bad idea for interoperability reasons.

Again with the limits stuff, redundant to Section 4.6.4.

Section 5.6:

For IPv4, shouldn't the CIDR be 1*2DIGIT?  For IPv6, shouldn't the CIDR be
1*3DIGIT?

Section 6.2:

It just occurred to me that in the earlier sections (2 or 4, in
particular), it's clear that check_host() returns one of the enumerated
result, but it's never made explicit that it also outputs an explanation
string.  We might want to mention this earlier than we do now so it's not a
surprise later.

The SHOULD in the fifth paragraph is questionable: How does it describe an
aspect of interoperability?

Last paragraph, s/exp=/exp/ 2x.

Section 7.1:

ABNF rules say literal strings in productions are case-insensitive.  That
means the macro-letter set actually implicitly includes all of the capital
letter equivalents.  If we want to constrain it to lowercase only, we need
to use hex notation.

Section 7.3:

"This macro SHOULD NOT be used...." should be in its own paragraph.  Also
the second sentence should be "See Section xxx for discussion."

At the end of this section, there are three paragraphs that all start
"Note:".  I don't think those tags add anything and suggest they be removed.

Section 8:

Second paragraph, s/, and where/ and, where/

Section 8.7:

Don't the last two sentences say the same thing?

Section 9.1:

Same point about the case-insensitivity of ABNF here.

The "SPF verifiers MUST make sure..." doesn't seem actionable to me.  Do we
really expect Received-SPF generators to be able to identify and exclude
malicious data?

Section 10:

s/document/protocol/ (or specification) x3

Section 10.1.1:

s/required/necessary/

Section 10.1.2:

Add "at the cost of a DNS query per receiver" to the end of the first
sentence.

Section 10.1.3:

s/to hostname/to the hostname/, s/of domain/of the domain/

Section 10.2:

Missing close parenthesis in the first paragraph.

Section 10.3:

Errant period in the first sentence.

s/Address/address/

Section 11.1:

Aren't the first and third bullets describing the same attack?

Missing parenthesis at the end of the fourth bullet.

Section 11.3:

Clobbering the DNS at a receiver could also result in delivery of malicious
mail if the receiver is configured to pass on "tempfail" and just add a
header field.

Is that second bullet true?  It appears to claim that IP address spoofing
is effectively impossible.

Section 11.5:

This appears to be an incomplete thought.  At a minimum, it doesn't flow
nicely into the next subsection.  Maybe add a sentence to indicate that
SMTP itself doesn't do anything to validate those parameters?

Section 11.5.2:

Remove commas around the section reference.

Appendix A:

Any changes made to ABNF above need to be reflected down here.

Appendix B.3:

Suggest a reference to RFC5782.

Appendix C:

s/implmentation/implementation/

Appendix G:

Fourth paragraph: As I mentioned above, RFC5451 has an appendix that talks
at length about why you want to do things like SPF checks at the border
rather than inside.

Appendix I:

The second paragraph claims we're documenting extensions since 4408.  Were
there any?

-MSK