Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.txt

Alessandro Vesely <vesely@tana.it> Wed, 15 May 2019 10:17 UTC

Return-Path: <vesely@tana.it>
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 6318C1202A4 for <dmarc@ietfa.amsl.com>; Wed, 15 May 2019 03:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 qIkzltFuPy7F for <dmarc@ietfa.amsl.com>; Wed, 15 May 2019 03:17:27 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505721202BB for <dmarc@ietf.org>; Wed, 15 May 2019 03:17:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1557915444; bh=5bRtmSu985eKts4NGpskyGZrjanScWwhQGCiwoJYSvY=; l=2081; h=To:References:From:Date:In-Reply-To; b=CBLwf5qGmu54ahN41jN8i0wzPLpK+UmQz7Iuj1wh6+5H0HkG+v79PMkK/5yFavP5T fo/COBjSQter6NRTgpt8vQNj2DazRO/HMpopi4zgAdFc/HUrGAatXd7VjRcV3hhXgB qfRNC62H0RxfqHKBZzxLl1U/ysL4+Mw8nb3YWlCsPyZ+h9h6KZPA1X2kBZVuD
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 15 May 2019 12:17:24 +0200 id 00000000005DC077.000000005CDBE734.00007B0F
To: dmarc@ietf.org
References: <155728145158.24534.10112720017814447505@ietfa.amsl.com> <12992594.LUNhQVcRDa@l5580> <CAD2i3WMeEFQ0njNmX8EeVUr2ydypTpYQYfKVKaoc6OXfq0OcLw@mail.gmail.com> <1694180.CbOjR3XESQ@l5580> <CAD2i3WMKUm51tjXc+cQVqri-wQqJJENd=33Ah45knm0BtODXew@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <e94283b9-5706-89be-dc4e-78bdf372510f@tana.it>
Date: Wed, 15 May 2019 12:17:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAD2i3WMKUm51tjXc+cQVqri-wQqJJENd=33Ah45knm0BtODXew@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/A8m-koeKERWDv5bp_9QdnpyAUL0>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.txt
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: Wed, 15 May 2019 10:17:30 -0000

On Fri 10/May/2019 01:16:58 +0200 Seth Blank wrote:
> 
> To reiterate:
> 
> This normative MUST NOT is a mistake from many different angles, as it:
> 1) codifies a policy decision that doesn't affect interoperability
> 2) adds complexity because reporting against the third lookup is now different
> than reporting for the other lookups
> 3) doesn't apply for all use cases (specifically, it would prevent .com from
> gathering RUF data, but also prevents .google from operating in the same manner
> as google.com <http://google.com>)
> 4) reverses a key value of DMARC: giving control of policy to domain owners
> 
> I strongly agree that RUF is potentially problematic here, and it would be
> better off if no one got it, but I really believe that's a policy decision for
> a domain owner / PSO (and a policy decision for who is allowed in a registry of
> PSOs), not something that should be normative in the spec.


In part I agree.  However, RUF is potentially problematic in general.  Whether
and how to honor RUF requests deserves a better discussion in the DMARC
specification.  I certainly wouldn't send a non-redacted failure report to an
unknown domain.

That said, I agree that control of PSDs should be given to PSOs, by the same
logic of bullet (4) above.


On Thu 09/May/2019 18:39:13 +0200 Scott Kitterman wrote:
> 
> I disagree.  That puts the (potential) fox in charge of the hen house.
>


It is true that we cannot trust the generic domain owner.  However, PSOs are
somewhat more constrained by policies and contracts.  In addition, their public
DNS records are quite easy to check.  Perhaps we could concede a little bit of
trust to those foxes?

In addition to Seth's "if you're a PSD, don't ask for RUF", I'd propose that
multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage SHOULD
publish a blank DMARC record, that is policy=none, no ruf, no rua.  PSOs that
violate those recommendations would not do so in a concealed or unanticipated
way, but as an integral part of their legalities.



Best
Ale
--