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

"John Levine" <johnl@taugh.com> Sat, 20 April 2013 23:32 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 2A7CF21F91BF for <spfbis@ietfa.amsl.com>; Sat, 20 Apr 2013 16:32:53 -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 18TnfIcDCXC6 for <spfbis@ietfa.amsl.com>; Sat, 20 Apr 2013 16:32:52 -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 40A4F21F9156 for <spfbis@ietf.org>; Sat, 20 Apr 2013 16:32:52 -0700 (PDT)
Received: (qmail 10453 invoked from network); 20 Apr 2013 23:34:25 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2013 23:34:25 -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=517325a3.xn--yuvv84g.k1304; i=johnl@user.iecc.com; bh=WUEZvALwGPi2DyBGBzXDsEAAXzfwS9a+XQlk6drL3P8=; b=Rrq/Uex8bK/uhqdXNZr56WGf/nY3sjZeqbp/xHkSHVyz04s/S45ZKzooVhE0heuGDW2J9tq/Ui7EqZa+7OGKIJQ4SsasClqZvzfnlLbyhdvyKgLTPiUOvmbmiiWXD0psduHB+hq/OQ4jdpL7vECnh2d3sKsSw2pTczinwWnTnhY=
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=517325a3.xn--yuvv84g.k1304; olt=johnl@user.iecc.com; bh=WUEZvALwGPi2DyBGBzXDsEAAXzfwS9a+XQlk6drL3P8=; b=3JJF9Mx/XgbicFso48JioXv9F7rcAlNf1k1B8yJrPolRNlAqCGpbk4HQ/pwgtsXI1WCdX31aahNshcUv+JkNrXwMeZIJvwuU2I6sM7lKikM+pymjHOiin8jpgOi+xtwVRidhKGlF/sLW8C6KkF0uV/uZ7bJHhb8LmWCX86WRmSk=
Date: Sat, 20 Apr 2013 23:32:29 -0000
Message-ID: <20130420233229.47086.qmail@joyce.lan>
From: John Levine <johnl@taugh.com>
To: spfbis@ietf.org
In-Reply-To: <1903338.omVMzuiKyh@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 23:32:53 -0000

>>    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.
>
>Generally, the SPF record for HELO requires at most one additional DNS lookup, 
>so even if you have a relatively low rejection rate base on these records, you 
>can come out ahead on resource expenditure because it's generally an 
>inexpensive check compared to Mail From records.

Well, maybe.  If someone says "HELO hotmail.com" as some spamware has
been known to do, you're going to do a lot of extra work before you
look at the Mail From.

>We have been through what goes in the main body and what goes into an appendix 
>several times and finally got to something people are roughly happy with.  I 
>would propose not having the 4408bis organization discussion again.  If people 
>are really unhappy with the organization, I have several comments against it 
>as well that I'll submit, but I think that we're better off to leave well 
>enough alone.

If moving this stuff requires a lot of argument, I agree it's not worth it.

>I found one oddity in the XML.  The output now looks like: ...

>Is that more like what you were expecting?

Yup.

R's,
John