Re: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate Reporting Draft

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=
40google.com@dmarc.ietf.org> 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=
> 40comcast.com@dmarc.ietf.org> 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 <dmarc-bounces@ietf.org> on behalf of Scott Kitterman <
>> sklist@kitterman.com>
>> 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
>> dmarc@ietf.org
>>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!E1ob9b6zOndeoRR8Tg7UMGAjqaq9Oo_z3eoYEByvsS-ttdsgNKpMMLcme9a-O1864chySx8TnYuf_IbBOtPw$
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>