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

Tim Wicinski <> Wed, 04 September 2019 20:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6997A120DCF for <>; Wed, 4 Sep 2019 13:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oInRW41u408X for <>; Wed, 4 Sep 2019 13:53:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CF75120A9B for <>; Wed, 4 Sep 2019 13:53:38 -0700 (PDT)
Received: by with SMTP id c7so22142940otp.1 for <>; Wed, 04 Sep 2019 13:53:38 -0700 (PDT)
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=35Ub6cJCaq1eI5WfdsNQ8awxZ3+XoP44Bzi6NPjUeZE=; b=l4yGhHaSmVQRMq1/FTRB2bUpCvA0e8qJF1+Ln43MdefrHwk+pG8lPJ5+NJLZWyg7u5 2pvzAMCKf3atUuY7It5pnVNH0Fe/VQu1/gr/qCWqYwSAb6fY39yxqVorEu5UW4k0Auyy NfExUVBcGQpq10ymCbThCB6bmHCFqQHzVfQJmlLyqDGBE7+VCKLg6+FPKuU9sQdjCysw ZzdiXYpse9r5i8C9qmi399IKm1cBr48YiOhthyLF6f4rhYi44qjmeNTJZXLacRFZ+bxv dUzl0bhsidgb4i/aeaK2kjneL2aVOUIIKtGKplvBDC4PdcMYOUe95rryQjF6mGAB3+JO CERw==
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=35Ub6cJCaq1eI5WfdsNQ8awxZ3+XoP44Bzi6NPjUeZE=; b=ibguDID10SS6U6TyHvbaSZk11/n3RV9MtROv0tkwDmYSnC2vY0lSVOdNZ0iqtsTgJN 6eSHRX+Tp0/Jsp5WucvD+YBUMzEU9QvDcYLZT2DPMUYvbyHTYNOBUmtFIR7TclD8FQFh D4Fvxi6dabXIe2sC7PPQ+i+N7y7jzJSjmequ9ZfsUFUXnCWnXnqkNf5okd1ExWf1r1mF oHQcouOUFgLZAwVaG/lLppzI3340FiCBjmZDn4lOZ+d0Xk7a/HDm5Bmr+a063JwUqHAr tuAA6DXaOq3gaHMTR6tprNldHjN4WyxsowbjIM8BJMfZP/JMjBTT10reieRbRbhKaLts E9wg==
X-Gm-Message-State: APjAAAUwSYuUOy0NvT5DKdmWVMkmSNVIBCcD3ye/Z1mAnGAPcyBwPPKQ Te+kMl9uj29L+YFS0VgeuLt+Fz0sGAHN1//5pyY=
X-Google-Smtp-Source: APXvYqy2QTo/2VQJ/802PhgptqKhmHUJ94bSpKJ5iZ6SGzhow64R3xYmQwqLdq9sXlABmeVYRD3GDNkRAazA7Lp4vbw=
X-Received: by 2002:a05:6830:1345:: with SMTP id r5mr23961638otq.158.1567630417966; Wed, 04 Sep 2019 13:53:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tim Wicinski <>
Date: Wed, 4 Sep 2019 16:53:26 -0400
Message-ID: <>
To: Dave Crocker <>
Cc: "Murray S. Kucherawy" <>, IETF DMARC WG <>
Content-Type: multipart/alternative; boundary="00000000000033bb0c0591c0661f"
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: Wed, 04 Sep 2019 20:53:46 -0000


I've had discussions with folks within the W3C on the PSL and the
possibility of extending it,
and there is always interest in considering requests from the IETF, but
they are the final
decision makers.

The whole idea of running an experiment would be to produce data that can
be shared and
can help the W3C modify the PSL.  Suggesting changes without understanding
their effects sounds would concern me.

(hats/no hats/I apologize for not knowing)

On Wed, Sep 4, 2019 at 9:29 AM Dave Crocker <> wrote:

> Murray,
> Thanks for the diligent reply.
> (As a matter of etiquette, I will again apologize for not having
> submitted my concerns earlier.  Partially, this was because my
> assessment of the work did not gel until recently.)
> Some responses:
> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
> >  From a higher level view, the experiment can be seen as the temporary
> > construction of an augmented PSL (i.e., the actual PSL coupled with the
> > queryable registry described in Appendix B), which DMARC then can
> > consume to resolve the use cases that have appeared which now need to be
> > addressed.  The portion of the experiment comprising an augmentation to
> > DMARC’s algorithm would therefore not be part of DMARC permanently.
> > Then, if the experiment proves effective, that would become prima facie
> > evidence that the PSL, augmented with this additional information, would
> > enable DMARC to resolve those use cases.  Such an augmented PSL would
> > still conform to the desirable separation of functions to which you
> alluded.
> This model of iterative design does not match my own sense of IETF work,
> experimental or otherwise.
> Simply put, 'temporary' is an appealing but highly misleading construct,
> in the form and scale of a standards body.[*]  The closest reality comes
> to matching that term is when the 'experiment' fails utterly and the
> effort must completely restart. When work like this operates over a
> period of years and at Internet scale, nothing is temporary.
> If an experiment succeeds, the specified work will have become
> entrenched and there will be significant resistance to making major
> changes.
> With respect to the use of this work as a model for changes to the PSL,
> unfortunately the spec is not written in a fashion to support that.
> This really is a core concern, in my view: the work needs to have a
> basic model that really is expected to be appropriate for the long term;
> hence my suggestion to highly limit any changes to DMARC and, instead,
> cast the bulk of the work as augmenting the PSL.
> That said, and as for getting changes to the PSL, based on my
> interactions with that community, I think it unlikely.  There does not
> seem to be the interest or resources for such work.  Strategically,
> that's the biggest hurdle to overcome, IMO.
> > In addition, there are a few very large players in the space who are
> > unfortunately reticent to declare publicly that they are interested in
> > seeing this evolutionary experiment proceed.  These include large email
> > providers and operators of sizable TLDs in need of the capabilities
> > pursued here. This provides some weight to the idea that this will not
> > be simply a niche experiment.
> Good to hear.
> > Lastly, we note that the idea of “walk up one node” came from an email
> > thread in December[1] wherein you suggested that approach, and which the
> > PSD draft now follows.  We are thus a little surprised by the assertion
> > that it should not proceed at all. Was there some content of that thread
> > that was not taken into account that would make it palatable?
> ..
> > [1]
> Sigh.  Yeah.  Still again, sorry.  Mostly this is a case of letting an
> idea simmer for a while, to think about it more.  My feeling is that the
> idea does not adequately attend to the items 1 and 2 I listed in that note.
> Hence my current view that:
> 1. The change to DMARC should be limited to permitting the query for the
> organization domain to be anywhere in the DNS tree, including a TLD.
> Within DMARC this would not look like 'extra' mechanism.
> 2. The mechanism that processes that query should be cast strictly as a
> PSL enhancement, independent of DMARC.
> d/
> [*] Note the 'obsolete' construct in RFC 5322.  It was introduced in RFC
> 2822, as a revision to RFC 822, 20 years ago.  As is obvious, it's
> intent was to eliminate use of the portions of RFC 822 deemed obsolete.
> Yet these portions still haven't been eliminated from the specification.
>   Twenty years later.
> --
> Dave Crocker
> Brandenburg InternetWorking
> _______________________________________________
> dmarc mailing list