Subject: [dmarc-ietf] Evaluator reference model

From: Douglas Foster <[email-masked]>
Date: Sat, 15 Jan 2022 10:13:51 -0500

I was disappointed by the amount of resistance to my observations about
default policy.   Although it was suggested that the topic be shunted to a
Best Practices document, it left no expectation that such a document would
ever be written.   Besides, I find several reasons to object to the
objections.  But before returning to that detail, I want to do some
“Milestone Zero” work, and lay out some theory about how DMARC can be used
by evaluators to improve their email security.

DMARC Goal

The goal of DMARC is to help evaluators make correct disposition decisions,
so that safe and wanted messages are allowed while malicious and unwanted
messages are blocked.  It does this by identifying messages whose
identities are verified and distinguishes them from messages that are not
verified and therefore might be malicious impersonations.

At this point, it must be noted that the mailing list community perceives
DMARC as producing a reverse and perverse effect, causing safe and wanted
messages to be blocked.   I don’t see that those concerns have been
removed.   My assessment of that issue is at the end.

Evaluation Goal

Malicious messages come from malicious actors, so an evaluator’s goal is to
identify the actor who originates a malicious message, so that all messages
from that actor can be blocked.  When impersonation may be involved,
careful judgment is needed to determine which message identifiers represent
the malicious actor.

Even if an “ultimate DMARC” solution could perfectly distinguish between
malicious impersonation messages and all other mail, the evaluator is not
done.   The evaluator needs to block both impersonating and
non-impersonating messages that might come from that source in the future.

Authentication Methods

There are three classes of email authentication methods, General, Specific,
and Shared

DMARC is a “General” authentication method.   A sender ensures that his
message passes authentication by conforming the message to the evaluator’s
authentication algorithm.

Most local policies are an example of “Special” authentication methods.
The evaluator trusts a specific message flow, so he conforms the
authentication process to the characteristics of the wanted messages.  The
sender is not involved and therefore is unaware that special authentication
has been configured.

Shared authentication is a variant of Special authentication.   Because of
an existing trust relationship between sender and evaluator, the sender
helps define the characteristics of the message stream, the evaluator
implements custom authentication for those characteristics, and the sender
is aware of the accommodation.

Structure of Special Authentication Rules

When configuring a Special authentication rule, the evaluator should still
be concerned about spoofing.  Therefore, a special authentication rule
should include one or more message identifiers that are received together,
as well as successful validation of at least one identifier which will
ensure that the entire set can be trusted.

Here are some of the message attributes from which an evaluator could
select when creating a DMARC-overriding special authentication rule for the
mailing list “[email-masked]”:

·         SMTP “MAIL FROM” address of [email-masked] with
SPF PASS.

·         LIST-ID address of [email-masked]

·         HELO or Reverse DNS name ending with “example.com” and forward
confirmed to the Source IP.

·         Source IP matches a special value or list.

Notably, the RFC5322.From address does not need to be part of the rule,
since the evaluator wants to accept list messages from all subscribers.
More on this later.

In the general case, the actual filter values are inferred from received
messages.  The complexity of the match rule is determined by the
evaluator’s risk perception and the limitations of what can be configured
in his filtering software.  Many existing products lack the ability to
create a rule which includes multiple attributes and a verification state,
rendering them unable to create appropriate rules for special
authentication.

SPF Overrides

The same concept should be applied when creating a special authentication
rule to override an SPF problem.   In most cases, the evaluator will not be
able to know or maintain a list of valid IP addresses, so the override rule
needs to be based on the server domain name:

·         SMTP “MAIL FROM” address has a specific domain name.

·         HELO or Reverse DNS names have a specific domain name and can be
forward-confirmed to the Source IP.

Although the Reverse DNS name may indicate the ISP organization, it often
indicates the server organization.  When either host name represents the
server organization and can be forward confirmed, the result is suitable
for a test of this type.

As with DMARC overrides, many existing products are unable to configure a
rule with these features.

Unverifiable Message Sources

Most verification problems occur when the RFC5321.MailFrom domain and the
RFC5322.From domain are not aligned.   These messages generally arrive from
submitting MTAs that handle messages for many domains.   These include:

-          Email Service Providers:   The client organization is indicated
in the RFC5322.From address and the ESP organization is indicated by the
RFC5321.MailFrom address.

-          Mailing Lists:  The subscriber is indicated in the RFC5322.From
address and the List organization is indicated by the RFC5321.MailFrom
address.

-          Forwarders:    The original message RFC5322.From address is
unchanged, while the RFC5321.MailFrom address may (or may not) be rewritten
to ensure SPF compliance.   If SRS encoding is used for the rewrite, the
evaluator may be able to infer the original SMTP address by reversing the
encoding.

-          Various other entities act on behalf of individual email account
owners from multiple domains.

When considering whether to create a special authentication rule for these
submitters, the critical issue is how much trust the evaluator places in
the submitting MTA.  A prerequisite assumption is that the evaluator trusts
the submitter to not introduce malicious content.   Beyond that, the levels
of trust are:

-          The submitting MTA has fully vetted the RFC5322.From address by
a reliable process, although not necessarily via DMARC, and therefore
re-verification is not required.

o   Legitimate ESPs are expected to validate their clients during account
setup, and then validate submissions using login mechanisms.

o   Mailing lists are expected to validate their subscribers during
enrollment, and then validate posts using DMARC or reconfirm messages.

