Subject: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

From: Douglas Foster <[email-masked]>
Date: Sat, 12 Jun 2021 08:55:33 -0400

Below is my proposed language for dealing with the problems that NP is
intended to address:
- unused DNS names
- non-existent DNS names

It provides supporting rationale, and provides a more complete solution
than anything suggested previously, and ties the design directly to the
mailing list problem.

I have labelled the sections starting with "X," because I am not sure of
the best way to position this text into the flow of the current draft.

Doug Foster

x. Reducing the scope of the SP policy

DMARC introduces a method for the domain owner to state "at time of
transmission, authorized emails will always authenticate using DMARC
criteria".   However,this authentication can be lost in transit if message
modification occurs in transit, as discussed in RFC 7960.  This possibility
can make domain owners reluctant to move beyond sp=none.  This is a
significant loss, because sp=none opens a vast namespace to domain abuse,
including
- names that are DNS domains but are not protected by a domain-level DMARC
policy
- names that are DNS records records rather than DNS names, and cannot be
protected by a domain-level DMARC policy
- names that are not in DNS at all, and therefore cannot be protected by a
domain-level DMARC policy.

To mitigate these impacts, it is useful to distinguish names used as email
domains from names that are not used for email.   Names that are never used
for email are never authorized at time of transmission, and therefore can
be blocked without concern about in-transit modifications.   Several
methods are presented for addressing this objective.

x.1 Implement mail domains as DNS domains with domain-level DMARC policies.

Mail domains are often implemented as DNS domains, but this is not
required.   MX records and SPF policies can be attached to a named resource
record or a wildcard resource record, while DMARC policies can only be
attached to a DNS domain.

Any name that is configured as a DNS resource record can be reconfigured as
a subdomain name supported by resource records which match the subdomain
name, and names that are not in DNS can be added as DNS domain names.  Once
all used mail domain names are configured as DNS domains, they can be
configured with DMARC policies.   Once this is complete, the SP policy will
only apply to unused and non-existent names.  This will permit use of
SP=reject because any such messages will have been unauthenticated at
origin as well as being unauthenticated at reception.   This approach is
fully compatible with RFC 7489 implementations of DMARC.

x.2 Implement an NP policy

The NP policy assumes that names used for mail can be reliably identified,
so that names not used for mail can be categorized as not authorized.  Two
approaches are used:

- For mail domain names that are used with SMTP, the name is assumed to
also be used as an RFC5322.From domain name.   This is indicated by an MX
record which evaluates to an IP address, or an SPF policy which does not
begin with an ALL term.  (RFC 7505 indicates that an MX record which does
not evaluate to an IP address is useful to indicate that a domain does not
accept incoming mail.  Based on RFC 7208, content after an ALL term is
ignored, so a policy of "-ALL" indicates that the name is never used as an
RFC5321.MailFrom domain and an ALL term with any other modifier is a
meaningless policy.)

- For mail domain names that are not used with SMTP, a new TXT record is
defined, with content "DMARCFROMv1".   The presence of this TXT record
indicates that the associated DNS domain, named DNS resource record, or
wildcard DNS record should be considered as potentially in use as an
RFC5322.From domain name.

Names which are identified by MX record, SPF policy, or DMARCFROMv1 TXT
record are considered in use names and are evaluated using the P or SP
policy.   Names which do not match these criteria are evaluated using the
NP policy.   This allows unused and non-existent names to be given a
stricter DMARC policy than used names.

To implement an NP policy, domain owners may need to make DNS changes:
- For used domain names that are only identified by an A or AAAA record, an
MX record or DMARCFROMv1 TXT record is needed to explicitly indicate that
the name is used for mail.
- For used domain names that are not in DNS at all, a DMARCFROMv1 TXT
record is needed to indicate that the name is used for mail.

The NP policy does not require that all mail domains become DNS domains,
but the NP policy will only be understood by evaluators which use this
specification.  Consequently, it is preferable to ensure that all mail
domains are implemented as DNS domains.

x,3 Implement SPF -ALL policies on unused names.

Organizations that have configured SPF to protect their valid
RFC5321.MailFrom domains may not have taken the extra measure of using SPF
to obstruct names that are not used for mail.  While not directly part of
DMARC, an authentication result of "DMARC=NONE SPF=FAIL" is a more
meaningful result than "DMARC=NONE, SPF=NONE".  Consequently, it is
desirable to  ensure SPF=FAIL for any names that are never used as
RFC5321.MailFrom domain names.   Since SPF has no inheritance, this
requires many entries.

