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

Jane Moneypenny <jane.moneypenny@protonmail.com> Sun, 29 September 2019 12:05 UTC

Return-Path: <jane.moneypenny@protonmail.com>
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 4442B120099 for <dmarc@ietfa.amsl.com>; Sun, 29 Sep 2019 05:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com
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 Lj5lss2vz_2z for <dmarc@ietfa.amsl.com>; Sun, 29 Sep 2019 05:05:17 -0700 (PDT)
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE03120018 for <dmarc@ietf.org>; 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; d=protonmail.com; 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: "dmarc@ietf.org" <dmarc@ietf.org>
From: Jane Moneypenny <jane.moneypenny@protonmail.com>
Reply-To: Jane Moneypenny <jane.moneypenny@protonmail.com>
Message-ID: <L0TZkYX7v684oxaWVJXJfQiYRTiGNddxEX7NR99qAACsR17fi216vUcfYmdPosn5PjkxGt8W9qGOcz3oMl-mlmZd2TeWwt0wDbWuEQM1R20=@protonmail.com>
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: <https://mailarchive.ietf.org/arch/msg/dmarc/mfcDEo2YX_5fxaI1tCdwZkb9qFw>
Subject: Re: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd post-WGLC Status
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: Sun, 29 Sep 2019 12:05:20 -0000

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

Comments:
- 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:
*.example.com IN TXT v=spf1 -all
together with
example.com 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).


Sincerely,
Mnpn.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 28, 2019 11:38 PM, Scott Kitterman <sklist@kitterman.com>; 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
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc