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

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=
40valimail.com@dmarc.ietf.org> wrote:

> On Wed, Feb 1, 2023 at 7:14 PM Douglas Foster <
> dougfoster.emailstandards@gmail.com> 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:* todd.herr@valimail.com
> *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
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>