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

Phillip Hallam-Baker <> Thu, 30 May 2013 20:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 285F721F9273; Thu, 30 May 2013 13:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8fOgwDXBvjwQ; Thu, 30 May 2013 13:00:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) by (Postfix) with ESMTP id 9026221F9354; Thu, 30 May 2013 13:00:41 -0700 (PDT)
Received: by with SMTP id hn14so56458wib.14 for <multiple recipients>; Thu, 30 May 2013 13:00:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aSF2ZcxNSEk8B6AEsM9NOfE/qPv9AH94fljFEeidwSM=; b=eFyS0wE3TXYdzhybVIdyJTK3obyfpIlfzY1H/xW0VDFlMinWb/rXl+GqXoMgj2TSou wurHhlMuOdz1S9JR9wG3S1GzS8upOieJymwNLBfsDfNegG/7CFU/9EUOiSQ1Umw2U8VW dNCPCwqnxaeFzIn+MbmMONj24rrZ0iUQakWkxERUci8ZWdmKy+k81e4k/9ThCW48wcJ1 JH9QkhRfHVWqKy0EbhsSlBpouDOfUrzNbtRkqblvqi2gPQoInMot26BfeiBv6fKDgCpy zIBCHM5e85zG//nzH+im/syuwyyplAC5UXO4vTqE8zCWGRv5Gtyl1VkgC3VBSZ4INNhv C76w==
MIME-Version: 1.0
X-Received: by with SMTP id ba2mr6394781wjc.22.1369944040627; Thu, 30 May 2013 13:00:40 -0700 (PDT)
Received: by with HTTP; Thu, 30 May 2013 13:00:40 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 30 May 2013 16:00:40 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: S Moonesamy <>
Content-Type: multipart/alternative; boundary=089e01184dd4e766c804ddf4f3c1
Cc:,, "" <>, Douglas Otis <>, "" <>
Subject: Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 May 2013 20:00:44 -0000

My point was a quibble, no more. The intent was clear enough to me and it
is hard to imagine an implementer of code making a blunder if their code is
timing out too often on real records they will raise their limits. A person
writing records might however.

I can see that attempting to clarify this point might add more confusion as
John Levine pointed out. In fact that was the main concern I had with the
document as a whole. I think it is done as well as it is going to be at
this point.

On Thu, May 23, 2013 at 3:14 PM, S Moonesamy <> wrote:

> Hi Doug,
> At 11:58 23-05-2013, Douglas Otis wrote:
>> Greater clarity would have been achieved by separating transactions
>> involving the SPF checkhost process (spfch-transactions) which may then
>> generate some number of recursive dns server transactions
>> (rdns-transactions).
>> A transaction made at the spfch level will result in some number of
>> transactions at the rdns level, which could then be described as
>> representing some number of separate DNS queries.
>> Confusion has been caused by conflating checkhost and recursive DNS
>> transactions with that of non-recursive DNS which may involve dozens of
>> unique queries to resolve any particular resource.  This is bad and is a
>> continuing source of confusion.
> What I noted among other things in the review was "the only quibble" and
> "it is reasonably clear".
>  A practical means to simplify SPF's impact on a receiver's DNS is to
>> first ignore SPF records containing macro expressions.  This happens and
>> this may explain the nearly 100% lack of macro use.  They then limit the
>> number of SPF resource records and MX mechanisms and ignore the PTR
>> mechanism.  Appreciate what receivers consider a reasonable demand on their
>> resources that offers cache-able results.
> I don't see any relation between the security directorate review (
>**archive/web/spfbis/current/**msg03679.html<>) to the above (quoted paragraph).  If the security directorate reviewer is
> of the opinion that it is related to his review I will ask the SPFBIS to
> comment about the matter.
> Regards,
> S. Moonesamy (as document shepherd)