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

Seth Blank <> Thu, 09 May 2019 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0577E1200DF for <>; Thu, 9 May 2019 16:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jvIeKiWGNThi for <>; Thu, 9 May 2019 16:17:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 580A91200DE for <>; Thu, 9 May 2019 16:17:16 -0700 (PDT)
Received: by with SMTP id y10so3205780oia.8 for <>; Thu, 09 May 2019 16:17:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=93OSlys9kEv2/YuEQYlvYsBmDrfb9If1u6PmOBpWiyQ=; b=Lcesu8k9BD/KMlglSYihFGNH62S4hK7i3Keo+Z6OS6rRrtc/5NCbLHRLDMYXxwn7sM jtxVwRkUfuT10m5+EuXuRyIhwYGS7wglAlk/vJ5U7DjY9eB9/3k9r3cXIOtTFZjeeNgi sYJO0RFZkWY0ju28d7pul6tgkEhw1OsKAhLr61RiETS9OODY7cTOtxHrIxzfPoDbLagA T6VPZ0qQhyq9t253ys+6V1pwqaR1BkbYn1kO3UvDBEJDj+bf3x23UN5q0KBWJbk6AC1v CnDGye7AsuKcy/v5yQNpu9R2vh14inu54k2f4scKrFoPItuS96dP/PJhOeNhVd4pBEvd t5/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=93OSlys9kEv2/YuEQYlvYsBmDrfb9If1u6PmOBpWiyQ=; b=DHHcJC9C5XiJ56156F4kJba1PDR7/iN7izocOaDKfn46DyAfof9mBJZ/hAzQjD+KsZ spi9Z0DXSY19RayACHsPdprfYZktYJ+X8hjQJtumYUK33yCvDgXlsa4yYL1qr/9089Af gFraP7ezImNnebjXYqXpLDY3cxWDb+8ZQQaP1jJPkddg14dkVgW4QA+s7O7tAAP+P9NB uPhtTGbfw/jf9zKQZz+fpf/4NbESXicgOCgF/egHtNMuhofMs2BnTEkE+rmWymzPAJ/9 dN2Jf1jLctg1je4MiL+q5JVi4Sk/WDVqMdjU5vhmp5psgaZx4rlGtP3kSrYkKro79pIj k17w==
X-Gm-Message-State: APjAAAV9bzSur5HejbWcq4GqigWuWfWjOM3xeBvobAPsfFrkQbS1jHRO 59kd9S5j2qGgTrQKDj2IxAsTjblVD7S8FefCA1h9UCVmLT4=
X-Google-Smtp-Source: APXvYqzbuD9YaHKU30hKbsEc1bzswCuoCmxxqQfwU05JT9xdJhbdR1ZXiwvndOz1xiWCdjzTutDhNVSh4AIPSzYkFWE=
X-Received: by 2002:aca:e8c5:: with SMTP id f188mr3087479oih.132.1557443835346; Thu, 09 May 2019 16:17:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <12992594.LUNhQVcRDa@l5580> <> <1694180.CbOjR3XESQ@l5580>
In-Reply-To: <1694180.CbOjR3XESQ@l5580>
From: Seth Blank <>
Date: Thu, 9 May 2019 16:16:58 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000905fbd05887ca61c"
Archived-At: <>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 May 2019 23:17:19 -0000

On Thu, May 9, 2019 at 3:03 PM Scott Kitterman <> wrote:

> If there's no MUST NOT, then any entity that does failure reporting needs
> to
> consider if they should do it for PSDs and if so, which ones.  That's a
> question that, at best, has a squishy answer.

I don't agree. It's up to the PSO, not the system generating reports, to
determine which type of reports are wanted. The proposed registry is the
control of who can even make a decision like this. If there were no
registry and PSD functionality were open to all, then this would be a more
concerning case.

But the entire point of DMARC is that a receiving system doesn't need to
guess - it's up to the domain owner to publish their policy. This flips
that distinction on its head and says it's no longer up to the domain owner.

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
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.