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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
