IETF Logo Mail Archive

Re: [spfbis] Result of record evaluation with non-implemented mechanism

Tim Draegen <tim@eudaemon.net> Thu, 14 January 2016 16:15 UTC

Return-Path: <tim@eudaemon.net>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9981A1A14 for <spfbis@ietfa.amsl.com>; Thu, 14 Jan 2016 08:15:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level:
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 XNExPeoeh6aN for <spfbis@ietfa.amsl.com>; Thu, 14 Jan 2016 08:15:55 -0800 (PST)
Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 164F71A1A12 for <spfbis@ietf.org>; Thu, 14 Jan 2016 08:15:54 -0800 (PST)
Received: from [192.168.1.20] (unknown [67.58.115.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id D0321CB46; Thu, 14 Jan 2016 11:14:49 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Tim Draegen <tim@eudaemon.net>
In-Reply-To: <5695253F.6060702@tana.it>
Date: Thu, 14 Jan 2016 11:15:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2F738C7-5753-4DF0-B0AA-B1B422DB14C8@eudaemon.net>
References: <5695253F.6060702@tana.it>
To: Alessandro Vesely <vesely@tana.it>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/Og7B3szf8q8vbJV_17LeC_FMKp8>
Cc: spfbis <spfbis@ietf.org>
Subject: Re: [spfbis] Result of record evaluation with non-implemented mechanism
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 14 Jan 2016 16:15:56 -0000

> On Jan 12, 2016, at 11:09 AM, Alessandro Vesely <vesely@tana.it> wrote:
> 
> OTOH, dmarcian reports that "exists" mechanisms are not fully supported by all
> high-volume receivers.

Speaking for dmarcian.com's SPF tool, Hotmail used to skip exists mechanisms due to the impact of expanding macro resolutions and trying to cache it all.  Search RFC 7208 for "cache" for some related text.

Two things:

1. It's not the exists: mechanism itself, its the use of macros that can be painful to DNS caching.  Apparently Hotmail saw macro-based DNS explosions in the context of the exists: mechanism, and act accordingly.  However, other mechanisms can use macros, too.

2. Hotmail's infrastructure has been moved (or is just about finished moving) to all-Outlook.  Part of this transition means no more skipping of exists.

I'm OK with removing the exists: mechanism warning shown to users of dmarcian's SPF tool.  One thing I'm not sure about is if warning about the use of macros should replace it.

Is concern about DNS caching infrastructure still relevant, or are these concerns rooted in an older time?  I'll be asking more "DNS people" about this, as I'd like to give correct guidance.

-= Tim

v2.23.0 | Report a Bug | By Email