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

"John Levine" <johnl@taugh.com> Sat, 20 April 2013 19:46 UTC

Return-Path: <johnl@iecc.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 D148921F925B for <spfbis@ietfa.amsl.com>; Sat, 20 Apr 2013 12:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.199
X-Spam-Level:
X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
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 EkCriYfi2o3m for <spfbis@ietfa.amsl.com>; Sat, 20 Apr 2013 12:46:36 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C537121F926E for <spfbis@ietf.org>; Sat, 20 Apr 2013 12:46:35 -0700 (PDT)
Received: (qmail 54480 invoked from network); 20 Apr 2013 19:48:06 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2013 19:48:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5172f099.xn--3zv.k1304; i=johnl@user.iecc.com; bh=FspSb5Bbmt6WtImLa4N3tnlSs5cQ+cJ6cB0WXERgImM=; b=ihPo7ufo6kiMN4wnvQ9/9peZ4Tc10zDPw3WGKqO01JzE59P6JuHh8beQQnu3wRP/mo5EUIBcONATNY++4G8sEvdTAKs5YvaeUTgXJs1dlGhAsuW2wMupYk0Gjak0Tsd6l52mnq0zRcSDx/mtZZEr7W/XiEdBW21iv5yZD6rS234=
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5172f099.xn--3zv.k1304; olt=johnl@user.iecc.com; bh=FspSb5Bbmt6WtImLa4N3tnlSs5cQ+cJ6cB0WXERgImM=; b=UXRfvB55bQkvGkEzTk9xSUp9Dj48yNC+5Zu0vW39JeENeB3h01MLf2WHD5EB0fh/MIEqv5izcRg1bwd6mZ7bDocEHM/tx5Jm6TjqQZtApQCqIeg3iej5KbaZ97jW0aRWYqSS5HCQBVK9OLNG8k1f4IyEWOCS1aGLrO5JiPQTFuc=
Date: Sat, 20 Apr 2013 19:46:10 -0000
Message-ID: <20130420194610.46217.qmail@joyce.lan>
From: John Levine <johnl@taugh.com>
To: spfbis@ietf.org
In-Reply-To: <3819226.HNrkiDGy6d@scott-latitude-e6320>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 7bit
Cc: spf2@kitterman.com
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 19:46:36 -0000

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.

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.

  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.

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. 

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.

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.

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.

R's,
John