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

[Douglas Foster <[e-mail]>]

You actually summarize my points pretty well.  Here are the three concepts:

1) People send mail with non-existent RFC5322.From domains (subdomains of
existent domains)  all the time, and that mail is wanted.

Yes, that is my assertion based on research into my mail stream.   I spent
several months checking every From address for NXDomain, MX Exists, or A
Exists.   I found that none of these tests added any value; it was mostly
an exercise for the benefit of this issue and this group.   After a while,
I stopped checking to reduce overhead.   This is an assertion of
fact, which I have presented several times.   Every mail stream is
different, so maybe someone else can present different data.   But oddly,
no one has presented other data, which makes me wonder if no one else can.

Anyone can prove me wrong with more comprehensive data, or you can accept
my results on blind faith, but you should not write text based on untested
assumptions, when actual data will answer the question.

2) The NP=reject tag is useful when PSD=Y, when applied to the PSD+1
organizational domain only.

Every organizatioin MUST be registered.  Mail coming from an unregistered
organization should be rejected.

However, when a PSD's NP clause is applied to non-existent subdomains of an
existent organization that has no DMARC record, the use is inappropriate.
 Based on #1, it is not only inappropriate but also likely to be wrong.
With this limitation, PSD policies should always publish NP=reject.

3) The NP tag may be of interest to some organizations.

Whether NP on organization policies is useful or not will depend on whether
it is applied correctly or not.   My expectation is that some organizations
will publish NP=reject when they should not, causing false positives.   I
also expect that some organizations will publish NP=reject correctly, and
the test will never fail because spammers are very unlikely to send using
non-existent subdomains of registered domains.

Assuming that there are exceptions to everything, perhaps someone can find
some messsages that fits these characteristics.  If so, we have to look at
the signal-to-noise ratio between correctly blocked messages and
incorrectly blocked messages.   If the ratio is wrong, evaluators will
disable the test anyway.

Finally, I don't have any problem with the definition of non-existent.   A
domain or subdomain is non-existent if it returns NXDOMAIN.   If the
organization domain does not exist, any messages that use that domain
should be blocked.   If the organization domain does exist, I am
unconcerned whether a particular subdomain exists.   If someone wants to
convince me that I should be concerned, I need data.

Doug





On Fri, Feb 3, 2023 at 9:32 AM Todd Herr <todd.herr=
[e-mail]> wrote:

> On Fri, Feb 3, 2023 at 3:35 AM Douglas Foster <
> [e-mail]> wrote:
>
>> Time to eat crow.
>>
>> You are right, the RFC5322.From address is the default Reply-To.   The
>> rest of the argument stands.
>>
>
> I'm at a bit of a loss to understand what argument you're making here. I'm
> going to answer on the assumption that your argument is "People send mail
> with non-existent RFC5322.From domains all the time, and that mail is
> wanted mail, and also the np tag shouldn't exist."
>
> Apologies if that's not your argument. If that's the case, please describe
> your argument and I'll reply again.
>
>>
>> So let's do a simple test on real mail:    Somebody implement the
>> proposed NP test to detect non-existent subdomains of legitimate mail.
>>  Don't count messages that are rejected because of NXDOMAIN on the SPF
>> policy lookup.   Don't count messages that are rejected because of DMARC
>> QUARANTINE or REJECT.   That leaves messages with these characteristics:
>>
>
> I don't understand your use of the phrase "NP test to detect non-existent
> subdomains of legitimate mail". The np tag is defined as a policy assertion
> for non-existent subdomains of the domain publishing a DMARC record, one
> that should be applied to messages using non-existent subdomains that fail
> DMARC validation checks. As I've stated before, I don't believe messages
> using a non-existent domain as their RFC5322.From domain (or RFC5321.From
> domain, for that matter) don't deserve the privilege of being accepted, but
> I haven't had a say in such matters since 2010. For the purposes of this
> message, I'll agree to the stipulation that I'm wrong on this topic, and
> that messages using non-existent domains in either >From header are worthy
> of being accepted.
>
>> - MailFrom domain exists
>> - From organization domain exists
>> - From domain does not exist based on your NP language, or any other
>> non-replyable rule you want to use.
>>
>
> Section 3.2.6 of DMARCbis, titled "Non-existent Domains", reads in its
> entirety:
>
> "For DMARC purposes, a non-existent domain is consistent with the term's
> meaning as described in [RFC8020 <https://www.rfc-editor.org/info/rfc8020>
> ]. That is, if the response code received for a query for a domain name
> is NXDOMAIN, then the domain name and all the names under it do not exist."
>
> That's not my language.
>
> So, we're at a state where the RFC5322.From domain does not exist, and the
> DMARC policy to be used for this message must come from a domain above it
> in the DNS hierarchy, because _dmarc.RFC5322.From.domain cannot exist based
> on RFC8020.
>
> Process between 1000 and 1,000,000 messages and review the ones that are
>> flagged by your test.   Report (a) number of messages flagged as suspicious
>> based on your  rule, and (b) number of unwanted messages flagged within
>> that group.    My testing indicates that the (a) group will be small and
>> the (b) group will be very close to zero.
>>
>> The reality is that attackers have very little reason to attack a
>> non-existent subdomain, because they always have existent subdomains that
>> will be more promising targets because they are real.    If they do start
>> attacking non-existent subdomains, there are existing options to defend:
>>
>> - To protect non-existent subdomains only, without affecting mailing
>> lists:   use domain-level p=none policies on all subdomains that send mail,
>> and sp=reject on the organization domain.
>>
>
> This option cannot be implemented, as one cannot publish a domain-level
> p=none policy on a non-existent subdomain that sends mail.
> _dmarc.RFC5322.From.domain cannot exist if RFC5322.From.domain does not
> exist in the DNS. This would require that the 'sp' tag be applied to the
> non-existent subdomain, and sp=reject would only apply to those messages
> that fail DMARC authentication checks. In your scenario, I'm presuming that
> the message would pass DMARC authentication checks, because there's a DMARC
> policy published at the org domain, and either the MailFrom domain or the
> DKIM signing domain aligns with the non-existent RFC5322.From domain and
> SPF or DKIM passes. Is my understanding of your scenario correct?
>
> Understand too that "p=none" even if it could be published for this
> non-existent domain is not a guarantee that a message will be accepted even
> if it fails DMARC authentication checks. "p=none" effectively means "Don't
> take the DMARC authentication results into account as part of your message
> disposition decision, which doubtless include many factors other than the
> DMARC validation results. I understand that that decision can still be
> 'deliver to spam', 'reject', or anything you deem appropriate, based on
> those many other factors."
>
>>
>> - To protect all subdomains:  use sp=reject on the organization domain.
>>
>
> This is the only option that will apply to non-existent subdomains in the
> absence of an np tag. Again though, sp=reject would only apply to those
> messages using a non-existent RFC5322.From domain if those messages don't
> pass DMARC validation checks.
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* [e-mail]
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>