Re: [spfbis] Question about SPF checks based on RFC 7208

Scott Kitterman <spf2@kitterman.com> Mon, 02 May 2016 02:55 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 A3C0812D0B0 for <spfbis@ietfa.amsl.com>; Sun, 1 May 2016 19:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSbWQFRgDTT0 for <spfbis@ietfa.amsl.com>; Sun, 1 May 2016 19:55:37 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4274712D0A6 for <spfbis@ietf.org>; Sun, 1 May 2016 19:55:37 -0700 (PDT)
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5A1EEC40152 for <spfbis@ietf.org>; Sun, 1 May 2016 21:55:36 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1462157736; bh=/1W5kKV42sjkUgpHeiSpIGfgEQ7IYXqXaMCS/BJziYs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ax+5UxQdLL0/AQ75PZOfiCGq8VL4EBuJIkPxD1H+RstO5imrlLNZLsr59G3j41JDh 5S/PHIoXDgMBpP1IbuAhiGGlJxNja/TzIg/U1F5yTSjfqCOZPcsW4FRcBmG4fKwLS/ iDvc8jdRBu03fBWoMcrGC6SylznjK6i1mlzRuMJs=
From: Scott Kitterman <spf2@kitterman.com>
To: spfbis@ietf.org
Date: Sun, 01 May 2016 22:55:35 -0400
Message-ID: <6348765.abvlTfSS9j@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <alpine.LRH.2.20.1605012241001.11694@fairfax.gathman.org>
References: <002101d1a342$c93e3000$5bba9000$@iname.com> <5060996.Nvmh582kyi@kitterma-e6430> <alpine.LRH.2.20.1605012241001.11694@fairfax.gathman.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/4S2bG9kt5Ta4EWVDiaoaqxUzhVY>
Subject: Re: [spfbis] Question about SPF checks based on RFC 7208
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 02 May 2016 02:55:38 -0000

While I believe your assessment of the type of records that do this is correct 
(mx would have been next on my list to deprecate after ptr if I thought we 
could have pulled it off), I think it's only technically correct to count an mx 
as void if you've checked both (and that's what RFC 7208 already says).

We may want to make that clearer, but changing it so that only A or AAAA 
missing counts as void would be a technical change that has interoperability 
risks.  I don't think we should do it.

Scott K


On Sunday, May 01, 2016 10:43:33 PM Stuart D. Gathman wrote:
> Implementations will *always* lookup only one of A/AAAA - the type
> matching the connect IP.  So taking your second option would mean that
> A,MX mechanisms would never be void!
> 
> On Sun, 1 May 2016, Scott Kitterman wrote:
> > I think it might make sense that to clarify that an mx mechanism is only
> > void if neither A nor AAAA exist.  Implementations could either do the
> > extra lookup or just not count it as void if only looking up one.  From
> > an interoperability perspective, I think either would be fine.