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

[Todd Herr <[e-mail]>]

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.