To demonstrate, assume that the domain "nomail.example.com" contains only a
webserver at "www.nomail.example.com".   Multiple SPF records are needed to
maximize protection of this subdomain from improper use.   An SPF policy of
"-ALL" is needed on:
- the domain itself, nomail.example.com,
- named resource records, including www.nomail.example.com
- the wildcard resource record, *.example.com.

---

From: Dotzero <[email-masked]>
Date: Sat, 12 Jun 2021 11:09:11 -0400

On Sat, Jun 12, 2021 at 8:56 AM Douglas Foster <
[email-masked]> wrote:

> criteria".

The portion of the above statement is an incorrect assertion and is
meaningless to validators and mailbox receivers. It is well known (at least
to validators and receivers) that there is a significant subset of senders
who publish incorrect SPF records or improperly DKIM sign messages or
improperly publish DKIM in DNS or improperly publish DMARC in DNS. Further,
a validator or mailbox provider can only go by what they see and know at
the time they attempt to determine whether a given message validates or not.

> However,this authentication can be lost in transit if message modification
> occurs in transit, as discussed in RFC 7960.  This possibility can make
> domain owners reluctant to move beyond sp=none.  This is a significant
> loss, because sp=none opens a vast namespace to domain abuse, including

Senders may be reluctant to implement DMARC for any number of reasons. I've
given email authentication training to thousands of people through OTA when
it was around and to/through the U.S. Federal government. Not once has
anyone raised the above as reasons for reluctance to implement DMARC,
either in total or for implementing policy.

> methods are presented for addressing this objective.

As pointed out above, you are asserting impacts not in evidence when you
state that these impacts are of concern. A difference, in order to be a
difference, must make a difference. You have presented nothing to show that
this is an issue causing senders not to implement DMARC.

> Any name that is configured as a DNS resource record can be reconfigured
> as a subdomain name supported by resource records which match the subdomain
> - For used domain names that are only identified by an A or AAAA record,
> an MX record or DMARCFROMv1 TXT record is needed to explicitly indicate
> that the name is used for mail.

As you state, it is NOT directly part of DMARC.

>
> To demonstrate, assume that the domain "nomail.example.com" contains only
> a webserver at "www.nomail.example.com".   Multiple SPF records are
> needed to maximize protection of this subdomain from improper use.   An SPF
> policy of "-ALL" is needed on:

Anyone sophisticated enough to be concerned that this is a problem is
sophisticated enough to publish the appropriate DNS records if they choose.
Your proposal adds unnecessary complexity to address something that is
essentially a non-issue in the real world of DMARC and interoperability.
The more complexity that is added reduces the likelihood of implementation
OR if implementation is attempted, correct implementation.

This proposed change should not be considered by the working group.

Michael Hammer

---

From: Douglas Foster <[email-masked]>
Date: Sat, 12 Jun 2021 14:48:25 -0400

(Subject ticket number corrected.)

Michael, I am surprised and disappointed by the severity of your critique.

NP Policy
-------------
The NP policy is upon us.   PSD for DMARC demonstrated the need.    The
problem is that their definition of NP, which the current DMARCbis draft
inherits, is a pre-SPF test for an invalid SMTP MailFrom address.   It is a
bizarre stretch to apply that test to the RFC5322.From address.    The
current test is insufficiently defined, undefended, and indefensible.  It
must be fixed.   The focus of this draft is a proposed fix, because there
have been no other fixes offered.

The key insight behind the NP policy idea is that some domain abuse can be
detected and rejected without depending on the attributes which create the
mailing list problem.  The best boundary for the NP policy is between those
names that are used as FROM address and those that are not.   Domain owners
currently lack sufficient mechanism to signal that condition correctly.

I evaluated options based on NXDOMAIN, but rejected them.  Even when done
perfectly, NXDOMAIN excludes a smaller set of unauthorized names than this
approach, and seems more difficult to implement.  NXDOMAIN has some nuances
which I found problematic.  This proposal introduces relatively low
compliance measures for those domain owners that wish to implement NP.

The Introduction
----------------------
As to the introduction, I think the relationship between SP=NONE and the
mailing list problem has been well elucidated.    Nor do I think that an
introductory sentence needs to enumerate all possible reasons for SP=NONE.
 But if you prefer to simply say "some domain owners have difficulty moving
