Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Brandon Long <> Thu, 12 December 2019 23:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EF3312012A for <>; Thu, 12 Dec 2019 15:38:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 mP9GBKGVs7jg for <>; Thu, 12 Dec 2019 15:38:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 372B8120019 for <>; Thu, 12 Dec 2019 15:38:06 -0800 (PST)
Received: by with SMTP id w20so159109uap.1 for <>; Thu, 12 Dec 2019 15:38:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ff2ILbj+MO1KLdZKBFvMvsAGdZ1YCfk/o1qnhv0Htdg=; b=ee0PJqmoTGLLOYYndjbeWMybn1YwaRl1qZDv/vzK5qKeJIQt4IBG8N/1M6deJP3lMw OlHOjqoLLe32SeZw0yWjK2lbK3wb/aZo22GEQJ/lJxIZiLteTf4j2FMpsoSKP1He5w31 bhyORVyY7H4F8I+oMAsIN0zdOFPsnThYAG/njOMYvFpG2SKiJ+TKhsRX0XFXNPXADeGB LIF861/6nXokSLAbWZbjd5OwXo9JeChQ/8teFcK+fNXZkENYxAgT/VH0wtFcBHgexLrT mx3/FAs3zFMHEs4vKNWQqxmGCfifpEQbn+vFniNyS5+4Vl+Myz5lz5XQ6rK91GWIua5Q u6cA==
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:cc; bh=Ff2ILbj+MO1KLdZKBFvMvsAGdZ1YCfk/o1qnhv0Htdg=; b=PKOCkaP1esAfFDSiiHXxga/s4o1GGCdU/SKPI/bBTAK9RfkTpuIT5TKtlx1aRyW4df 4znKAwkxfBYeHKZpcv18nBAwfpFgC4IFM1dfE8Rmh1rhrCeundTXgr84FjaxjefBTFh9 IN/+sgutdaJzeHchc8UbAPsH4p2eDKXmSL5EWwFjBdqaJFqgeUVGkL6k7veGk1UslEs0 A2uVH6uOwW231FEEr9oR8/hPXVJ0veU5ejN2vzTAuhjsMSwGb5cphutNRElHuA5D1HPU XHyxiiPQYDcUbnGZQRS2EKdk89GbigTLcScAHbEeCgP40wAVTLdEZ6M23K236GWLkWRX ZcCA==
X-Gm-Message-State: APjAAAWzYd8W0WgVweHv998J82uIGLQjmnNfb2yDCK3Wpi7SGLDK/TEJ tSmHlYNZxPSlAHbKIvXM8zL/I/XRVU6GrGN0zTvI
X-Google-Smtp-Source: APXvYqzKOV8PspL8kadW+e95asX/q7l2q0P4KOMbVBjxf/3qPpouqHLI9Qwq/e8xLumd64nHjEOzgBpOIXrTsPya17U=
X-Received: by 2002:ab0:26cd:: with SMTP id b13mr10150127uap.44.1576193884477; Thu, 12 Dec 2019 15:38:04 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <92703458.QmNNAb80T6@l5580> <> <> <>
In-Reply-To: <>
From: Brandon Long <>
Date: Thu, 12 Dec 2019 15:37:52 -0800
Message-ID: <>
To: "Kurt Andersen (b)" <>
Cc: Scott Kitterman <>, IETF DMARC WG <>
Content-Type: multipart/alternative; boundary="000000000000954e3705998a3ca9"
Archived-At: <>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
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, 12 Dec 2019 23:38:08 -0000

On Wed, Dec 11, 2019 at 7:45 AM Kurt Andersen (b) <> wrote:

> On Tue, Dec 10, 2019 at 2:13 PM Brandon Long <> wrote:
>> On Mon, Dec 9, 2019 at 6:27 PM Kurt Andersen (b) <>
>> wrote:
>>> On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman <>
>>> wrote:
>>>> On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:
>>>> > I'm sure I probably missed this, but couldn't we avoid this question
>>>> by just mandating no reporting for non-existing organizational domains?  Is
>>>> that a non-starter?
>>>> It's one of the use cases we are trying to cover.  I don't know if that
>>>> makes it a non-starter.
>>> Unless I'm misunderstanding Brandon's suggestion, it seems like you
>>> (Brandon) are asking if doing no reporting on missing org domains solves
>>> the scalability problem. *Getting* reports for missing org domains is the
>>> main purpose of the PSD proposal so it would render the purpose moot.
>> Hmm, I guess I don't see it that way.
>> Preventing phishing attacks from, insomuch as DMARC
>> can be used for such, seems way more important than the reporting.
>> Obviously, getting to p=reject without reporting is more challenging.  You
>> can certainly have policy without reporting.
> While it is very true that receivers may implement validation and possibly
> enforcement without reporting, we could solve the use case of phishing from
> missing org-level domains by the same approach that we can solve it from
> any missing domain - just don't accept mail from such bogus sources. That
> does not help the overseers of a domain realm (org-1, aka LPSD) to tackle
> takedowns or public awareness campaigns against such abuse though.

I mean, that was also true for all DMARC, the point was the owner was
asking everyone to do that.  If you're saying we should have a different
system for trying to get everyone to not accept messages from non-existent
domains... ok, but I'm not sure where that would come from.

Maybe no one would be willing to go with np=reject without being able to
confirm there's no good mail doing that.  That seems more likely to be true
for existing large scale branded domains (which I guess falls into),
whereas setting that policy for the newer branded domains (.google) and
multi-organizational (.bank) seems fine without reporting.