o   Some forwarders may apply satisfactory sender authentication processes
and therefore qualify for this level of trust.

o   Websites and other entities acting on behalf of individual email
accounts will have used login or other authentication to also justify this
level of trust.

-          The submitting MTA has not vetted the RFC5322.From address to
the level required by the evaluator, and therefore evaluation must be
repeated.  This most commonly occurs with forwarding services.  ARC is
useful in this situation, if a DKIM signature verification state has been
lost in transit.

When the evaluator trusts that the sender performs adequate RFC5322.From
authentication, the specific value of the RFC5322.From domain does not
matter.  The special authentication rule can often be as simple as “SMTP
MAIL FROM domain is <value> and the SPF status is PASS.”

This is an appropriate point to highlight the difference between identity
trust and message trust.   An ESP may send messages on behalf of a
malicious client organization, or a mailing list may forward a post from an
infected subscriber account.   Special authentication rules which override
authentication tests should not necessarily be used to override identifier
reputation checks or content filtering checks.

Submitter Accommodation measures

A forwarding MTA can ensure sender authentication by writing the SMTP
MailFrom address to ensure SPF PASS or rewriting the RFC5322.From address
to ensure DMARC PASS.   Rewriting of the RFC5321.MailFrom address may
inhibit the evaluator from correctly assessing reputation of the message
originator.   Rewriting of the RFC5322.From address will confuse the user
interface and is widely disparaged.

Mailing List negative outcomes

Mailing Lists are often trusted and therefore eligible for special
authentication.   However, the list owner may not know that the list is
trusted or may not be able to adapt the MLM software to benefit from the
evaluator’s trust.   This leads to a worst-case outcome:   The list
performs From-munging to ensure DMARC compliance, even though the recipient
does not want From-munging and the recipient’s evaluation system does not
require From-munging.

Because in-transit modifications could be used to misrepresent the author
or used to introduce malicious content, there is no conceivable General
authentication method that could authorize mailing lists to modify
content.   Any accommodation to trust an in-transit modification must be
based on special authentication.

Consequently, any solution to the mailing list problem must involve Shared
authentication:

-          The list documents the accommodation that will need to avoid
From-munging,

-          the evaluator implements that accommodation and notifies the
list, and

-          the list suppresses From-munging for destinations that have
configured special authentication.

ARC fails for this purpose because (a) the list owner does not know if ARC
information will be used to grant a special authentication, and (b) the ARC
information is unnecessary if the mailing list is already trusted to
implement good business practices to prevent impostor postings or
non-subscriber postings.

However, mailing lists are ideally suited for shared authentication through
the subscriber enrollment process.   As part of the subscription, the
provider is directed to ask for special authentication from his email
filtering organization.  Because the subscriber is carrying the request
forward, the request will be considered properly sponsored.   If the
special authentication is granted and the result communicated back into the
subscriber profile, then From-munging can be avoided for that subscriber.
   The final requirement is for MLM software that can perform conditional
From-munging.  In the absence of that feature, senders may be able to
configure a post-processing MTA to conditionally alter From-munging after
the message leaves the MLM.

Doug Foster

---

From: Todd Herr <[email-masked]>
Date: Tue, 18 Jan 2022 08:51:17 -0500

On Sat, Jan 15, 2022 at 10:14 AM Douglas Foster <
[email-masked]> wrote:

>
> DMARC Goal
>
> The goal of DMARC is to help evaluators make correct disposition
> decisions, so that safe and wanted messages are allowed while malicious and
> unwanted messages are blocked.  It does this by identifying messages whose
> I don't agree with the goal statement here, because it implies to me that
all messages that pass DMARC validation are safe and wanted, while all
messages that do not pass DMARC validation are malicious, and neither
statement is true.

Let me provide, in quotes from the Abstract and Introduction sections of
the current rev of DMARCbis, an alternate viewpoint:

   DMARC permits the owner of an email author's domain name to enable
   verification of the domain's use, to indicate the Domain Owner's or
   Public Suffix Operator's message handling preference regarding failed
   verification, and to request reports about use of the domain name.
   Mail receiving organizations can use this information when evaluating
   handling choices for incoming mail.

   A DMARC pass indicates only that the RFC5322.From domain has been
   authenticated for that message.  Authentication does not carry an
   explicit or implicit value assertion about that message or about the
   Domain Owner.  Furthermore, a mail-receiving organization that
   performs DMARC verification can choose to honor the Domain Owner's
   requested message handling for authentication failures, but it is
   under no obligation to do so; it might choose different actions
   entirely.

   For a mail-receiving organization supporting DMARC, a message that
   passes verification is part of a message stream that is reliably
   associated with the RFC5322.From field Domain Owner.  Therefore,
   reputation assessment of that stream by the mail-receiving
   organization is not encumbered by accounting for unauthorized use of
   that domain in the RFC5322.From field.  A message that fails this
   verification is not necessarily associated with the Domain Owner's
   domain and its reputation.

Those three paragraphs can be boiled down to "DMARC is the way to
ascertain if usage of the domain in the RFC5322.From header was
authorized for that message by the domain owner." That's it; no more
and no less.

Is authorized usage a sure indicator that mail was wanted? Nope.
Spammers can publish DMARC policy records and get pass verdicts on
their messages in the same way that criminals can carry drivers
licenses that prove their identity.

