Re: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd post-WGLC Status

Jane Moneypenny <> Sun, 29 September 2019 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4442B120099 for <>; Sun, 29 Sep 2019 05:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lj5lss2vz_2z for <>; Sun, 29 Sep 2019 05:05:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CE03120018 for <>; Sun, 29 Sep 2019 05:05:17 -0700 (PDT)
Date: Sun, 29 Sep 2019 12:05:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1569758714; bh=GCrIwrZ1xxkMG1zsHD92EGWilVsD9GZz6PQvs+u6nPc=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=RJEobQNZdSx+CEFq+ZnwsjJk4jj89IFsL0GQf7yDYMfNT12R8PRsF5RnFMxnvMDeY Iz+R7BQsoZtOx9UQ4sIT7OEG4ZIHTWmvbIAlUV/HW2vAsRlsNGVXVfoiuG6iJHmei0 UlavSlQ7kysTJwJK094AbBc0KPkhjh0mowYNnjaE=
To: "" <>
From: Jane Moneypenny <>
Reply-To: Jane Moneypenny <>
Message-ID: <>
In-Reply-To: <2080369.Hr1xgu6sVx@l5580>
References: <2080369.Hr1xgu6sVx@l5580>
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: <>
Subject: Re: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd post-WGLC Status
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: Sun, 29 Sep 2019 12:05:20 -0000

2.6. Non-existent Domains
For DMARC purposes, a non-existent domain is a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records.

- sometimes a domain used for mailing purposes does not have a MX record - I am not sure if 'and' is appropriate word here,
- question: what if there is a CNAME record?,
- email receivers could/should perform reverse DNS lookup, however they do not - as a result, an email from (both: Envelope and Mail from), is accepted by the MTAs,
- today, an email ‘from’ (Envelope and Mail) NXDOMAIN is accepted by vast majority of MTAs, and SPF check result is “spf=neutral” (in general), same with non-existent sub-domains (even if there is DMARC in place a message from non-existent sub-domain could be successfully delivered).

There is a solution for non-existent subdomains: Wildcard SPF. Wildcard SPF covers sub-domains (if there is no other RR for such sub-domain), and (in general) it works with DMARC.
For example:
* IN TXT v=spf1 -all
together with IN TXT v=DMARC1; p=reject;
Covers each and every NX-sub-domain, and it works pretty well.

Currently proposed solution, even with the 'np' tag, may not work. It could be rather fatally flawed.

That being said, we should consider (for PSDs) a solution similar to a Wildcard SPF, if we want PSD-DMARC work as it should.

And, because a Wildcard SPF is a TXT - not A, AAAA, MX - record, and it does not mess with the definition (2.6. Non-Existent Domains).


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 28, 2019 11:38 PM, Scott Kitterman <> wrote:

> WGLC started on 2019-06-26. It ended 2019-07-17.
> 2019-06-26: WG Secretary called for additional discussion on three topics:
> 1.  What further context is needed in the introduction
> 2.  If explicit call outs to ICANN/limited operator capacity to implement are
>     needed
> 3.  If an np= tag is needed to allow PSD functioning for only NXDOMAINs
>     By the end of the WGLC period, after a slow start, there was a vigorous
>     discussion on all these issues and (with a few days post-WGLC for the np= tag
>     discussion to finish) moved towards what was in my judgment a reasonably solid
>     consensus. All issues that people brought up were addressed by the WG
>     (including inclusion of some recommended editorial changes made before WGLC
>     that hadn't made it into the draft).
>     A new revision addressing the WGLC discussion (-05) and document shepherd
>     comments was uploaded 2019-07-27.
>     Post WGLC discussion:
>     2019-07-22: A question was brought up if the draft should include hard
>     requirements to forbid mail from non-existent domains. The WG concluded that
>     independent of the wisdom of such a rule, it was out of scope for the WG.
>     2019-07-27: A set of editorial nits were provided against -05.
>     2019-07-31: Additional document shepherd feedback based on revisions provided
>     in -05 and earlier comments.
>     2019-08-09: New revision (-06) published fixing editorial nits and
>     incorporating additional changes based on document shepherd feedback.
>     2019-08-10: Comments on -06 from Alessandro Vesely, but no suggested changes.
>     2019-08-13: Comments on the general PSD DMARC concept from Dave Crocker.
>     2019-09-03: WG Chair feedback on 2019-08-13 comments, some discussion ensues.
>     2019-09-09: Discussion concludes. It appears to me that the upshot of the
>     discussion is that the Section 2.3 Longest PSD definition needs to be updated.
>     All other issues have been addressed.
>     2019-09-24: Alessandro Vesely reports having implemented PSD DMARC in
>     zdkimfilter for Courier MTA using an alternative data format for PSD DMARC
>     participants based on the PSL format.
>     Based on the post-WGLC discussion, I believe an updated draft before IETF last
>     call is appropriate with three changes:
> 4.  Updated Longest PSD definition:
> > 2.3. Longest PSD
> > The longest PSD is the Organizational Domain with one label removed.
> 2. Addition of the PSL data format to Appendix B (it would be B.3). I
> haven't drafted text yet, but I don't expect it to be controverisial.
> 3. Add zdkimfilter to Appendix C (also didn't make text yet).
> Unless someone tells me otherwise, I plan to go ahead with those changes.
> Scott K
> dmarc mailing list