Re: [Uta] Comments on draft-ietf-uta-mta-sts-03

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 28 March 2017 16:48 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 F1853129461 for <uta@ietfa.amsl.com>; Tue, 28 Mar 2017 09:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 7yWz6xZGPehe for <uta@ietfa.amsl.com>; Tue, 28 Mar 2017 09:48:31 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E34A129449 for <uta@ietf.org>; Tue, 28 Mar 2017 09:48:30 -0700 (PDT)
Received: from [172.31.30.48] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 13DD37A32F1 for <uta@ietf.org>; Tue, 28 Mar 2017 16:48:30 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <8a9cd559-d27f-c245-bfb4-2bc2ecea6ea1@diennea.com>
Date: Tue, 28 Mar 2017 12:48:11 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: uta@ietf.org
Message-Id: <C542D1B7-635B-484F-9565-FB8DF3FCEFA5@dukhovni.org>
References: <d42e535b43f14fc68b9b3e22cdff2e51@EXC01-Arezzo.diennea.lan> <BF2CE255-261C-4006-B8C9-9D9518EF258F@dukhovni.org> <CANtKdUffuLwo--4KY7XL3NsZanUcjat1MUmZF7-H_UYBergdSA@mail.gmail.com> <8a9cd559-d27f-c245-bfb4-2bc2ecea6ea1@diennea.com>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/OJ1hORbKzd9misNUDFzhmsDol3U>
Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03
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: Tue, 28 Mar 2017 16:48:33 -0000

> On Mar 28, 2017, at 6:38 AM, Federico Santandrea <federico.santandrea@diennea.com> wrote:
> 
> If we replace that with something along the lines of:
> 
>  o  "date-time": The date-time indicates the start- and end-times for
>     the report range.  It is provided as a string formatted according
>     to Section 5.6, "Internet Date/Time Format", of [RFC3339].
>     "start-datetime" should be 0000 UTC of the relevant day or the
>     first time a policy was discovered, whichever comes last.
>     "end-datetime" should be 2400 UTC of the relevant day or the
>     time the last cached policy did expire, whichever comes first.
> 
> Then one would normally see reports for one whole day, except when one
> first publishes a policy and in abnormal situations where a policy
> has been allowed to expire with no new one available.

Not just when first publishing, but also when each new sending
system first discovers a policy, which will make for too much
noise in the reports.

Also, policy expiration will not be "abnormal".  If I implement
STS, pre-expiration background policy refresh will not happen
in the absence of email to the destination domain.  This avoids
unbounded fiiling of the cache with junk domains to which email
delivery has long ceased.

The simplest solution is to accept that STS covers ongoing
validation of email to frequently used domains, and is otherwise
subject to downgrade.

-- 
	Viktor.