Does authorized usage ensure delivery to the Inbox? Absolutely not.
Lots of people in the industry will make claims that DMARC can
increase deliverability, but it takes a whole lot more than just DMARC
pass to get to the inbox. DMARC allows the domain owner to get proper
credit from the mail receiver for doing all the other things right, or
to get proper blame from the mail receiver for doing all the other
things wrong. Some might even say DMARC gets you the deliverability
that you deserve.

Is unauthorized usage a sure indicator that mail was unwanted? Again,
nope. Lots of legit senders haven't yet fully deployed authentication
across their entire infrastructure or might have a glitch somewhere in
their mail streams, and either case can cause messages to fail DMARC
validation checks. A great way for those domain owners to evaluate
their deployment and find gaps that need to be addressed is for them
to publish a DMARC policy record with p=none and rua tag pointing to a
mailbox that they actively monitor; the reports will uncover those
streams that are missing authentication, and the domain owner can
address those problems before eventually leveling up to p=quarantine
or p=reject. I don't know that this was intended by those who first
developed the DMARC spec, but for my money DMARC is the best tool out
there for a domain owner to judge their readiness to deploy DMARC in a
meaningful way.

Does unauthorized usage mean that a message will be rejected? Not
necessarily, and not even if the domain owner publishes a policy with
p=reject. My spam folder associated with my Gmail account contains
messages claiming to be from domains that publish a policy of
p=reject, and these messages failed DMARC validation, but Gmail did
not reject them. Their network, their rules.

My point here is that DMARC is but one tool in a much larger toolbox.
When fully deployed for a domain, it's intended to stop unauthorized
usage of that domain in the RFC5322.From header. Authorized usages of
the domain might be for good, or they might be for evil, and DMARC is
just one data point that an evaluator has to make the final
interpretation of the domain owner's intent.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*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.

---

From: Douglas Foster <[email-masked]>
Date: Tue, 18 Jan 2022 09:35:58 -0500

I entirely agree that the DMARC result is different from the
wanted/unwanted result.   If my opening failed to convey that, it was not
intentional.   My real point was that DMARC is, or should be, for the
benefit of the evaluator.

Specifically, I have trouble with the language about "Domain owners enable
verification...", because it implies that DMARC is controlled by, and
consequently for the benefit of, the domain owner.

The evaluator does not need the domain owner's permission to use publicly
available information to assess whether a particular message is or is not
accurately identified.   After doing so, the evaluator does not need the
domain owner's permission (in the form of p=reject) to block messages which
he determines to use malicious impersonation.

Domain owner control, if it was ever there, has been demolished by the tree
walk.  Every message will have a DMARC policy applied.  This new workload
may have some performance impact on evaluators, so it deserves a passing
mention.

I thought it curious that my default policy comment received so much
resistance, because it was really targeting the transition period when the
PSL still has some use..   Once the PSD policies are deployed,
evaluator-supplied default policies will never be activated, but the PSD
policies will produce the same result..

The perspective that the domain owner is in control also appears in the
latent assumption that a NONE policy is useless to the evaluator,
contributing only overhead (if reporting is done) but doing nothing to help
with message disposition.   I have tried to explain in some detail why NONE
is no obstacle to an intelligent evaluator.    In many respects, DMARC is
two policies, one for computing PASS and one for obtaining suggestions for
handling FAIL.   The extended discussion about mailing lists convinced me
that even the disposition suggestions in DMARC are not very useful.

DF

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jan 2022 06:49:23 -0800

On 1/18/2022 5:51 AM, Todd Herr wrote:
> I don't agree with the goal statement here, because it implies to me 
> that all messages that pass DMARC validation are safe and wanted, 
> while all messages that do not pass DMARC validation are malicious, 
> and neither statement is true.
>
> Let me provide, in quotes from the Abstract and Introduction sections 
> of the current rev of DMARCbis, an alternate viewpoint:

+1

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]

---

From: Todd Herr <[email-masked]>
Date: Tue, 18 Jan 2022 10:33:52 -0500

> consequently for the benefit of, the domain owner.

RFC 7489 and DMARCbis both say that if a policy record is not discovered,
then "Mail Receivers SHOULD NOT apply the DMARC mechanism to the message."
The domain owner is always subject to the rules and policies of the mail
receiver, regardless of whether or not a DMARC policy is published, but a
domain owner does have the ability to exert some control over whether or
not the DMARC mechanism is applied to any message using its domain. The
domain owner has no control over how the results of that DMARC mechanism
application are used, but it does have the ability to express an opinion or
preference on what should be done if the message fails a DMARC mechanism
check.

> he determines to use malicious impersonation.

This is true, but any mail receiver applying a DMARC mechanism to a message
for which no DMARC policy exists isn't really following the DMARC protocol.

>
> Domain owner control, if it was ever there, has been demolished by the
> tree walk.  Every message will have a DMARC policy applied.  This new
> workload may have some performance impact on evaluators, so it deserves a
> passing mention.
>
>
I don't know that "demolished" is a word I'd agree with. As a domain owner,
I can publish a DMARC policy record for my organizational domain and have
full control over the DMARC policies that exist for any subdomain, existing
or not, of that organizational domain, and the tree walk would stop with my
organizational domain.

The tree walk is, I believe, intended to allow for a policy published at
b.domain.tld to apply to messages using a.b.domain.tld in the RFC5322.From
domain. With RFC 7489, we don't have that, because b.domain.tld's DMARC
policy is never queried for during the policy discovery process. Only
_dmarc.a.b.domain.tld and _dmarc.domain.tld are queried for under the
current RFC.