beyond SP=NONE,", without any additional comment, I can accept a change
along those lines.   Getting the correct definition of NP is my priority,
not the opening sentence.

Validate vs Reject
------------------------
Sender authentication involves two partially independent goals:  proving
that a message is definitely authorized, and proving that a message is
definitely not authenticated.   Proving authorization is only relevant for
names that are used as email addresses.   Proving non-authorization has a
much larger scope, because it involves all possible names, not merely
in-use names.

RFC 7489 attempted to prove non-authentication based on domains achieving
SP=REJECT and messages being delivered without in-transit loss of
credentials.   This has not worked out well in practice.   NP defines
non-authentication based on attributes which are not dependent on transit,
and therefore it is a very powerful idea.

Level of Detail
-------------------
I could be convinced to move some of this content into a Best Practices
document.,   But my target audience is not limited to the big organizations
that can build custom code and spend a large amount of money on
consultants.   I am equally concerned about the smaller players who are
dependent on off-the-shelf products available from vendors, and the
developers witin those vendors who often implement to the specification
rather than to the security problem.   So yes, I favor laying things out
clearly, rather than assuming that sophisticated people will be able to
read between the lines.

If you have a different definition of NP, let's hear the proposal and its
defense.

Doug Foster

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 Jun 2021 13:12:01 +0200

Doug,

maybe it's me, but I have problems understanding your proposal.  Let me quote 
what seems to hamper my comprehension.

Besides, #11 in the Subject: is obviously a typo.

On Sat 12/Jun/2021 14:55:33 +0200 Douglas Foster wrote:
> ties the design directly to the mailing list problem.

I couldn't see where mailing lists are taken into account.

> occurs in transit, as discussed in RFC 7960.  This possibility can make domain 
> owners reluctant to move beyond sp=none.

Why do you consider SP irrespective of P?  Actually, SP could be used by 
"simple" mail sites, those which make no use of subdomains for email.  In such 
cases, setting sp=reject can safely prevent generic abuses even for domains 
having p=none.  It sounds similar to null SPF records for non-mail hosts.

> Mail domains are often implemented as DNS domains, but this is not required.

Please, stick to well established jargon.  Tim made a good synthesis in section 
2.2 and ensuing ones.  A /DNS domain/ is defined by RFC 1034:

     A domain is identified by a domain name, and consists of that part of
     the domain name space that is at or below the domain name which
     specifies the domain.

In this sense, the concept of non-existing domain names that are legitimately 
used sounds like a contradiction in terms.

> Once all used mail domain names are configured as DNS domains, they can be
> configured with DMARC policies.

AFAICS, a /used mail domain name/ which is not a DNS name is a /non-existent 
domain/ found in some (forged) email addresses.  I agree that such practice 
should be discouraged.  Yet, that doesn't seem to be the point here...

BTW, are there organizations that use non-existent (sub) domains during the 
delivery of legitimate messages?  Years ago I saw sporadic mailing list authors 
forged like [email-masked].  Is that what you're talking about?

> RFC5322.From domain name.

Ok, that is clear, but, IMHO, won't work.  Working MXes or IP addresses are a 
necessary condition to receive mail.  Thus, a purist receiver has to accept 
such domains as valid.  Therefore traditionalist domain operators will not see 
a compelling need to define any auxiliary TXT records.  A new RR type of this 
kind would most probably be going to characterize mass mailers who hasten to 
adopt any new trick that seems to offer a chance to increase deliverability. 
Undoubtedly, someone would be tempted to discard senders based on that (as it 
happened to DKIM...)

An organization which wants to say sp=reject but does use some email subdomains 
had better define plain DMARC records for them.  Records can be easily 
duplicated by CNAMEs.  If we needed to vary some parts but not others, for 
example a different policy but the same aggregate reporting address, we should 
define something equivalent to SPF's include.

> - For used domain names that are not in DNS at all, a DMARCFROMv1 TXT record
> is needed to indicate that the name is used for mail.

Actually, /any/ record definition will turn a domain into an existing one. 
However, by Section 2.7 of PSD, which defines the MX/A/AAAA test, such domain 
would still be non-existing.  In that sense, DMARCFROMv1 conflicts with PSD.

> Organizations that have configured SPF to protect their valid RFC5321.MailFrom 
> domains may not have taken the extra measure of using SPF to obstruct names 
> that are not used for mail.  While not directly part of DMARC, an 
> authentication result of "DMARC=NONE SPF=FAIL" is a more meaningful result than 
> "DMARC=NONE, SPF=NONE".  Consequently, it is desirable to  ensure SPF=FAIL for 
> any names that are never used as RFC5321.MailFrom domain names.   Since SPF has 
> no inheritance, this requires many entries.

That's a well known SPF issue:
http://www.open-spf.org/FAQ/Common_mistakes/#all-domains

There used to circulate scripts to generate null SPF records.  It would help if 
DNS hosting services implemented a checkbox to carry out such task.  But this 
if far OT.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Mon, 14 Jun 2021 19:19:03 -0400

Thank you for asking.

OK.,  I will use the term "email suffix" for the part of an email address
that follows the @ character,  and "DNS domain" for a name that appears in
DNS as a domain object.

An email suffix can legitimately be associated with an A/AAAA
resource record that is not a DNS domain.   For example, an alarm
monitoring system might send alarms using the server's host name as the
email suffix (e.g. [email-masked]).   MX and SPF can also be
configured for Monitor.Example.Com even though it is not a  DNS domain.
This is specifically authorized by RFC 5321.

A spoofed email address could use any email suffix, such as
[email-masked].   Our interest must extend beyond names
that are in DNS.

In my mailstream, most messages sent from mailing services use the mailing
service domain for the SMTP address.  This insures that the message
produces SPF PASS.  It also means that the FROM domain name has no
necessary dependence on any DNS entry.   It took me only one day to find
examples of this;,non-existent subdomains used on legitimate messages sent
by mailing services.  The FROM suffix correctly reflects the parent
organization, but the full email suffix does not appear in DNS.   This
situation means that we cannot distinguish between valid and invalid email
suffixes using DNS alone, we must require domain owner signalling.

How does a domain owner signal that @bounce.e.example.com is valid as a
FROM domain, even though the name is only used for mailing service
messages?    Under the current draft, the domain owner must associate the
name with an IP address using an MX, A, or SPF record, even though the name
has no legitimate connection to the chosen IP address.  I do not consider
this acceptable.   In the real world, I fear that implementing such a
requirement will have unexpected consequences, and network administrators
who share my fear will be reluctant to comply with our draft.

I focused on SP and NP because it is the SP or NP policy which provides
inheritance,  Inheritance has to be the primary way that we defend against
abuse of unused and non-existent email suffixes

You asked a lot of questions.   I think I should stop there and give you a
chance to respond before going further.

Doug Foster

On Mon, Jun 14, 2021 at 7:12 AM Alessandro Vesely <[email-masked]> wrote:

> domain
> required.
> record
> RFC5321.MailFrom

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 16 Jun 2021 13:33:53 +0200

On Tue 15/Jun/2021 01:19:03 +0200 Douglas Foster wrote:
> It took me only one day to find examples of this;,non-existent subdomains used 
> on legitimate messages sent by mailing services.  The FROM suffix correctly 
> reflects the parent organization, but the full email suffix does not appear in 
> DNS.

Me too.  I reviewed my logs for 2021 and got this:

88 NXDOMAIN found out of 160,473 messages:
35 bounces (empty mailfrom),
26 not found host in an existing suffix,
27 totally astray.

Except for bounces, which just reflect a poorly configured server, I wouldn't 
swear to their legitimacy.  For the few samples of which I still have the 
score, it was high.

However, to reject based just on NXDOMAIN is too harsh.

> This situation means that we cannot distinguish between valid and invalid
> email suffixes using DNS alone, we must require domain owner signalling.

I'd agree, but the idea of suggesting to signal such lack of registration over 
the DNS is to diabolically persist on an error.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 16 Jun 2021 12:01:08 -0400

>However, to reject based just on NXDOMAIN is too harsh.

I dunno, in my experience it's quite common, and if you do, the chances of losing a message you care
about are negligible.

In any event, this has nothing to do with DMARC.  If for some reason you want to do a DMARC evaluation
of a non-existent domain, you can use the organizational domain or I suppose PSD.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 16 Jun 2021 19:51:09 +0200

> I dunno, in my experience it's quite common, and if you do, the chances of losing a message you care

It's been customary to reject NXDOMAIN in smtp.mailfrom since when I recall it. 
  To reject NXDOMAIN in header.from is (was) an ADSP feature which doesn't seem 
to be very widespread.  DMARC dropped it a long time ago.

> of a non-existent domain, you can use the organizational domain or I suppose PSD.

It might make sense to reject that ~30% which doesn't even have an 
organizational domain (dubbed totally astray in my previous post).  But I still 
receive From: <[email-masked]> on a mailing list.  Rejecting that 
risks getting unsubscribed.  Perhaps mailing lists deserve a special permission...

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 16 Jun 2021 14:02:21 -0400

>risks getting unsubscribed.  Perhaps mailing lists deserve a special permission...

Or perhaps mailing lists should refrain from forwarding messages from cowards who
use fake addresses and don't sign their mail.

Either way, I still don't see what this has to do with DMARC.  Let's close ticket #112 and stop.

R's,
John

---

From: Dotzero <[email-masked]>
Date: Wed, 16 Jun 2021 14:28:22 -0400

> Either way, I still don't see what this has to do with DMARC.  Let's close

+1

Michael Hammer

---

From: Ken O'Driscoll <[email-masked]>
Date: Wed, 16 Jun 2021 19:41:35 +0000

+1

Ken.

________________________________
From: dmarc <[email-masked]> on behalf of John Levine <[email-masked]>
Sent: Wednesday, 16 June 2021, 19:02
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

R's,
John

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Douglas Foster <[email-masked]>
Date: Wed, 16 Jun 2021 17:43:08 -0400

You or the others seem to be confusing NXDOMAIN on RFC5321.MailFrom lookup
with NXDOMAIN on RFC5322.FROM.  The issues are very different.

NXDomain on the MailFrom lookup says neither the SPF policy nor the SMTP
domain exist, and therefore there is no reverse path.   Rejecting such
messages makes a lot of sense and, as has been said, has nothing to do with
DMARC.

NXDomain on RFC5322.From is a completely different issue.    It means that
the name is only used for service provider messaging, and is therefore not
linked to any IP address or other physical infrastructure.  It affects the
ability to define a meaningful NP test.   The issue becomes irrelevant to
DMARC if and only if we drop the NP policy idea completely.

The proposed MX/A/AAAA/SPF test has two significant problems:
- It incorrectly classifies some names as NP because they do not need
MX/A/AAAA/SPF records because they are not tied to an IP address, and we
have provided a very poor mechanism for a domain owner to come into
compliance.
- It incorrectly classifies some names that are not used for email as not
NP, simply because they have an A/AAAA record.   It provides no method for
the domain owner to signal that the name is not used for email and
therefore should be treated as NP.

With the expectation of significant errors in both directions, we do not
have a usable definition of NP.

Doug Foster

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Jun 2021 00:56:50 -0700

I continue to not understand the defect you're highlighting here.

I think you've expressed yourself primarily in the abstract.  Could you
craft a sample message, sample envelope, and sample DNS context that
highlights the problem you're talking about?  Maybe then it'll snap into
focus.

> have provided a very poor mechanism for a domain owner to come into

There's a workaround here: If I want to use a name that is not represented
in the DNS according to that test, all I need to do is DKIM sign with my
parent domain.  That makes "p" apply because now you have an aligned
"pass", which presumably trumps any "np" that's set.

If you aren't signing with DKIM in that scenario, and you obviously can't
pass SPF either, then you can't possibly hope to pass DMARC irrespective of
any test being done on the name's validity.

> therefore should be treated as NP.

If they're not used for email, then they're not in DMARC's problem space.

At any rate, since PSD has been approved, I'm hoping the experiment is
underway, or will be soon, and then we might have some actual data about
the severity of this defect and thus also possibly some hints about ways it
can be mitigated.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 17 Jun 2021 13:12:44 +0200

On Wed 16/Jun/2021 20:02:21 +0200 John Levine wrote:
> Let's close ticket #112 and stop.

I agree that the definition given in the PSD is clear enough:

    For DMARC purposes, a non-existent domain is a domain for which there
    is an NXDOMAIN or NODATA response for A, AAAA, and MX records.  This
    is a broader definition than that in [RFC8020].

