IETF Logo Mail Archive

Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.

Jim Fenton <fenton@bluepopcorn.net> Thu, 10 August 2017 23:36 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172E81326D8 for <uta@ietfa.amsl.com>; Thu, 10 Aug 2017 16:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 m-Oo7Ra5SZjn for <uta@ietfa.amsl.com>; Thu, 10 Aug 2017 16:36:23 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AFB1326DA for <uta@ietf.org>; Thu, 10 Aug 2017 16:36:23 -0700 (PDT)
Received: from splunge.local (c-24-4-226-141.hsd1.ca.comcast.net [24.4.226.141]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v7ANaLOR023321 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <uta@ietf.org>; Thu, 10 Aug 2017 16:36:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1502408183; bh=Ycw3YCUqF/orLItfzrJtKDKStn73FNccVBDe+XDeLJM=; h=Subject:To:References:From:Date:In-Reply-To; b=OtVTCXFWhlJGK/tqO/8tcTCa2/jIsB/iL2ZUX1G4aHSqzvOYe09Mld39xGGSqU4hg 7ScrvI+jgzw7LYplBjo2iPEwfhf4AxoTA1fV33QPpSFePMY3vvh1yfr3EAkHqcLd5S VBlc3mVn/2+bkTqk5a5dEHODZkzopCXhqcx2fmnU=
To: uta@ietf.org
References: <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <CANtKdUc6PaDyBOcG_LhvezbnZ8JEv=xFf=MosQWSY8dg4MxjLg@mail.gmail.com> <20170809174827.GQ8146@mournblade.imrryr.org> <CANtKdUdqHM-bu_Z_GVcCN_Jca9SNNNdBkQKPOOtX_a=zW_EJZA@mail.gmail.com> <20170809183310.GU8146@mournblade.imrryr.org> <CANtKdUcqcoKjRctyGJ6Qc41vOxEvt8Knzjc6CZGn-0jqN9g5BA@mail.gmail.com> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> <CANtKdUcc5mBNeUd9kPg_VemcbX4vdDwfvVgoXrr=nQtYLDeStQ@mail.gmail.com> <20170810174656.GX8146@mournblade.imrryr.org> <62416269-a781-0642-f339-5f5ebbbb4146@bluepopcorn.net> <20170810230738.GE8146@mournblade.imrryr.org>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <80d8938a-2b27-9ba9-985c-54c688b215fe@bluepopcorn.net>
Date: Thu, 10 Aug 2017 16:36:16 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170810230738.GE8146@mournblade.imrryr.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/vaaEWrixonB5DaQFHI8wADnAFJY>
Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2017 23:36:25 -0000

On 8/10/17 4:07 PM, Viktor Dukhovni wrote:
>
> Under that condition, there's no need to wait to remove the TXT
> record, removal of the record (being a change in the record) will
> in this variant of the design trigger a refresh, and the sending
> MTA will see a "none" policy and proceed to promptly flush it.
>
That's the part I didn't get: that an NXDOMAIN or NODATA response was
also considered to be a record change that triggers a refresh. Thanks.
That isn't immediately obvious because the lack of a TXT record when you
don't already have a policy cached inhibits fetch of the policy.

-Jim

v2.23.0 | Report a Bug | By Email