If the intent of the tree walk is, at least in part, to allow for
publishing of policy records at the PSD level and for those records to be
inherited by existing subdomains (e.g., _dmarc.tld is inherited by
domain.tld if domain.tld does not publish its own policy record) then I
have badly misunderstood the tree walk. If that's not the intent, then the
next rev of DMARCbis needs to make that more clear.

> that even the disposition suggestions in DMARC are not very useful.
A policy of "none" isn't useless to an evaluator; it's communicating to the
evaluator that the domain owner isn't yet confident that all mail sent
using its domain in the RFC5322.From header is properly authenticated, and
so messages that fail the DMARC mechanism check should not be automatically
assumed to be unauthorized. I would expect an intelligent evaluator to use
the data point resulting from a fail with p=none differently and/or to
attach less significance to such a verdict than a fail with p=quarantine or
p=reject. I would further expect an intelligent evaluator to not apply the
DMARC mechanism to messages for which no policy was discovered, but if they
did, I would expect them to generally give little if any weight to the
results because they should have no expectation that the message should
pass the DMARC mechanism check, because the domain owner has given no
indication that it's authenticating mail in a way that might generate a
pass. Perhaps an intelligent evaluator with essentially unlimited resources
would have data available to them that tracked all possible combinations of
sources, paths, and domains used for SPF, DKIM, and RFC5322.From to have
established a common thread for which combinations tend to pass DMARC and
which don't, but that seems like a lot of work to me.

--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 18 Jan 2022 11:37:43 -0500

"Demolish" should have been limited to the notion that a domain owner has a
"right" to not be DMARC-evaluated, because he has not published a policy.
 With tree walk, every message will have either a domain-published policy
or a PSD policy.

A message asking for entrance to my network has NO rights.   The only
reason to omit DMARC evaluation of a message is because it is not in the
interest of the evaluator to do so.  That situation has not been
demonstrated.  The RFCs cannot expect evaluators to act contrary to their
interest to comply with a document.

Maybe I am too much of an outlier.   I don't see DMARC as useful for
automatically blocking messages, so I don't try.   I have noted previously
that if sender authentication failure is deterrminative,for a message, the
risk is fairly low because it has passed sender reputation and content
filtering.   My FAIL messages are allowed or quarantined, then reviewed
after-the-fact.   Local policies are updated to block unwanted senders and
authorize the wanted senders.  It is always about identifying the unwanted
and malicious senders, not single messages, and it has been working quite
well.

df

On Tue, Jan 18, 2022 at 10:34 AM Todd Herr <todd.herr=
[email-masked]> wrote:

>> Specifically, I have trouble with the language about "Domain owners
>> enable verification...", because it implies that DMARC is controlled by,
>> and consequently for the benefit of, the domain owner.
>>
>
> This is true, but any mail receiver applying a DMARC mechanism to a
> message for which no DMARC policy exists isn't really following the DMARC
> protocol.
>
>>
> I don't know that "demolished" is a word I'd agree with. As a domain
> owner, I can publish a DMARC policy record for my organizational domain and
> have full control over the DMARC policies that exist for any subdomain,
> existing or not, of that organizational domain, and the tree walk would
> stop with my organizational domain.
>
> A policy of "none" isn't useless to an evaluator; it's communicating to
> the evaluator that the domain owner isn't yet confident that all mail sent
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Todd Herr <[email-masked]>
Date: Tue, 18 Jan 2022 11:49:29 -0500

On Tue, Jan 18, 2022 at 11:38 AM Douglas Foster <
[email-masked]> wrote:

> "Demolish" should have been limited to the notion that a domain owner has
> a "right" to not be DMARC-evaluated, because he has not published a
> policy.   With tree walk, every message will have either a domain-published
> policy or a PSD policy.
>

I'm not asserting that a message has any rights to enter your network. I'm
a firm believer in the concept of "your network, your rules".

If you have a rule that you will apply the DMARC mechanism regardless of
whether or not a DMARC policy exists for a domain, then you are seemingly
implementing a policy of "no auth, no entry" (and you are well within your
rights to do so) but you are not following the DMARC protocol when doing so.
--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 18 Jan 2022 11:57:36 -0500

Why should the protocol provide a carve-out for non-participating domains?

Similarly, if the carve-out is really important, what are we to do about
PSD policies, since they take away the carve-out.?   I suppose we could
create a clause for PSD policies to say sp="NoCheck", but we have not yet
done so, and I don't think that we should.

Doug

---

From: "John Levine" <[email-masked]>
Date: 18 Jan 2022 12:01:44 -0500

It appears that Dave Crocker  <[email-masked]> said:
>-=-=-=-=-=-

Agreed.  The current text is fine, Doug's proposal is not.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Jan 2022 12:04:21 -0500

The point of DMARC is to allow sending domains to specify a policy to apply
to unauthenticated mail that purports to be from them.  In that sense,
DMARC is for the senders.

If a receiving domain wants to use DMARC in its decision process, outside
what the purported sending domain says, that's, as Todd says, its choice,
but is outside of the intent, and therefor the specification, of DMARC.

Barry

On Tue, Jan 18, 2022 at 11:58 AM Douglas Foster <
[email-masked]> wrote:

>>> "Demolish" should have been limited to the notion that a domain owner
>>> has a "right" to not be DMARC-evaluated, because he has not published a
>> I'm not asserting that a message has any rights to enter your network.
>> I'm a firm believer in the concept of "your network, your rules".
>>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jan 2022 09:05:14 -0800

On 1/18/2022 7:33 AM, Todd Herr wrote:
> On Tue, Jan 18, 2022 at 9:36 AM Douglas Foster 
> <[email-masked]> wrote:
>
>     wanted/unwanted result.   If my opening failed to convey that, it
>     was not intentional.   My real point was that DMARC is, or should
>     be, for the benefit of the evaluator.
>
>     Specifically, I have trouble with the language about "Domain
>     owners enable verification...", because it implies that DMARC is
>     controlled by, and consequently for the benefit of, the domain owner.
>
>
> RFC 7489 and DMARCbis both say that if a policy record is not 
> discovered, then "Mail Receivers SHOULD NOT apply the DMARC mechanism 
> to the message."

Forgive me, but there is a simpler point here.

1. "enables" does not "imply" control; it asserts it quite plainly.

2. The claim of implying to benefit only to the domain owner is simply 
incorrect.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jan 2022 09:08:39 -0800

On 1/18/2022 9:04 AM, Barry Leiba wrote:
>
> If a receiving domain wants to use DMARC in its decision process, 
> outside what the purported sending domain says, that's, as Todd says, 
> its choice, but is outside of the intent, and therefor the 
> specification, of DMARC.

Ahem.  A mechanism that includes a domain owner's being able to suggest 
disposition handling by a receiver makes the implication of benefit to 
the receiver explicit, rather than outside of the intent.

What is outside the intent is any 'requirement' of compliance by the 
receiver.

(But to riff on this a bit:  One can imagine some tortured logic where 
the tossing or marginalizing of some mail by the receiver is only 
beneficial to the domain owner, but I'll claim it fails on the pragmatics.)

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Jan 2022 12:11:46 -0500

I think what's *also* outside the intent is for the receiver to infer
anything in absence of any statement by the domain owner.  Do you
disagree with that?

Barry

---

From: Todd Herr <[email-masked]>
Date: Tue, 18 Jan 2022 12:12:52 -0500

> Why should the protocol provide a carve-out for non-participating domains?

I don't see a "carve-out". If a domain doesn't publish a DMARC policy
record, that's one less thing that a mail receiver has to do during the
transaction for that message (which might matter for large scale providers
who receive tens if not hundreds of millions of messages per day) and one
less data point in the domain owner's favor that might be used by the
receiver when making its handling decision.

Put more simply, no DMARC policy record does not help the domain owner at
all, but not performing the DMARC mechanism check *might* help the
receiving domain.

--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jan 2022 09:21:48 -0800

On 1/18/2022 9:11 AM, Barry Leiba wrote:
> I think what's*also*  outside the intent is for the receiver to infer

Heck no.

Since there is nothing in DMARC that mandates that it be used, and 
nothing normative that specifications the 'conditions' 'intent' about 
when it /is/ used, then inferring anything by its absence is quite 
literally outside the scope of DMARC specification.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dotzero <[email-masked]>
Date: Tue, 18 Jan 2022 12:29:49 -0500

> Why should the protocol provide a carve-out for non-participating domains?

I would think that  "non-participating domains" would be self explanatory.
Non-participating is a choice not to participate, not a carve out. IETF
standards are about interoperability (2 or more parties that choose to
participate). IETF standards are not about one party forcing another party
to participate involuntarily or clubbing them into submission.

> done so, and I don't think that we should.

There is no "carve-out"
.
Michael Hammer

---

From: Douglas Foster <[email-masked]>
Date: Tue, 18 Jan 2022 13:13:17 -0500

Michael, you ducked the question.

If a domain owner has a right to not participate in DMARC, why are we
removing that right with PSD policies?

Either participation is optional or it is not.    Which is it?

This right to not participate is based on an assumption that DMARC will be
used to block legitimate traffic.   That fear is only justified because we
have been unwilling to document how DMARC should be used to ensure
appropriate dispositions.    Failure to talk about failure management has
created the problem and we seem determined to perpetuate it (even though
failure management, as applied to mailing lists, was part of our charter.)

Doug

---

From: Todd Herr <[email-masked]>
Date: Tue, 18 Jan 2022 13:25:17 -0500

> removing that right with PSD policies?

I said in an earlier message in this thread that I did not understand the
tree walk to mean that PSD policies will rule if the org domain doesn't
publish one. Here's what I wrote:

One of us is wrong in our understanding of the point of the tree walk, and
it very well could be me, but I think we need to get consensus here on this
point.

> failure management, as applied to mailing lists, was part of our charter.)
I submit that DMARCbis does say how DMARC should be used to ensure
appropriate dispositions, in the Introduction section:

domain and its reputation

--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 18 Jan 2022 15:26:31 -0500

Alas, there is no convincing this group, but the missed opportunity is so
great:.   By testing every message, I learn that 81% of domains and 93% of
messages are able to authenticate using DMARC rules.   (Statistics taken
after sender reputation blocks have excluded the known offenders.)
 Compare that to the 5% of domains that have any DMARC policy, and the tiny
subset of those that are enforceable.

DF

On Tue, Jan 18, 2022 at 1:25 PM Todd Herr <todd.herr=
[email-masked]> wrote:

>> This right to not participate is based on an assumption that DMARC will
>> be used to block legitimate traffic.   That fear is only justified because
>> we have been unwilling to document how DMARC should be used to ensure
>    verification is not necessarily associated with the Domain Owner's domain and its reputation
>
>
> --
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Jan 2022 15:38:19 -0500

Maybe I'm misunderstanding what you mean by "testing every message",
so let me ask it this way:

- A message says it's from [email-masked]
- If you can authenticate that through DKIM or SPF, you have an
authenticated message from gloob.example.com.  What do you do next,
and how does that relate to what DMARC specifies?
- If you can NOT authenticate that through DKIM nor SPF, DMARC says
you should look for a DMARC policy for gloob.example.com.  I presume
you look for one, yes?
- If you find a policy, DMARC would have you follow it.  Do you?
- If you do not find a policy, we're now outside the scope of current
DMARC.  What do you do now?

Maybe if we're misunderstanding this and you clarify it, some of us
might agree with you, so let's please try.

Barry

On Tue, Jan 18, 2022 at 3:27 PM Douglas Foster
<[email-masked]> wrote:
>
> Alas, there is no convincing this group, but the missed opportunity is so great:.   By testing every message, I learn that 81% of domains and 93% of messages are able to authenticate using DMARC rules.   (Statistics taken after sender reputation blocks have excluded the known offenders.)   Compare that to the 5% of domains that have any DMARC policy, and the tiny subset of those that are enforceable.
>
> DF
>
> On Tue, Jan 18, 2022 at 1:25 PM Todd Herr <todd.herr=[email-masked]> wrote:
>>
>> On Tue, Jan 18, 2022 at 1:13 PM Douglas Foster <[email-masked]> wrote:
>>>
>>> If a domain owner has a right to not participate in DMARC, why are we removing that right with PSD policies?
>>
>>
>> I said in an earlier message in this thread that I did not understand the tree walk to mean that PSD policies will rule if the org domain doesn't publish one. Here's what I wrote:
>>
>> If the intent of the tree walk is, at least in part, to allow for publishing of policy records at the PSD level and for those records to be inherited by existing subdomains (e.g., _dmarc.tld is inherited by domain.tld if domain.tld does not publish its own policy record) then I have badly misunderstood the tree walk. If that's not the intent, then the next rev of DMARCbis needs to make that more clear.
>>
>>
>> One of us is wrong in our understanding of the point of the tree walk, and it very well could be me, but I think we need to get consensus here on this point.
>>>
>>>
>>> This right to not participate is based on an assumption that DMARC will be used to block legitimate traffic.   That fear is only justified because we have been unwilling to document how DMARC should be used to ensure appropriate dispositions.    Failure to talk about failure management has created the problem and we seem determined to perpetuate it (even though failure management, as applied to mailing lists, was part of our charter.)
>>>
>>
>> I submit that DMARCbis does say how DMARC should be used to ensure appropriate dispositions, in the Introduction section:
>>
>> Todd Herr | Technical Director, Standards and Ecosystem
>> e: [email-masked]
>> 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.
>>

---

From: "John Levine" <[email-masked]>
Date: 18 Jan 2022 16:16:57 -0500

It appears that Todd Herr  <[email-masked]> said:
>have badly misunderstood the tree walk. 

The whole point of a PSD is to have a default policy for parts of the
DNS tree where the superdomain has a relationship that lets it define
policies for its registrants. The examples we've seen are the UK
government which has a PSD for gov.uk, and the proposal to have one
for .bank, which has all sorts of rules like you have to be a real
bank.

If you were doing a tree walk and the first DMARC record you find is
a PSD, that's the policy you use.  Why wouldn't you?

I might look at the PSD flag to decide whether to send reports, but
not whether to believe that it's the policy.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Jan 2022 16:31:11 -0500

> not whether to believe that it's the policy.

Yes.  Based on what's written in DMARCbis 04, if the first policy you hit was a 
PSD policy, that's what you should use.  The psd tag in the record is relevant 
for determining organizational alignment, not policy discovery.

Scott K

---

From: Todd Herr <[email-masked]>
Date: Tue, 18 Jan 2022 16:31:53 -0500

> not whether to believe that it's the policy.
Yeah, I spent some time reading RFC 9091 this afternoon, and along with
your reply here it clarified for me the point of the PSD.

Specifically https://datatracker.ietf.org/doc/html/rfc9091#section-1.2