However, by that definition a domain with a Null MX [RFC7505] is an existent 
domain for DMARC purposes.  Perhaps this apparent contradiction could be noted 
by adding a sentence somewhere, for example:

    Even though the bare existence of a domain does not entail that it can send
    or receive email, the presence or absence of the relevant DNS RRs determines
    which policy between sp= and np= is applicable.  If a DMARC record is found
    for a domain that would be non-existent by the above definition, the p=
    policy defined there is still the one to be applied.

Would that add clarity?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 17 Jun 2021 09:55:17 -0400

> domain for DMARC purposes.

True, but so what?  If you want to do a DMARC alignment check, you do it 
the same way as for any other domain.  For the umpteenth time, DMARC is 
not the magic anti-spam bullet, and you continue to use whatever other 
filtering methods you use.

> Would that add clarity?

No.  Let's close #112 and talk about something else.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Douglas Foster <[email-masked]>
Date: Thu, 17 Jun 2021 12:17:48 -0400

This is frustrating.   NP is a new design and the design issues should
have been discussed before we got to this point.   I don't know why so many
people are eager to not define the new technology.

There seems to be an unwillingness to acknowledge the current state of the
email ecosystem.  There seems to be a mythology that any email suffix used
with a mailing service must also exist elsewhere in the ecosystem as an
SMTP sender and receiver.   The MX/A/AAAA/.SPF seems to be based on this
myth.  There is no such necessity in the real world.

For a legitimate message, where a mailing service uses its own identity for
MailFrom and the client's identity for the From, the From address has very
few constraints:
- IETF format rules
- DMARC policy if present
- Mailing service business practices

On mailing service business practices:
I find that the major mailing services can be trusted to correctly present
the client organization.  But that does not include a requirement that the
email suffix has a separate identity as an SMTP sender and receiver.   My
data indicates that they will be happy to let @Example.Com send a message
from @EasterSale.Marketing.Example.com.

On DMARC policy
NP is only relevant if:
- The message does not authenticate.  DMARC PASS continues to be a final
result.
- A domain P policy does not apply.   P policies override SP and NP
policies.
- The SP policy is NONE and the NP policy is QUARANTINE or REJECT.   (If
the NP policy is the same as the SP policy, the result will be equivalent
to RFC7489 SP without NP.  If the NP policy is weaker than the SP policy,
the configuration is simply stupid.)

NP is an effort to partition the RFC 7489 SP=NONE result set, so that a
subset of all SP results can be blocked on some additional criteria.
This additional criterion could be based on non-existent as indicated by
NXDOMAIN, or it could be based on "not used for email" based on a criterion
to be defined.   Either approach needs to have a mechanism for
non-compliant names to be made compliant.   I believe that this should
involve a DNS entry, but the compliance measure should be specific to the
NP test.   Requiring that every FROM address be linked to an IP address
does not meet that requirement.

Doug Foster

Doug Foster

On Thu, Jun 17, 2021 at 3:57 AM Murray S. Kucherawy <[email-masked]>
wrote:

>> NXDomain on RFC5322.From is a completely different issue.    It means
>> that the name is only used for service provider messaging, and is therefore
>> not linked to any IP address or other physical infrastructure.  It affects
>> the ability to define a meaningful NP test.   The issue becomes irrelevant
>> to DMARC if and only if we drop the NP policy idea completely.
>>

---

From: Douglas Foster <[email-masked]>
Date: Thu, 17 Jun 2021 12:24:51 -0400

Yes, The test should most certainly define how MX="." and SPF="-ALL"
affect the test.  This is why I said that the test needs a more complete
definition, but many were unwilling to even address that part of the
problem.

Even with those modifications, the test is only applicable for names that
are also used for SMTP MAILFROM.   This does not cover all names that are
used for FROM.

I infer that the A/AAAA component is included in the test definition
because these might indicate an implicit MX.   The use of implicit MX is
unnecessary, and I suspect unlikely to be in use by DMARC-publishing
domains.    It would a minor compliance step to require domain owners to
replace implicit MX with explicit MX, so that the test will accurately
indicate names that are used for SMTP purposes.

Doug Foster

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Jun 2021 00:01:39 -0700

> people are eager to not define the new technology.

Please don't conflate "I still don't understand what you're talking about"
with "I am eager not to define NP" or "I am unwilling to acknowledge
(something)".  They're not the same thing, and only the former is true.

Your message continues to assert something abstract.  I'll repeat my
previous request:

Could you craft a sample message (including DKIM details), sample envelope,
and sample DNS context (including A, AAAA, MX, and SPF details) that
highlights the problem you're talking about?  Maybe then it'll snap into
focus.

