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

[Douglas Foster <[e-mail]>]

Time to eat crow.

You are right, the RFC5322.From address is the default Reply-To.   The rest
of the argument stands.

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:
- 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.

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.

- To protect all subdomains:  use sp=reject on the organization domain.

Maybe somebody can produce different results than my testing, since
everyone's mailstream is different.   I look forward to your evidence.

Doug Foster



On Thu, Feb 2, 2023 at 11:36 PM Douglas Foster <
[e-mail]> wrote:

> Please give me credit for having thought about non-existent domains when
> everyone else was insisting that the MX-A-AAA test will work for
> RFC5322.From, simply because it works for the RFC5321.MailFrom.
>
> As for non-existent subdomains, I have documented all of this previously:
>
> - RFC5322.From has nothing to do with the ability to reply to a message.
>  Replies are determined by RFC5321.MailFrom or the Reply-To header.
>  Additionally, a high percentage of mass mailings are sent with some
> version of a NOREPLY name, and are accepted as a matter of course.  There
> is even a NOREPLY.COM domain that is used for this purpose by some of my
> correspondents.
>
> - DMARC relaxed alignment can be used to authenticate a non-existent
> RFC5322.From domain using an existent and verified MailFrom or DKIM domain.
>
> - Real senders send legitimate messages from non-existent RFC5322.From
> domains.  I do not have a particularly large incoming mail flow, but when I
> tested for the condition, I was averaging about one message in 1000 were
> from non-existent subdomains of existent parent domains.  It added nothing
> to my filtering effectiveness so I turned off the test after documenting my
> results to the group.
>
> All domains must be registered with a PSO, therefore a non-existent
> organization is fraudulent, and it is in the legitimate interest of the PSO
> to inhibit such fraud by any means possible.   Non-existent domains of a
> registered domain are in internal matter at not the business of the PSO.
>  If a contractual relationship between the PSO and the domain owner has
> stricter requirements, it is not something that can be enforced by an
> evaluator who is not a party to the contract.
>
> The current language says what you intend, and what you intend is a
> mistake.  Again.
>
> DF
>
> On Thu, Feb 2, 2023 at 9:13 AM Todd Herr <todd.herr=
> [e-mail]> wrote:
>
>> On Wed, Feb 1, 2023 at 7:14 PM Douglas Foster <
>> [e-mail]> wrote:
>>
>>>
>>> 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.
>>>
>>
>> I disagree with both statements here.
>>
>> A policy record containing an 'np' tag cannot exist in the DNS at
>> _dmarc.domain without the name 'domain' existing in the DNS, so I can't
>> even really parse your first statement. Can you clarify what you mean here,
>> please?
>>
>> Beyond that, the np tag is currently defined (correctly, in my opinion)
>> thusly:
>>
>> Indicates the message handling preference of the Domain Owner or PSO for
>> mail using non-existent subdomains of the domain queried. It applies only
>> to non-existent subdomains of the domain queried and not to either existing
>> subdomains or the domain itself.
>>
>>
>> As for the claim that existing domains have the right to send using a
>> non-existent subdomain, while such sending practices are outside the scope
>> of DMARC, those domains should have no expectation that such mail will be
>> accepted, on the grounds that the RFC5322.From domain being non-existent
>> means that the message cannot be replied to, and is therefore not worthy of
>> acceptance.
>>
>> --
>>
>> *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
>>
>