1.2 <https://datatracker.ietf.org/doc/html/rfc9091#section-1.2>.  Discussion

   This document provides a simple extension to [RFC7489
<https://datatracker.ietf.org/doc/html/rfc7489>] to allow
   operators of Public Suffix Domains (PSDs) to:

   *  Express policy at the level of the PSD that covers all
      Organizational Domains that do not explicitly publish DMARC
      records

   *  Extend the DMARC policy query functionality to detect and process
      such a policy

   *  Describe receiver feedback for such policies

   *  Provide controls to mitigate potential privacy considerations
      associated with this extension

--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 18 Jan 2022 17:08:31 -0500

I test every message for SPF, aligned SPF, and aligned verified DKIM.
 With one exception mentioned below, I don't block on FAIL, but I do
collect data.

Most legitimate messages produce at least SPF, many messages have DKIM
signatures.  I receive very little forwarded mail.  So most messages pass
DMARC tests naturally.  Then I tailor my local policies to reflect my
message stream,

For example, I trust ConstantContact and SendGrid to present accurate
identification of their clients.   They get a local policy which says
everything they send counts as equivalent to DMARC PASS, whether signed or
not.   This approach solves the Girl Scout troop mass mailing problem that
John raised a long time ago.  Those types of filter rules add another 1% of
domains and 2% of messages to the PASS category.

Note that I trust SendGrid identities, not their clients.   Any new domain
arriving from SendGrid goes to Quarantine until I flag it as allowed or
blocked.

We have very little legitimate traffic from EDU domains, so when I saw a
pattern of EDU impersonators, I added a rule to require PASS for *.EDU.

After applying these edits, I have a bunch of stuff that is still FAIL.
 It has a high percentage of spam or all types.   Periodically I do a log
review and identify some domains and servers that need to be blocked, as
well as some domains that need a special authentication rule so that I will
not need to investigate the same identity issue again.

I cannot imagine why I would give this up to only evaluate the domains that
have given me permission via a DMARC policy.  I think documenting this
approach would help a lot of other evaluators and software developers.

I get angry at products that think DMARC is a checkbox that you turn on or
off -- just follow the RFC and block the FAILS.   It doesn't work in
reality, but it allows them to say that the product does DMARC.   I assume
a lot of ransomware attacks could be prevented if the product vendors
understood the DMARC potential.

Doug

On Tue, Jan 18, 2022 at 3:38 PM Barry Leiba <[email-masked]> wrote:

> > Alas, there is no convincing this group, but the missed opportunity is
> so great:.   By testing every message, I learn that 81% of domains and 93%
> of messages are able to authenticate using DMARC rules.   (Statistics taken
> >> I said in an earlier message in this thread that I did not understand
> the tree walk to mean that PSD policies will rule if the org domain doesn't
> >> One of us is wrong in our understanding of the point of the tree walk,
> and it very well could be me, but I think we need to get consensus here on
> this point.
> >>>
> >>>
> >>> This right to not participate is based on an assumption that DMARC
> will be used to block legitimate traffic.   That fear is only justified
> because we have been unwilling to document how DMARC should be used to
> ensure appropriate dispositions.    Failure to talk about failure
> management has created the problem and we seem determined to perpetuate it
> (even though failure management, as applied to mailing lists, was part of
> our charter.)
> >>>
> >>
> >> This email and all data transmitted with it contains confidential
> and/or proprietary information intended solely for the use of individual(s)

---

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Jan 2022 17:33:08 -0500

First: I note that you did not answer my direct questions.  Please
consider that when you see that people aren't understanding you.

> I test every message for SPF, aligned SPF, and aligned verified DKIM.   With one exception mentioned below,
> I don't block on FAIL, but I do collect data.
...
> I cannot imagine why I would give this up to only evaluate the domains that have given me permission via a
> DMARC policy.

And here's where we have the disconnect:
No one is suggesting that you should not do anything you find useful
with the data you collect: no one wants you to give anything up.  All
we are saying is that when a domain owner does not publish a DMARC
policy, anything you choose to do is outside of the DMARC spec,
because DMARC is about the policies that domain owners publish.

> I think documenting this approach would help a lot of other evaluators and software developers.

An informational document that suggests collecting data they way
you're doing it, and documents things you can do with that data...
would be a fine thing to write.  You may, of course, do so, publish it
as an Internet draft, and see if there's agreement to publish it
through the IETF.  Lacking that, you might get it published through
the Independent stream.

In any case, I don't see that it has anything to do with the DMARC
protocol spec that we're working on now.

Barry

---

From: Douglas Foster <[email-masked]>
Date: Tue, 18 Jan 2022 17:44:34 -0500

You could declare that "DMARCv1 psd=y np=reject" is a valid policy, that
psd=y implies p=reject but is not inherited, so that sp result is "do not
check".

I think this is what you want.

On Tue, Jan 18, 2022 at 4:32 PM Todd Herr <todd.herr=
[email-masked]> wrote:

>    This document provides a simple extension to [RFC7489 <https://datatracker.ietf.org/doc/html/rfc7489>] to allow

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Jan 2022 18:39:14 -0500

No.  That's not how DMARC records work and there's no reason to make psd=y 
mean anything other than "don't use this domain when evaluating alignment".

Scott K

On Tuesday, January 18, 2022 5:44:34 PM EST Douglas Foster wrote:
> > 1.2 <https://datatracker.ietf.org/doc/html/rfc9091#section-1.2>. 
> > Discussion> 
> >    <https://datatracker.ietf.org/doc/html/rfc7489>] to allow operators of
> >    Public Suffix Domains (PSDs) to:
> >

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 Jan 2022 11:49:49 +0100

On Tue 18/Jan/2022 16:33:52 +0100 Todd Herr wrote:
> evaluator that the domain owner isn't yet confident that all mail sent using 
> its domain in the RFC5322.From header is properly authenticated, and so 
> messages that fail the DMARC mechanism check should not be automatically 
> assumed to be unauthorized.

Yes, p=none can mean that.  Or it can mean that the domain owner, despite being 
below a PSD which imposes DMARC hard policies, doesn't want to participate at 
all.  Or it can mean that a relevant percentage of the domain's mail traffic 
goes through mailing lists; hence, although all mail sent using its domain in 
the RFC5322.From header is properly authenticated at the first hop, it would be 
misleading to assert a hard policy in general.

We're overloading p=none with too many meanings.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Wed, 19 Jan 2022 08:25:43 -0500

I have been trying to understand why such a big disconnect is possible
between my usage of DMARC data and the standard one.   I have concluded
that it occurs because we are dealing with two protocols, not one, and the
standard view conflates them unnecessarily.   The first protocol is the
algorithm for detecting DMARC PASS, and the second protocol is the
algorithm for handling DMARC FAIL.

DMARC PASS is trusted to indicate that the message is from the domain owner
because of the nature of DNS record ownership – the message is reliably
tied to a DNS record, and the DNS record is reliably tied to the domain
owner.   There is no secondary authentication which is required to make
DKIM PASS  or SPF PASS authenticate the domain’s messages; the
authentication is inherently triggered by publishing SPF or DKIM
information.    Therefore the DMARC PASS protocol is a datagram service,
like SPF and ARC.   All three use a one-way flow of information from the
domain owner to the evaluator via DNS.

The DMARC FAIL protocol is different.   Once a message is determined to not
pass the DMARC PASS protocol, the domain owner is queried to answer the
question, “What is the probability your messages are always authenticated,
and therefore that this FAIL represents an impersonation?”   The possible
responses are:  No protocol, None, Test Quarantine, Test Reject,
Quarantine, and Reject.   As we move from No policy to Reject, we have an
increase in the probability that all domain messages  can be authenticated
and therefore that all FAIL messages are impersonations.    (Of course,
even when impersonation is confirmed, the evaluator has to determine
whether it is an acceptable impersonation.  This is sufficiently common
that it needs to be mentioned, but is outside the scope of our protocols.)

The two protocols are largely independent.  A domain owner could publish
nothing for SPF and DKIM, then publish a P=REJECT policy, to indicate that
it never sends mail from a particular subdomain name.   It could also
publish SPF and DKIM information to allow some messages to be
authenticated, yet publish no DMARC policy to guide failure handling.

Doug

On Tue, Jan 18, 2022 at 5:33 PM Barry Leiba <[email-masked]> wrote:

>  With one exception mentioned below,

---

From: Todd Herr <[email-masked]>
Date: Wed, 19 Jan 2022 08:54:28 -0500

> algorithm for handling DMARC FAIL.
No.

There is one protocol - DMARC, and the application of that protocol can
nominally produce two results - PASS or FAIL.

The protocol defines the methods for arriving at those results, and offers
the domain owner the opportunity to publish its opinion on what should be
done with messages producing a FAIL verdict, but does not mandate any
behavior for FAIL verdicts, nor should it. Message handling decisions will
always, always, always be at the discretion of the receiving domain; their
network, their rules.

[snip]

> authenticated, yet publish no DMARC policy to guide failure handling.

There is already a better commonly accepted way for a domain owner to
announce that a domain sends no mail, and this method is computationally
less expensive for the receiving side.

The method is to publish an SPF record that looks like this: "v=spf1 -all"

Because SPF is checked during EHLO/MAIL FROM, the transaction can be
terminated earlier than one relying on DMARC, which requires that the
entire message be consumed by the receiving server so that the RFC5322.From
header can be parsed for the domain and DMARC checking can proceed.

--

---

From: Barry Leiba <[email-masked]>
Date: Wed, 19 Jan 2022 09:14:13 -0500

>> I have been trying to understand why such a big disconnect is
>> possible between my usage of DMARC data and the standard one.   I
>> have concluded that it occurs because we are dealing with two
>> protocols, not one, and the standard view conflates them
>> unnecessarily.   The first protocol is the algorithm for detecting
>> DMARC PASS, and the second protocol is the algorithm for handling
>> DMARC FAIL.
>
> No.
>
> There is one protocol - DMARC, and the application of that protocol
> can nominally produce two results - PASS or FAIL.
>
> The protocol defines the methods for arriving at those results, and
> offers the domain owner the opportunity to publish its opinion on what
> should be done with messages producing a FAIL verdict, but does not
> mandate any behavior for FAIL verdicts, nor should it. Message
> handling decisions will always, always, always be at the discretion of
> the receiving domain; their network, their rules.

I look at it a different way, coming to the same conclusion that it's
one protocol:

There's the part that domain owners do: publish DMARC policy records.

There's the part that mail recipients do: determine DMARC PASS or
DMARC FAIL, and then take action accordingly.

They're two parts of one protocol and they are not at all independent;
we are not conflating them.

That's my opinion as a participant.

As a chair, I clearly see consensus with the views that Todd and I,
along with several others, have expressed in this discussion.  I don't
see that this line of discussion is going anywhere useful and I see it
as a distraction from finishing the work.  Let's please move on.

Barry

---

From: "John Levine" <[email-masked]>
Date: 19 Jan 2022 10:23:50 -0500

It appears that Todd Herr  <[email-masked]> said:
>assumed to be unauthorized. ...

I would agree except for the word "yet".  For most of my domains I have no
intention of ever publishing a policy other than p=none.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 Jan 2022 18:38:36 +0100

> intention of ever publishing a policy other than p=none.

My understanding is that some users of your domain(s) use your MXes but, 
occasionally or consistently, use a different MSA.  In such cases, no DKIM 
signature with d=your domain can be present.  Is that correct?

Anyway, I often see your DKIM signatures, and p=none doesn't tell me much about 
how to handle their failing to verify.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 19 Jan 2022 12:49:39 -0500

No.

R's,
John