Re: [dmarc-ietf] Comment on DMARCbis, was draft-ietf-dmarc-psd

Jane Moneypenny <jane.moneypenny@protonmail.com> Thu, 13 February 2020 10:26 UTC

Return-Path: <jane.moneypenny@protonmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49A1200DB for <dmarc@ietfa.amsl.com>; Thu, 13 Feb 2020 02:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 eIV5bZ9g4HEl for <dmarc@ietfa.amsl.com>; Thu, 13 Feb 2020 02:26:00 -0800 (PST)
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (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 441551200DF for <dmarc@ietf.org>; Thu, 13 Feb 2020 02:26:00 -0800 (PST)
Date: Thu, 13 Feb 2020 10:25:47 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1581589557; bh=qyIxYG4fwL7wC9e8B8oEOT/T805P9hHWVL0lL7dyI+4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=jMUNjuVcFRNccHtLr/yS2F32nmm7wf4eE0GnMTlFbYXc376ako9QZ3W7iV+YgrZhI g28JRCkHPRTo+zdClwKWT0KUeMJxDEMOd1n7HztUul1mx9R4Oe+nx1GECQMGE8zz8s 9FX2EBJ5irwAGFfEad+gmj6kDCJZPCQ7hzeIePfo=
To: Alessandro Vesely <vesely@tana.it>
From: Jane Moneypenny <jane.moneypenny@protonmail.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Reply-To: Jane Moneypenny <jane.moneypenny@protonmail.com>
Message-ID: <PrnGuaFhe0l3-5rQTDR3imYwIlxCWS7P5ZNgccOlX2yyRwDVcjj9eySBuvX9jqhMl0sVIVRHehaCX9ATLc_hnZ0c2BwMDHtyB2BzKBz16f0=@protonmail.com>
In-Reply-To: <f1bbfc6b-a20f-5cb0-0e65-aee2c1a32536@tana.it>
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <CAJ4XoYdgHD7O8wzv1J-=qC_M7-r32Z_UxHakTZWbMFOAU5OSjA@mail.gmail.com> <9467613.0cjHueyR6G@l5580> <CAL0qLwb-9OMzp=JAfDKsALEFY0T8zEWg9LOnfQSPNaJcpfL8rw@mail.gmail.com> <f1bbfc6b-a20f-5cb0-0e65-aee2c1a32536@tana.it>
Feedback-ID: maG8rBvbVesMvSttssIWvHvk4FVyIn95_Qx9mK3VOL2K8_0Gp4G9wiVKu5rDHO6CjG4Ix8q6os17SKjYvK8tHA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8Ui-lRzMptIYlEMThDmMllmRR1U>
Subject: Re: [dmarc-ietf] Comment on DMARCbis, was draft-ietf-dmarc-psd
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2020 10:26:04 -0000

> For a second issue, consider whether report generators should track policy
> changes during the day and, in case, send multiple reports with different
> PolicyPublished. Otherwise, PolicyPublished would be valid for only a part of
> the reported rows, presumably the last. Is that acceptable?
>

Shall the "policy tracking" mechanism take into consideration:-
- TTL,
- DNS cache issues?




Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 6, 2020 7:44 PM, Alessandro Vesely <vesely@tana.it> wrote:

> On Tue 04/Feb/2020 22:26:30 +0100 Murray S. Kucherawy wrote:
>
> > On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman sklist@kitterman.com wrote:
> >
> > > I agree on DMARCbis. I don't think advancing this draft has a significant
> > > effect on that. Worst case, if DMARCbis is done before we can reach any
> > > conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in
> > > it.
>
> +1, albeit I don't think DMARCbis arrives so quickly
>
> > I think we've always been assuming that PSD DMARC would be input to
> > DMARCbis, so we were planning to start the latter but not close it until
> > the former was completed. This is the first time I've seen a different
> > suggestion.
> > I'd love to hear more opinions about ordering of the work here. This seems
> > like an ideal time to review and update our milestones.
>
> There are quite some issues about DMARC. Let me mention aggregate report
> format first, as this brings out a third thing which can be done in parallel,
> namely to publish http://dmarc.org/dmarc-xml/0.2.
>
> Various tweaks have been proposed, I think they're well summarized in
> http://bit.ly/dmarc-rpt-schema
>
> For a second issue, consider whether report generators should track policy
> changes during the day and, in case, send multiple reports with different
> PolicyPublished. Otherwise, PolicyPublished would be valid for only a part of
> the reported rows, presumably the last. Is that acceptable?
>
> Another case for sending multiple reports at once is on hitting size limits.
> Is better to increase sending frequency instead? How to negotiate sending
> frequency between report consumer's ri= and producer's conditions deserves some
> discussion.
>
> I'm sure there's a bunch of other issues, and we should start to collect them.
>
> > > I don't see anything about PSD DMARC being inherently on the critical
> > > path for DMARCbis. I suspect the current major obstacle to DMARCbis is
> > > that the question of how to take the PSL out of the equation is unsolved,
> > > despite one IETF WG that was supposed to be dedicated to the question.>>
> > > I don't think not publishing PSD DMARC helps move DMARCbis forward, so I
> > > think it's a false choice.>>
> >
> > I think what Dave proposed about PSL separation from DMARC is entirely
> > appropriate and pragmatic, and in fact probably easy enough: DMARC is
> > changed so that it says the organizational domain is determined using some
> > process [currently] external to DMARC, and then a second document explains
> > how that process is accomplished using the PSL (and/or PSD, depending on
> > when the experiment result comes in). That's a fairly simple edit overall,
> > and is actually probably minor and non-controversial compared to some of
> > the other surgery that I believe is in the queue.
>
> +1, let DMARC core defineorganizational domain by characteristics. A second
> document present a process, possibly demonstrating how the required
> characteristics are met.
>
> Scott's I-D already outlines the characteristics of Branded and
> Multi-organization PSDs, that the experimental processes are suited for.
>
> Best
> Ale
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc