It matters not whether "_dmarc.domainpath" returns NXDOMAIN. In fact it is expected to occur before the tree walk lands on a PSD policy.
What does matter is that the NP policy should only apply when the organization domain is non-existent. Existing domains have the right to send using a non-existent subdomain. The drift of the conversation seems to be an assumption that PSD policies will only appear where the member domains are required to have a DMARC policy. If this is true, landing on the PSD policy for any reason represents a contractual violation, so the distinction between non-existent subdomain and non-existent domain is moot. If this is not true, then we should make the distinction. Any organization domain should be existent before it sends mail, as it is required by the ICANN name registration process. Checking for NXDOMAIN on the organization is an appropriate defense whether a PSD policy exists or not. Doug Foster On Tue, Jan 31, 2023 at 11:36 AM Emil Gustafsson <emgu= [email protected]> wrote: > Since the concept of non-existing domains is important from this privacy > perspective, should we call out how we suggest that is determined? > On top of my head, using the example from the dmarcbis, would the DNS > lookups actually become 6 in this case (plus one WHOIS lookup)? > > 1. _dmarc.a.b.c.d.e.mail.example.com *[does not exist]* > 2. _dmarc.e.mail.example.com *[does not exist]* > 3. _dmarc.mail.example.com *[does not exist]* > 4. _dmarc.example.com *[does not exist]* > 5. _dmarc.com *[do exist]* > 6. example.com > - If this succeeds; we know the domain exists > - If this does not exist - should we recommend making a WHOIS > lookup for example.com? > > Or should we just leave it to the mailbox providers to decide for > themselves how to do this? > /E > > On Mon, Dec 19, 2022 at 6:49 PM Brotman, Alex <Alex_Brotman= > [email protected]> wrote: > >> Thanks Scott. I'll try to get this merged in the next few days. I have >> two other merges from Ale that I need to sort out. I'll get a new rev done >> after they're both merged. >> >> >> >> -- >> >> Alex Brotman >> Sr. Engineer, Anti-Abuse & Messaging Policy >> Comcast >> >> ________________________________________ >> From: dmarc <[email protected]> on behalf of Scott Kitterman < >> [email protected]> >> Sent: Monday, December 19, 2022 10:43 AM >> To: IETF DMARC WG >> Subject: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate >> Reporting Draft >> >> The RFC 9091 privacy considerations, with minor updates need to be >> incorporated into the DMARCbis effort. Given the constraints on PSDs >> requesting failure reports, they belong in the aggregate draft. I've >> opened a >> PR to, with some light editing, pull them in: >> >> >> https://urldefense.com/v3/__https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/pull/15__;!!CQl3mcHX2A!E1ob9b6zOndeoRR8Tg7UMGAjqaq9Oo_z3eoYEByvsS-ttdsgNKpMMLcme9a-O1864chySx8TnYuf_EiF96H_$ >> >> I don't think it should be particularly controversial, since it's almost >> exactly what the WG already agreed for RFC 9091, but people should review >> it. >> >> Scott K >> >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!E1ob9b6zOndeoRR8Tg7UMGAjqaq9Oo_z3eoYEByvsS-ttdsgNKpMMLcme9a-O1864chySx8TnYuf_IbBOtPw$ >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