> does not meet that requirement.

If I squint at this, maybe I can see what you're trying to argue: "
example.com" can't publish an "np" policy if they use a subdomain of "
example.com" that has no representation of any kind in the DNS.  Is that
correct?  If so, do you find this to be a defect, or simply a limitation to
be documented?  If you think it's a defect, why is that so?

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Tue, 22 Jun 2021 00:17:33 -0400

I am providing two types of examples:
1) A legitimate sender using a non-existent name,
2) An impersonating sender using undefended non-domain names.

Valid Message Example
===================

MailFrom:  [email-masked]
From:         [email-masked]
Signature: None
DMARC Policy:   Not currently configured.
SPF Status:   PASS
FROM Status:  NXDOMAIN

What happens when they implement DMARC?

One possibility is that they create a DKIM signature for
"scope1._domainkey. secure.hiltonheadislandsc.gov"   This ensures DMARC
PASS as long as the signature validates.

But if the message is modified in transit, the signature will no longer
validate.   Which policy should apply?   If the public key was successfully
retrieved, then the name certainly exists, and is used for DKIM signing, so
it should be SP.   But it does not yet meet the MX/A/AAAA/SPF test, so our
draft calls for it to be evaluated as NP.

To meet the MX/A/AAAA/SPF tests, the sender must create one of those four
DNS records.   But which one is relevant?   None of them.

Attack Scenario Examples
====================

Assume:  Example.com has DMARC policy of "p=reject, sp=none, np=none"

Also assume that "spammer.tld" decides it will be profitable to impersonate
example.com, and begins this data collection:

Research:
1. Spammer scans the example.com website, collecting host names.
2. Spammer performs MX and SPF lookups to collect additional host names.
3. Spammer performs DNS lookup on some other commonly-used names to see if
they exist.
4. Spammer notes that while "example.com" is protected by SPF and DMARC
p=reject, individual hosts do not have an SPF policy.

Strategy
Spammer does not want to risk being blocked by DMARC p=reject, so he will
not use "example.com" directly.
Spammer does not want to be blocked by SPF NXDOMAIN, so he will not use a
non-existent MAILFROM domain.
Spammer choses "mail.example.com" as the preferred impersonation domain.

Attack Scenario 1:  Spammer gets lucky, because the MX for "example.com" is
the host "mail.example.com".   Spammer has these options;

a) Pretend to be a mailing service, using spammer.tld as the SPF context:
MAILFROM=[email-masked]
FROM=[email-masked]
Sender authentication evaluates to SPF=PASS and DMARC policy SP applies.

Example.com has these sender-authentication defense options for this attack:
- Changing mail.example.com to a subdomain and creating a subdomain DMARC
P=reject/quarantine policy, or
- Changing the organization policy to sp=reject/quarantine

b) Pretend to be a direct message
MAILFROM=[email-masked]
FROM=[email-masked]
Sender authentication evaluates to SPF=NONE and DMARC policy SP applies.

Example.com has these sender-authentication defense options for this attack:
- Create an SPF "-ALL" policy for "mail.example.com"
- Changing mail.example.com to a subdomain and creating a subdomain DMARC
P=reject/quarantine policy, or
- Changing the organization policy to sp=reject/quarantine

================

Scenario 2:  Spammer notes that "mail.example.com" is not a defined host.
 Spammer has these options:

a) Pretend to be a mailing service, using spammer.tld as the SPF context:
MAILFROM=[email-masked]
FROM=[email-masked]
Sender authentication evaluates to SPF=PASS and DMARC policy NP applies.

Example.com has these sender-authentication defense options for this attack:
- Changing mail.example.com to a subdomain and creating a subdomain DMARC
P=reject/quarantine policy, or
- Changing the organization policy to sp=reject/quarantine

b) Pretend to be a mailing service, sent by a host in the target domain:
MAILFROM=[email-masked]
FROM=[email-masked]
Sender authentication evaluates to SPF=NONE and DMARC policy NP applies.

Example.com has these sender-authentication defense options for this attack:
- Create an SPF "-ALL" policy for "www.example.com", or
- Changing mail.example.com to a subdomain and creating a subdomain DMARC
P=reject/quarantine policy, or
- Changing the organization policy to sp=reject/quarantine, or
- Changing the organization policy to np=reject/quarantine