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
- [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd post… Scott Kitterman
- Re: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd … Jane Moneypenny
- Re: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd … Scott Kitterman
- Re: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd … Scott Kitterman
- Re: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd … Scott Kitterman