Subject: [dmarc-ietf] Priming the Pump for Discussion - Ratchets

From: Todd Herr <[email-masked]>
Date: Tue, 6 Jul 2021 08:45:35 -0400

Greetings.

The theoretical goal of any domain owner that publishes a DMARC record is
to transition from an initial policy of p=none to a final one of p=reject,
because it is only at p=reject that DMARC's intended purpose of preventing
same-domain spoofing can be fully realized.

Many domain owners see the transition from p=none to p=reject as a black
box, in that they believe they have no way of knowing what the full impact
of such a change might have on their mail, and they fear irreparable harm
to their mail if they make a mistake.

The designers of DMARC anticipated this fear, and built several different
transitional states, or ratchets, into the protocol, including:

   - The "pct" tag (https://trac.ietf.org/trac/dmarc/ticket/47)
   - The "sp" tag (https://trac.ietf.org/trac/dmarc/ticket/48)
   - "quarantine" as a value for "p=" (
   https://trac.ietf.org/trac/dmarc/ticket/39)

All of these are designed to allow the domain owner to request that some,
but not all, of its mail be held to stricter authentication standards so
that the domain owner can dip a toe in the water before jumping in.

The ratchets have introduced some problems, though:

   - The 'pct' tag doesn't exactly work like it's intended to, and really
   can't because of the nature of mail flow, unless there is a high volume of
   failed authentication for the domain in question. (There is a much longer
   discussion of this in section 6.7.4, Message Sampling, of
   draft-ietf-dmarc-dmarcbis-02.)
   - Some domain owners have taken a "more is more" approach to ratchets,
   figuring if one is good, all are better, resulting in needlessly
   complicated policy records

The purpose of this email is to get folks thinking about possibly
simplifying the ratchet mechanisms, perhaps boiling them down into one.
This thinking and on-list discussion on this topic would serve as a
precursor to further face-to-face discussion at the next interim working
group meeting.

I'll start the discussion by taking an extreme position...

Ratchet mechanisms don't help in any way that a short TTL on your DMARC
record won't help, and in fact you need the short TTL on your record
anyway, because if you're trying a ratchet mechanism and find it's too
much, you still gotta update DNS to roll it back.

Getting to p=reject isn't a difficult undertaking, at least from a
technical standpoint. Enumerate all your mail streams, ensure that they're
authenticating properly, and boom, you're done. The proper tools for doing
that are p=none, a rua tag pointed at a mailbox that is parsed by automated
means, active daily monitoring of the data consumed in those aggregate
reports (so that mail streams can be enumerated and authentication problems
addressed), and time. Time is the big one here, because sufficient time
must elapse to ensure that all of your legitimate mail streams are
exercised and reported upon, and that can take many months in large
organizations or at companies that are in the business of seasonal email
sending.

The big challenge to fixing authentication issues, especially in large
organizations, is usually in just finding who owns the host/process that's
generating that unauthenticated mail. That can add time to the process, but
once you've enumerated them all, updated your SPF record and/or made sure
they're all properly DKIM signing, you can skip right from p=none to
p=reject.

I look forward to lively conversation...

-- 

*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: Dilyan Palauzov <[email-masked]>
Date: Tue, 06 Jul 2021 15:04:26 +0000

Hello,

Is the period for abstentions on posting now over?

>    https://trac.ietf.org/trac/dmarc/ticket/39)

After reading several opinions on this, I do not think that  
“quarantine” means a transitional state between “reject” and “none”,  
according to the majority.  The distinct “quarantine” and “reject”  
options exist, solely because the SMTP protocol does permit this  
distinction.  Both options protect the domain equally good.  Both  
options are only hints from the domain owner, which hints can be  
altered by the recipient (the recipient can handle all “reject” as  
“quarantine” and all “quarantine” as “reject”).

I have not read the recent drafts.  In case the drafts do not discuss,  
while reject is better than quarantine, it is not better: reject and  
quarantine are equally good final states.

There are two exceptions:
• Reject allows the sender of emails (the administrator/postmaster) to  
get an (immediate) notification, when the DKIM+DMARC implementations  
on sender and receiver disagree, quarantine does not allow such  
feedback.  The administrator can take actions to fix the  
implementation, based on the feedback for a concrete message.
• Reject allows the sender (the user, mailbox owner) to look for  
alternative means to contact the recipient, once the mail is  
immediately returned.  When quarantine is used, a DMARC/DKIM  
implementations on an end has errors, or transitional DNS problems  
happen, and the recipient does not (regularly) check its spam folder,  
the mail is essentially lost and nobody is notified.

With the above exceptions in mind, that have negative impact only when  
quarantine is used, it is biased to state, that quarantine is a  
transitional state between reject and none.

Past experience showed, that reducing the ratches, by striking  
quarantine out, leads to endless mail threads, which nobody can follow.

I think it is realistic to mention the above two exceptions.

In fact, as somebody mentioned two years ago, the DMARC wording  
suggests that reject is stronger than quarantine.  The wording at  
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-02#section-6.7.4.1 (pct fallback to quarantine from reject) does currently support this concept.  As far as I remember, there was consensus to remove this text. (pct=10; p=reject shall fall back to p=none, not to p=quarantine).  If the reasoning on why shall QUARANTINE be kept, is taken into account (=because SMTP allows this variant), the reasoning in no way explains, why is quarantine a transitional  
state.

My opinion is, that the current editing process does improve the  
situation, but DMARC/DKIM will remain complex topics.  Even if a  
misunderstanding on why is reject stronger (better) protection than  
quarantine remains, there will still be improvements in other areas.

The “extreme position” below is not extreme enough: since SPF is  
pointless in indirect mail loops, SPF records shall never be touched  
when dealing with DMARC.  I agree with the extreme position, but I do  
not believe there will be consensus on it.

Greetings
   Дилян

----- Message from Todd Herr <todd.herr=[email-masked]>  
---------
    Date: Tue, 6 Jul 2021 08:45:35 -0400
    From: Todd Herr <todd.herr=[email-masked]>
Subject: [dmarc-ietf] Priming the Pump for Discussion - Ratchets
      To: IETF DMARC WG <[email-masked]>

> I look forward to lively conversation...

----- End message from Todd Herr  
<todd.herr=[email-masked]> -----

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 6 Jul 2021 19:58:37 +0200

Hi,

> same-domain spoofing can be fully realized.

I slightly disagree on that.  Both p=none and p=quarantine have their own 
merits, and the transition can take a very long time.

> Getting to p=reject isn't a difficult undertaking, at least from a technical
> standpoint. Enumerate all your mail streams, ensure that they're
> authenticating properly, and boom, you're done.

I keep seeing authentication failures on mailing lists.  Speaking for myself, 
MLs constitute a relevant percentage of my mail traffic.  I'm going to stay at 
p=none (or maybe p=quarantine; pct=0) until that is fixed.

> simplifying the ratchet mechanisms, perhaps boiling them down into one.

I'd rather propose to add another p= level, in between p=none and p=quarantine. 
  I'd want receivers to reject my mail if it fails authentication, but only on 
the first hop.  In particular, I'd want mailing lists (whether or not doing 
From: munging) to reject unauthenticated messages claiming to come from me. 
(And, given that it's hard to specify "first hop", it would be fine to word 
such policy as "reject by MLMs only".)

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 6 Jul 2021 14:50:57 -0400

I don't really have a horse in this race since I never plan to publish anything
other than p=none, but ...

>much, you still gotta update DNS to roll it back.

Given that the reports are completely independent of the policy, of course.

I believe the goal of the rachet mechanisms was that you can turn them
up a little bit, so if they're wrong, they'll only screw up a little
bit of your mail. But the fallacy is that if your mail is only a
little bit screwed up, you won't be able to tell from the sending end
whether anything is wrong. Better to take a deep breath, set the TTL to
10 seconds, throw the switch, and if you screwed up, you'll find out
quickly.

My inclination is to deprecate pct= and say receivers can ignore it.  Deprecate p=quarantine,
and say that receivers SHOULD treat p=quarantine and p=reject the same, with the actual
handling to be determined by receivers who know a lot more about their users' behavior
than senders do.

Some people use pct=0 as a flag to say that things like mailing lists should do
DMARC-evading things, but I think there are better ways to debug list software.

R's,
John

PS: https://www.theonion.com/americans-eagerly-check-to-see-if-they-got-any-emails-t-1847220852

---

From: Douglas Foster <[email-masked]>
Date: Sun, 11 Jul 2021 15:32:18 -0400

If we are willing to break upward compatibility, it might be preferable to
define policy in terms of what the sender knows, rather than what the
receiver should do.   After collecting feedback, the sender should know
whether all message sources are sending with SPF PASS, DKIM PASS, or both.

This could be implemented with granularity based on the domain-part used in
MAILFROM, and these four possible policy statements:

Messages sent using organization domain for SMTP:

·         All messages with MAILFROM matching <FROM scope> will produce SPF
PASS, at first hop.

·         All messages with MAILFROM matching <FROM scope> will produce
DKIM PASS based on the FROM address, at first hop.

Messages sent by mailing service providers using the service provider
domain for SMTP:

·         All messages with MAILFROM not matching <FROM scope> will produce
SPF PASS based on the SMTP address used, at first hop.

·         All messages with MAILFROM not matching <FROM scope> will produce
DKIM PASS based on the FROM address, at first hop.

We know that forwarding can affect DMARC and SPF evaluation, and that
forwarding is outside the control of the sender.   Consequently, when
verification fails, it is the recipient system’s burden to determine
whether forwarding has occurred, how the forwarding action affects the
trust level of the message, and consequently whether the forwarding path is
acceptable.   One way to handle this would be for recipients of forwarded
mail to register that fact with the system administrator, so that the
system administrator could configure appropriate rules in the message
evaluation system.

Additionally, not all DMARC-violating impersonation is malicious, so even
when impersonation is confirmed, it remains the recipient system’s burden
to decide whether the impersonation should be tolerated or repudiated.

Some implementations of sender authentication have used IETF specifications
to simplistically implement message repudiation, without understanding the
possible exceptions, and consequently without providing the necessary
exception mechanisms.  I am hoping that DMARCbis will include enough
discussion of exceptions to reduce the likelihood of this error persisting
forever.   Changing the way we define policy might help achieve this goal.

 Doug Foster

On Tue, Jul 6, 2021 at 8:46 AM Todd Herr <todd.herr=
[email-masked]> wrote:

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

---

From: Douglas Foster <[email-masked]>
Date: Sun, 11 Jul 2021 17:42:41 -0400

Sorry, I got tangled up in the weeds between policy scope and alignment.
 The four policy assertions should have been phrased as:

For messages with FROM within <policy scope>,

·         All messages with MAILFROM algined to FROM will produce SPF PASS,
at first hop.

·         All messages with MAILFROM aligned to FROM will produce DKIM
PASS, based on the FROM address, at first hop.

·         All messages with MAILFROM not algned to FROM will produce SPF
PASS based on the SMTP address used, at first hop.

·         All messages with MAILFROM not aligned to FROM will produce DKIM
PASS, based on the FROM address, at first hop.

These are intended to be four independent assertions which can be
individually ON or OFF.   To implement this concept, we would need one or
four new keyword=value tokens.    DMARCv1 senders and receivers would use
the existing tokens and values (of which it has been said, 94% are NONE or
PCT=0.)   DMARCbis senders and receivers would use the new tokens based on
this concept.

This is intended to address Dave Crocker's concerns which led to a rewrite
of the introduction, Todd Herr's comments that DMARC FAIL should only be a
data point which is integrated into the evaluation algorithm, and
Alessandro's request for a partial implementation between NONE and
QUARANTINE.

Doug Foster

On Sun, Jul 11, 2021 at 3:32 PM Douglas Foster <
[email-masked]> wrote:

> This could be implemented with granularity based on the domain-part used
> in MAILFROM, and these four possible policy statements:
>
> SPF PASS, at first hop.
> ·         All messages with MAILFROM not matching <FROM scope> will
> produce SPF PASS based on the SMTP address used, at first hop.
>
> ·         All messages with MAILFROM not matching <FROM scope> will
> produce DKIM PASS based on the FROM address, at first hop.
>
> Some implementations of sender authentication have used IETF
> specifications to simplistically implement message repudiation, without
> understanding the possible exceptions, and consequently without providing
> the necessary exception mechanisms.  I am hoping that DMARCbis will include
> enough discussion of exceptions to reduce the likelihood of this error
> persisting forever.   Changing the way we define policy might help achieve
> this goal.
>
>
>  Doug Foster
>
>
>
>
>
>>    - The 'pct' tag doesn't exactly work like it's intended to, and
>>    really can't because of the nature of mail flow, unless there is a high
>>    volume of failed authentication for the domain in question. (There is a
>>    much longer discussion of this in section 6.7.4, Message Sampling, of
>>    - Some domain owners have taken a "more is more" approach to
>>    ratchets, figuring if one is good, all are better, resulting in needlessly

---

From: Douglas Foster <[email-masked]>
Date: Tue, 13 Jul 2021 07:02:34 -0400

I understand that under the current specification, PCT has been useful
because P=NONE with PCT=100 produces different results than QUARANTINE with
PCT=0.   This is an anomaly that I would hope we can fix, but if not, we
need to specify that the only valid settings are PCT=0 or PCT=100.   The
specification should force numbers between 1 and 99 to be interpreted as
either 0 or 100.

The current PCT specification is fatally flawed because the denominator is
undefined and unstable.  Suppose that a domain owner concludes that most
but not all of his traffic will produce DMARC PASS.   Should the percentage
be based on message volume or Source IP counts?    Either way, the volume
distribution received by any single evaluator will be different than the
volume distribution sent out.

But the larger problem is that the evaluator is performing a conditional
probability, because the policy is only applied to messages that produce
DMARC FAIL.    If there is no impersonation, an unauthenticated message has
a 100% probability of being legitimate.    The denominator is determined by
the volume of impersonation messages, not by the volume of legitimate
messages.   The percentage offered by the sending domain owner is useless.

Next, assume that an accurate probability can be determined, and that 80%
of unauthenticated messages are legitimate and 20% are impersonations.
Does it make sense to apply that probability rule to
message disposition?    It will produce these results:

Legitimate and DMARC ignored, message accepted = 80%*80% = 64% of total

Legitimate and DMARC enforced, message blocked = 80%*20% = 16% of total

Impersonation and DMARC ignored, message accepted = 20%*80% = 16% of total

Impersonation and DMARC enforced, message blocked = 20%*20% = 4% of total

Therefore, the correct decision is applied only 68% of the time, and the
wrong decision is applied 32% of the time.   This is unsatisfactory for
protecting against ransomware, and also unsatisfactory for reliably
delivering wanted messages.

The actual volume of impersonating messages will be determined by the
spammer, not by the domain owner, so the whole notion of choosing a
percentage is flawed.    The domain owner does not have the information
needed to provide a usable percentage.   The message evaluator can only
determine the percentage by carefully examining many messages and
categorizing the source.  Once the source is categorized, guessing is no
longer necessary and the percentage is irrelevant.

Doug Foster

---

From: Todd Herr <[email-masked]>
Date: Tue, 13 Jul 2021 14:09:45 -0400

> longer necessary and the percentage is irrelevant.
I believe you'll find that your ideas, or at least sentiments quite similar
to them, are captured in draft-ietf-dmarc-dmarcbis-02

First, draft-ietf-dmarc-dmarcbis-02 makes a small but substantial change to
the definition of the pct tag from what's currently in RFC 7489. Where RFC
7489 reads:

   pct:  (plain-text integer between 0 and 100, inclusive; OPTIONAL;
      default is 100).  Percentage of messages from the Domain Owner's
      mail stream to which the DMARC policy is to be applied.

draft-ietf-dmarc-dmarcbis-02 instead starts with this text:

   pct:  (plain-text integer between 0 and 100, inclusive; OPTIONAL;

      default is 100).  For the RFC5322.From domain to which the DMARC

      record applies, the "pct" tag is the percentage of messages

      producing a DMARC result of "fail" to which the Domain Owner
      wishes its preferred handling policy be applied.

Since the concept of applying DMARC policy to messages that produce a DMARC
result of "pass" doesn't exist, it doesn't make sense to claim that "pct"
applies to the entire mailstream.

Next, draft-ietf-dmarc-dmarcbis-02 contains a substantial rewrite of the
Message Sampling section (now section 6.7.4) that goes to great lengths to
attempt to show that the desired pct value really can't be counted on to be
applied as asked for, and what might actually happen could vary widely from
what's desired.

https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/

--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 13 Jul 2021 17:21:40 -0400

Thank you.   I will review it.

On Tue, Jul 13, 2021, 2:10 PM Todd Herr <todd.herr=
[email-masked]> wrote:

>> The current PCT specification is fatally flawed because the denominator
>> is undefined and unstable.  Suppose that a domain owner concludes that most
> I believe you'll find that your ideas, or at least sentiments quite
> similar to them, are captured in draft-ietf-dmarc-dmarcbis-02
>
> First, draft-ietf-dmarc-dmarcbis-02 makes a small but substantial change
> to the definition of the pct tag from what's currently in RFC 7489. Where
> RFC 7489 reads:
>
> Since the concept of applying DMARC policy to messages that produce a
> DMARC result of "pass" doesn't exist, it doesn't make sense to claim that
> "pct" applies to the entire mailstream.
>

---

From: Steven M Jones <[email-masked]>
Date: Tue, 13 Jul 2021 18:23:54 -0700

On 7/6/21 05:45, Todd Herr wrote:
>
> The theoretical goal of any domain owner that publishes a DMARC record
> is to transition from an initial policy of p=none to a final one of
> p=reject, because it is only at p=reject that DMARC's intended purpose
> of preventing same-domain spoofing can be fully realized.

While preventing impersonation of "high value" domains was the original
impetus for DMARC, and preventing same-domain spoofing is a/the core
benefit, it provides value for other use cases as well. For example, a
domain that doesn't currently see much abuse and has several indirect
mailflows (so "p=none"), but wants reporting as an "early warning
system" in case they're targeted later.

Broad applicability helps justify putting DMARC on the Standards Track,
so IMO we should be careful not to preclude other use cases, or give the
impression they aren't seen as valid.

--S.

---

From: "John Levine" <[email-masked]>
Date: 14 Jul 2021 12:52:28 -0400

It appears that Steven M Jones  <[email-masked]> said:
>-=-=-=-=-=-

Good point -- that's exactly why I use it, even though I have no intention
of ever publishing a policy other than p=none.

The reports are quite interesting.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Thu, 15 Jul 2021 21:07:25 -0400

>
> We can and should provide an intermediate policy option, if we concentrate
> on the principle that both authentication and repudiation require
> confirming evidence.  Repuudiation is not the simple opposite of
> authentication.   To this date, our choices have been limited because
> DMARCv1 did not design repudiation rules, but we can.
>
> The aligned DKIM signature test can have three conclusions, not just two:
>
> ·         Fully Authenticated:    A signature is present, a DNS public
> key is available, and the key can be used to verify the signature.
>
> ·         Provided:  A signature is present, and a DNS public key is
> available, but the key cannot be used to validate the signature.
>
> ·         No Signature or No key:  A signature is not present or is
> present but the DNS public key is not available.
>
> If the domain owner indicates that all messages originate with a
> signature, then messages with “No Signature or No Key” are verifiably not
> from the domain owner and can be confidently repudiated.
>
> Similarly, SPF checks can provide multiple levels of granularity:
>
> ·         Fully authenticated:   An SPF policy is found, it evaluates to
> PASS, and the MAILFROM and FROM domains are aligned.
>
> ·         Well-identified source:   An SPF policy is found, it evaluates
> to PASS, but the MAILFROM and FROM domains are not aligned.
>
> ·         Valid Identifier:  An SPF policy is found.
>
> ·         No policy:   An SPF lookup returns or NXDOMAIN.
>
> We can provide a repudiation test based on Valid Identifier.   Some
> forwarders will forward without MAILFROM rewrite, in which case SPF will
> fail, but the Valid Identifier test will pass.   Other forwarders will
> perform MAILFROM rewrite to ensure SPF PASS.  In either case, it is
> reasonable to conclude that all forwarded messages wiill pass the “Valid
> Identifier” test.
>
> Consequently, a DMARCbis policy focused on “no false rejections” will look
> like this:
>
> ·         Authenticated (unchanged):
>
> o   SPF PASS and aligned, or
>
> o   DKIM verified and aligned.
>
> ·         Repudiated (new):
>
> o   No DKIM signature or no DNS key for the signature, when the domain
> owner indicates that DKIM signatures are always present
>
> o   No SPF policy (NONE or NXDOMAIN) when  the domain owner indicates
> that SPF policies always exist.
>
> ·         Ambiguous (clarified):
>
> o   Any message which is neither Authenticated nor Repudiated.  This
> includes any authorized messages which have been processed through a
> mailing list.
>
Doug Foster

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 Jul 2021 11:32:15 +0200

On Tue 13/Jul/2021 20:09:45 +0200 Todd Herr wrote:
> On Tue, Jul 13, 2021 at 7:03 AM Douglas Foster wrote:
> 
> 

Why not?  I'd say that a DMARC filter takes no action when dmarc=pass (except 
for setting Authentication-Results: and feedback data).  The policy requests 
noop on pass, and it is applied indeed.

> applied as asked for, and what might actually happen could vary widely from

I find that section excessively long and difficult.  It doesn't mention the key 
point that the percentage is more and more exact as the number of (failed) 
messages grows.  Indeed, pct=20 doesn't say that the policy should apply to one 
of /the first five/ messages.

The second paragraph of Section 6.7.4.2 surmises that the percentage is meant 
on a daily basis.  From such assumption, it then infers its inexactness.

    The "pct" tag is a request to take a sample of a larger population
    and apply different rules to it.  The population is made up of all
    messages that produce DMARC "fail" results for that domain in a given
    day, and the sample size is the percentage of that population
    represented by the value of the "pct" tag.  It is trivial to perform
    this sampling to the exact number specified if the population size is
    known, but the nature of email is such that the population size
    cannot be known until all messages have been collected and evaluated
    that day.  Email traffic tends to flow in spurts, not at a constant
    level throughout the day, and so a volume seen during any time slice
    cannot be extrapolated across a 24 hour period.  Waiting until the
    end of the day to decide which messages to either quarantine or
    reject goes against all best practices and exposes the mail-receiving
    organization to vectors of abuse, and so we must approximate the
    population and sample sizes on the fly.

It would be untroubled to consider the population to be made up of all messages 
for that domain during all of the time while the given DMARC record holds.  The 
approximation then results from interrupting the message stream, or altering 
the record, before the applied percentage reaches the exact value expressed 
therein, which otherwise it will eventually meet.

The last paragraph of Section 6.7.4.2 seems to say that pct affects reporting:

    *  "0" - A request that zero percent of messages producing a DMARC
       "fail" result have the specified policy applied.  While this is
       seemingly a non-sensical request, this value has been given
       special meaning by some mailbox providers when combined with
       certain "p=" values to alter DMARC processing and/or reporting for
       the domain publishing such a policy.

I'd remove "and/or reporting".

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Fri, 16 Jul 2021 09:44:35 -0400

On Fri, Jul 16, 2021 at 5:32 AM Alessandro Vesely <[email-masked]> wrote:

> DMARC
I will continue to maintain that it makes no sense to talk about the
concept of applying DMARC policy to messages which pass DMARC validation
checks, especially in the context of the 'pct' tag.

In RFC 7489, the definitions of "quarantine" and "reject" both speak of
their application in terms of "email that fails the DMARC mechanism check".

So, for a DMARC record such as this:

_dmarc.foo.com IN TXT "v=DMARC1; p=quarantine; pct=X; rua=...."

I assert that the domain owner is requesting that X percent of the messages
that fail the DMARC mechanism check be subjected to the "quarantine"
policy.

To assert that the domain owner is instead asking only that DMARC
validation checks be performed on X percent of the messages runs the very
real risk of the pct mechanism being even less useful as a ratchet,
especially when X is small, because that X% of the total mailstream might
not contain any DMARC failures.

It occurs to me now that something like the following is considered a valid
DMARC record, and we should probably fix that:

_dmarc.foo.com IN TXT "v=DMARC1; p=none; pct=25; rua=...."

The fix would be to describe the 'pct' tag as only valid with p= quarantine
or reject, because "p=none, pct=X" is just a nonsensical way of writing
"p=none; pct=100", because you're going to get "none" on all failures
regardless.

> of /the first five/ messages.
Please suggest alternate text.

> I'd remove "and/or reporting".
This section is an attempt to discuss the need for one to have a policy of
"p=quarantine; pct=0" to get accurate reporting from Google in the past,
and was mentioned during the last interim -
https://datatracker.ietf.org/doc/minutes-interim-2021-dmarc-01-202105270900/

Please suggest alternate text.

--

---

From: Jim Fenton <[email-masked]>
Date: Fri, 16 Jul 2021 16:24:27 -0700

>> from the domain owner and can be confidently repudiated.

Why would “Provided” be handled any differently from “No signature or no key”? An attacker can easily provide a signature for a message they are spoofing, and after observing some of that domain’s traffic will know what selector name to use that has a published public key.

DKIM is very explicit about its results: either the signature verifies or it does not. There is no third case.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 16 Jul 2021 16:38:33 -0700

On 6 Jul 2021, at 5:45, Todd Herr wrote:

> is

*Any* domain owner? That is not a goal of any of my domains.

A DMARC record should reflect the sending behavior of the domain it’s 
associated with. If the domain, for any number of reasons, does not have 
the ability to authenticate all of its outgoing mail in an aligned way, 
it should either publish p=none and leave it at that, or not publish a 
DMARC record at all (if it doesn’t want any reports).

-Jim

P.S. What I think you are describing here is what I consider the 
converse of a ratchet. A ratchet allows movement in one direction, not 
the other, and you seem to be talking about going from a p=reject policy 
back to something less strict if there is a problem.

---

From: Douglas Foster <[email-masked]>
Date: Sat, 17 Jul 2021 08:38:13 -0400

The goal is to partition all incoming messages into two mutually exclusive
groups:   Those messages which originated under domain owner control, and
those which originated under domain owner control, and those which
originated outside domain owner control.   This requires two things:

- First, that at origination, credentials are in place so that a first-hop
MTA can reliably perform this partitioning.   I have a much longer
analysis, but the short version is that this requires an aligned and
verified DKIM signature on all messages.   There is no partial
participation, which is why the percentage notion needs to be discarded.
 Of course, fully authenticated messages are always detectable.  However,
in the absence of DKIM on all messages, the partitioning is not possible
because both domain owner and non-owner messages will both fail to be
authenticated.

- Secondly, the message addresses and the associated DKIM credential must
be preserved until the message is received.   We know that this is not the
case because forwarding with changes will break the DKIM signature.   The
absence of verification does not reliably indicate the absence of domain
owner
control, it can result from a domain owner message which was modified or a
non-owner message which was received in transit for any reason.

Consequently, we need three categories:
1) Messages which can be reliably attributed to the domain owner because
authentication passess.
2) Messages which can be reliably attributed to non-owners because of a
repudiation rule.
3) Messages which are ambiguous because they neither meet an authentication
rule nor meet a repudiation rule.

When we acknowledge this three-category reality, we have solved the mailing
list problem.   Mailing list messages can never be in category one.   They
belong in category 2.  The current DMARCv1 specification forces them into
category 3.   The two-possibility worldview creates the problem.   The
three-possibility worldview solves the problem.

I suggest these repudiation rules:

Rule 1:  The domain owner asserts that all messages from this domain will
originate with a verifiable DKIM signature.   If a message does not have an
aligned DKIM signature, or does not have a DNS public key available for the
scope ID, then the message originated outside domain owner control,  As I
have said, this is a mandatory first step to any policy being applied to
non-authenticated mail.

Rule 2:  The domain owner asserts that all messages from this domain will
originate with an SPF policy, including messages from email service
providers.   Results of SPF NONE or SPF NXDOMAIN indicate messages that are
outside domain owner control.

Rule 3:  The domain owner asserts that all messages from this domain will
have RFC5322.FROM addresses that "exist".   Messages that do not have FROM
addresses which "exist" have originated outside domain owner control.  The
definition of "Exists" is still being debated, and I have expressed strong
feelings about the right definition.

Rule 4:  The domain owner asserts that all messages from the domain will
originate with an initial ARC Set.   Messages which do not have an ARC Set
from the domain have originated outside domain owner control.  I am
inclined to include broken-chain ARC sets in this rule, but John would be a
better person to clarify this question

Everything that is not authenticated or repudiated is in category 2.   I
understand that category 2 includes a large number of messages.   These
messages require more analysis because the DMARC result is indeterminate.
 In most cases, this means that the next step is to put the message through
the full suite of content filters.   If the message is not blocked based on
content filters, then it may be desirable to do an in-depth analysis of the
message. Full header analysis is complex, ambiguous, subject to spoofing,
and very much outside of the capabilities of this document.

Note:  I am being careful to use "outside domain owner control" because
some such messages are very much wanted and should not be blocked.   Even
though such cases exist, the partitioning effort is indeed useful, because
it can be used to block some unwanted messages.  So "p=reject" fails on
multiple levels:   It presumes that the domain owner knows that credentials
will be preserved until reception, which is false, and it assumes that
non-credentials messages should always be blocked, which is also false.
 "Pct=50" fails because it presumes that partial participation is possible,
and it presumes that a message evaluator will be willing to use a random
number generator to decide message fates.

Doug Foster

Doug Foster

On Fri, Jul 16, 2021 at 7:24 PM Jim Fenton <[email-masked]> wrote:

> Why would “Provided” be handled any differently from “No signature or no
> key”? An attacker can easily provide a signature for a message they are
> spoofing, and after observing some of that domain’s traffic will know what
> selector name to use that has a published public key.
>

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 17 Jul 2021 15:09:18 +0200

On Fri 16/Jul/2021 15:44:35 +0200 Todd Herr wrote:
> On Fri, Jul 16, 2021 at 5:32 AM Alessandro Vesely wrote:
>>> DMARC result of "pass" doesn't exist, it doesn't make sense to claim
>>> that "pct" applies to the entire mailstream.>>
>> Why not?  I'd say that a DMARC filter takes no action when dmarc=pass 
>> (except for setting Authentication-Results: and feedback data).  The
>> policy requests noop on pass, and it is applied indeed.>

This is a minor issue.  I just observed it is not necessary to pinpoint on what set to take the percentage.  The case that results in the easier wording should be used.

> not contain any DMARC failures.

I never meant that.  The DMARC check has to performed in all cases.

> DMARC record, and we should probably fix that:> 

I agree it's quite nonsensical, except you can have p=none; sp=reject; pct=X, which makes sense.  However, it isn't worth to spend a paragraph of specification to declare such records invalid.  It is totally obvious how to treat such cases —it's a noop, similar to the policy to be applied on dmarc=pass.

I found various instances of such records, which I paste at the bottom of this message.

>>> Next, draft-ietf-dmarc-dmarcbis-02 contains a substantial rewrite
>>> of the Message Sampling section (now section 6.7.4) that goes to
>>> great lengths to attempt to show that the desired pct value
>>> really can't be counted on to be applied as asked for, and what
>>> might actually happen could vary widely from what's desired.
>>
>> I find that section excessively long and difficult.  It doesn't
>> mention the key point that the percentage is more and more exact as
>> the number of (failed) messages grows.  Indeed, pct=20 doesn't say
>> that the policy should apply to one of /the first five/ messages.>

I will.  I appreciate your mathematical digression, but I don't think dmarcbis is the appropriate kind of media to publish such kind of articles.

> Please suggest alternate text.

Hm... an attempt could be as follows:

    *  "0" - A request that zero percent of messages producing a DMARC
       "fail" result have the specified policy applied.  While this is
       seemingly a non-sensical request, this value has an effect on
       some mailing lists or groups who rewrite the From: header field
       only if the author domain publishes a strict policy.  So having
       p=quarantine; pct=0 changes how mail mediators behave without
       affecting the actual treatment by the final receivers.

Of course, processing is different and the resulting aggregate reports change as a consequence.  Currently there are some variations on how to operate From: munging.  There should be a section on that topic, so the above paragraph could refer to it.

Now for p=none; pct=;  many records are expired, some are still current, some make sense, some don't.

MariaDB [mail]> SELECT domain, dmarc_rec, FROM_UNIXTIME(last_recv) AS date FROM domain WHERE dmarc_rec RLIKE 'p=none' AND dmarc_rec RLIKE 'pct=' AND NOT dmarc_rec RLIKE 'p=[rq]' order by date desc;
+---------------------------+------------------------------------------------+---------------------+
| domain                    | dmarc_rec                                      | date                |
+---------------------------+------------------------------------------------+---------------------+
| bluehost.com              | adkim=r; aspf=r; p=none; pct=10                | 2021-07-17 00:38:18 |
| mailerlite.com            | adkim=r; aspf=r; p=none; pct=5                 | 2021-07-16 13:47:29 |
| reverbia.it               | adkim=r; aspf=r; p=none; pct=1                 | 2021-07-14 11:01:12 |
| kernel.org                | adkim=r; aspf=r; p=none; pct=1                 | 2021-07-13 21:24:30 |
| crif.com                  | adkim=r; aspf=r; p=none; pct=25; fo=s          | 2021-07-06 14:28:33 |
| endurance.com             | adkim=r; aspf=r; p=none; pct=10                | 2021-07-04 04:56:51 |
| domain.com                | adkim=r; aspf=r; p=none; pct=10                | 2021-06-29 17:47:32 |
| constantcontact.com       | adkim=r; aspf=r; p=none; pct=10                | 2021-06-11 18:22:30 |
| asmallorange.com          | adkim=r; aspf=r; p=none; pct=10                | 2021-06-05 11:07:19 |
| netfacil.net.br           | adkim=r; aspf=r; p=none; sp=none; pct=5        | 2021-05-29 12:58:25 |
| xss.de                    | adkim=r; aspf=r; p=none; pct=1                 | 2021-05-20 23:35:57 |
| nic.cz                    | adkim=s; aspf=r; p=none; sp=none; pct=5; fo=1  | 2021-05-17 14:28:01 |
| oyabasket.com             | adkim=r; aspf=r; p=none; sp=none; pct=90; fo=0 | 2021-02-25 04:45:41 |
| ac-orleans-tours.fr       | adkim=r; aspf=s; p=none; sp=none; pct=1; fo=0  | 2021-02-25 00:20:17 |
| forgerock.com             | adkim=r; aspf=r; p=none; sp=none; pct=0        | 2021-02-24 13:22:35 |
| nw.tutto-business.it      | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0  | 2021-02-14 10:39:05 |
| nw.esperienza-italia.it   | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0  | 2021-02-13 12:09:45 |
| ticino.com                | adkim=r; aspf=r; p=none; pct=90                | 2021-02-04 14:50:44 |
| DENIC.DE                  | adkim=r; aspf=r; p=none; sp=none; pct=0; fo=0  | 2021-01-26 09:58:41 |
| uclouvain.be              | adkim=s; aspf=s; p=none; sp=none; pct=50; fo=1 | 2021-01-05 10:42:00 |
| vshosting.cz              | adkim=r; aspf=r; p=none; pct=1                 | 2020-08-11 18:05:14 |
| nw.graziepromo.com        | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0  | 2020-08-04 09:09:04 |
| xyonet.com                | adkim=r; aspf=r; p=none; pct=5; fo=0:1:d:s     | 2020-07-30 22:57:33 |
| anandbus.net              | adkim=r; aspf=r; p=none; sp=none; pct=20; fo=0 | 2020-06-10 23:59:42 |
| windstream.com            | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=1  | 2020-04-27 15:13:16 |
| ipage.com                 | adkim=r; aspf=r; p=none; pct=10                | 2020-03-30 11:16:28 |
| packlink.com              | adkim=r; aspf=r; p=none; pct=60                | 2020-03-27 16:02:53 |
| hostgator.com             | adkim=r; aspf=r; p=none; pct=10                | 2020-02-10 06:04:43 |
| pasteur-cayenne.fr        | adkim=r; aspf=r; p=none; sp=none; pct=5        | 2019-12-27 04:27:44 |
| nw.mailzop.com            | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0  | 2019-12-22 16:04:05 |
| mediacombb.net            | adkim=r; aspf=r; p=none; sp=none; pct=0; fo=1  | 2019-12-15 04:42:23 |
| nw.kisend.com             | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0  | 2019-11-26 18:14:11 |
| nw.mailrogue.com          | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0  | 2019-11-21 20:34:34 |
| nw.mailcri.com            | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0  | 2019-10-15 15:40:06 |
| nw.keesend.com            | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0  | 2019-10-13 15:57:08 |
| maersk.com                | adkim=r; aspf=r; p=none; pct=1; fo=1           | 2019-07-17 09:03:42 |
| qlc.in                    | adkim=r; aspf=r; p=none; pct=5                 | 2019-06-04 00:21:26 |
| iran.ir                   | adkim=r; aspf=r; p=none; pct=50; fo=1          | 2019-02-12 09:29:27 |
| 0086.info                 | adkim=r; aspf=r; p=none; pct=5; fo=1           | 2019-02-03 17:30:23 |
| olivet.edu                | adkim=r; aspf=r; p=none; pct=5; fo=1           | 2019-02-01 19:17:07 |
| news.packlink.it          | adkim=r; aspf=r; p=none; pct=60                | 2018-08-01 11:53:01 |
| ucdavis.edu               | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=1  | 2018-04-29 04:19:01 |
| anchus.com.ar             | adkim=r; aspf=r; p=none; sp=none; pct=1        | 2018-04-10 19:19:24 |
| junkemailfilter.com       | adkim=r; aspf=r; p=none; sp=none; pct=0        | 2018-02-02 21:47:05 |
| bnl.gov                   | adkim=r; aspf=r; p=none; pct=10                | 2018-01-24 02:12:25 |
| aqa.org.uk                | adkim=r; aspf=r; p=none; sp=none; pct=10       | 2018-01-24 01:01:06 |
| explorartdigital.com      | adkim=r; aspf=r; p=none; sp=none; pct=1        | 2018-01-16 17:13:23 |
| mail1.datongcloud.com     | adkim=r; aspf=r; p=none; pct=50                | 2018-01-12 18:25:53 |
| hulusungaitengahkab.go.id | adkim=r; aspf=r; p=none; pct=20                | 2018-01-01 04:08:33 |
| demmarkita2.com           | adkim=r; aspf=r; p=none; pct=20                | 2017-10-18 13:56:23 |
| opentext.com              | adkim=r; aspf=r; p=none; sp=none; pct=10; fo=s | 2017-09-28 22:43:18 |
| eu.org                    | adkim=r; aspf=r; p=none; sp=none; pct=10       | 2017-07-25 19:42:09 |
| ramosmirkin.com           | adkim=r; aspf=r; p=none; sp=none; pct=1        | 2017-07-23 12:00:18 |
| macsales.com              | adkim=r; aspf=r; p=none; pct=0                 | 2017-06-22 19:46:57 |
| opayq.com                 | adkim=r; aspf=r; p=none; pct=0                 | 2017-06-09 12:44:37 |
| mchsi.com                 | adkim=r; aspf=r; p=none; sp=none; pct=0; fo=1  | 2017-01-01 18:58:58 |
| lqfconos.com              | adkim=r; aspf=r; p=none; sp=none; pct=1        | 2016-10-24 20:00:38 |
| unimelb.edu.au            | adkim=r; aspf=r; p=none; sp=none; pct=10       | 2016-02-28 02:36:47 |
| waltermoreno.com          | adkim=r; aspf=r; p=none; sp=none; pct=1        | 2015-05-02 22:09:08 |
+---------------------------+------------------------------------------------+---------------------+
59 rows in set (0.088 sec)

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Mon, 19 Jul 2021 06:59:07 -0400

Todd, the new language has addressed my concerns about PCT.

As a message evaluator, PCT is an unreasonable request.   If I follow the
requested approach, it pretty much guarantees that I will block wanted
messages and allow unwanted messages.    I don't want to explain to a
C-level executive that a message was mishandled because "the random number
generator told me to do it."

PCT is also a significant data collection effort.   That collection effort
may represent a significant processing load, since every
non-authenticated record requires looking back over all received messages
in a chosen time period.   Obviously, that algorithm can be tuned, but the
tuning process is costly in time, labor, and stability risk.

I suppose that the issue here is that domain owners are concerned about the
message recipients who never send RUA reports.   Once enforcement is turned
on, SMTP reject and non-delivery reports provide feedback from more sources
(any source that does not discard silently).   The domain owner is unlikely
to get non-delivery reports from spam sources, so any notification about
messages that are blocked for DMARC-related reasons will be indications of
legitimate messages that were handled contrary to domain owner
preferences.   I understand the concern, I just don't see it as compatible
with my own security needs.

A partial solution lies in my proposal for an intermediate enforcement
option.   This option should be called "relaxed" mode, for consistency with
other standards.     The domain owner chooses whether
- SPF policy record is required in DNS,
- DKIM public key is required in DNS,
- From "existence" indicator is required in DNS, or
a domain-owner ARC Set is required in the message.
These are independently selectable enforcements; and they provide a domain
owner the opportunity to get reject and NDR information on a limited scale,
based on the feature selected and the weak nature of the test.

Domain owners who want to tolerate mailing list messages will stay in
relaxed mode permanently, and it provides more security than P=NONE.
Domain owners that want to block mailing list messages would eventually
switch to "strict", which is the same as our current P=REJECT.

Doug Foster

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Jul 2021 10:50:46 -0400

Doug, I think the issue here is that I disagree with your premise, so
the rest of the argument fails for me:

> The goal is to partition all incoming messages into two mutually exclusive groups:   Those messages which
> originated under domain owner control, and those which originated under domain owner control, and those
> which originated outside domain owner control.   This requires two things:

I don't agree with the characterization of the second group.  I would
say that we are partitioning messages into these two groups:
- Those for which we can confirm that they originated in the domain
they say they did.
- Those for which we can not confirm that.

Note that the second of those is subtly different to your
characterization, in that there's a difference between knowing that
they did not originate in the domain... and not knowing whether they
did or didn't.  It has never been a claim of either DKIM or SPF that
we can know anything in particular about a message when validation
fails: all either of them tells us is that validation has failed.

As Jim says, DKIM is very clear about that, when it tells us to treat
a validation failure the same as an absent signature.  Any proposal
that tries to treat a signature that fails to validate in any special
way is a non-starter, as it violates DKIM.

Barry

On Sat, Jul 17, 2021 at 8:38 AM Douglas Foster
<[email-masked]> wrote:
>
>
> The goal is to partition all incoming messages into two mutually exclusive groups:   Those messages which originated under domain owner control, and those which originated under domain owner control, and those which originated outside domain owner control.   This requires two things:
>
> - First, that at origination, credentials are in place so that a first-hop MTA can reliably perform this partitioning.   I have a much longer analysis, but the short version is that this requires an aligned and verified DKIM signature on all messages.   There is no partial participation, which is why the percentage notion needs to be discarded.   Of course, fully authenticated messages are always detectable.  However, in the absence of DKIM on all messages, the partitioning is not possible because both domain owner and non-owner messages will both fail to be authenticated.
>
> - Secondly, the message addresses and the associated DKIM credential must be preserved until the message is received.   We know that this is not the case because forwarding with changes will break the DKIM signature.   The absence of verification does not reliably indicate the absence of domain owner
> control, it can result from a domain owner message which was modified or a non-owner message which was received in transit for any reason.
>
> 1) Messages which can be reliably attributed to the domain owner because authentication passess.
> 2) Messages which can be reliably attributed to non-owners because of a repudiation rule.
> 3) Messages which are ambiguous because they neither meet an authentication rule nor meet a repudiation rule.
>
> When we acknowledge this three-category reality, we have solved the mailing list problem.   Mailing list messages can never be in category one.   They belong in category 2.  The current DMARCv1 specification forces them into category 3.   The two-possibility worldview creates the problem.   The three-possibility worldview solves the problem.
>
> Rule 1:  The domain owner asserts that all messages from this domain will originate with a verifiable DKIM signature.   If a message does not have an aligned DKIM signature, or does not have a DNS public key available for the scope ID, then the message originated outside domain owner control,  As I have said, this is a mandatory first step to any policy being applied to non-authenticated mail.
>
> Rule 2:  The domain owner asserts that all messages from this domain will originate with an SPF policy, including messages from email service providers.   Results of SPF NONE or SPF NXDOMAIN indicate messages that are outside domain owner control.
>
> Rule 3:  The domain owner asserts that all messages from this domain will have RFC5322.FROM addresses that "exist".   Messages that do not have FROM addresses which "exist" have originated outside domain owner control.  The definition of "Exists" is still being debated, and I have expressed strong feelings about the right definition.
>
> Rule 4:  The domain owner asserts that all messages from the domain will originate with an initial ARC Set.   Messages which do not have an ARC Set from the domain have originated outside domain owner control.  I am inclined to include broken-chain ARC sets in this rule, but John would be a better person to clarify this question
>
> Everything that is not authenticated or repudiated is in category 2.   I understand that category 2 includes a large number of messages.   These messages require more analysis because the DMARC result is indeterminate.   In most cases, this means that the next step is to put the message through the full suite of content filters.   If the message is not blocked based on content filters, then it may be desirable to do an in-depth analysis of the message. Full header analysis is complex, ambiguous, subject to spoofing, and very much outside of the capabilities of this document.
>
> Note:  I am being careful to use "outside domain owner control" because some such messages are very much wanted and should not be blocked.   Even though such cases exist, the partitioning effort is indeed useful, because it can be used to block some unwanted messages.  So "p=reject" fails on multiple levels:   It presumes that the domain owner knows that credentials will be preserved until reception, which is false, and it assumes that non-credentials messages should always be blocked, which is also false.   "Pct=50" fails because it presumes that partial participation is possible, and it presumes that a message evaluator will be willing to use a random number generator to decide message fates.
>
> Doug Foster
>
>
> Doug Foster
>
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Jul 2021 10:54:16 -0400

Indeed: I see PCT as a feature that was put in early, in order to
allow us to experiment with things and ease into DMARC.  As we move to
a Proposed Standard version, I don't see a continuing need for such a
phase-in feature, and aggregate reporting covers the desire to reduce
reporting volume.  I would like to see us deprecate PCT entirely, and
remove the complexity and the misunderstandings that cause confusion
and unexpected results, at best, and that can cause interoperability
issues, at worst.

Barry

On Mon, Jul 19, 2021 at 6:59 AM Douglas Foster
<[email-masked]> wrote:
> As a message evaluator, PCT is an unreasonable request.   If I follow the requested approach, it pretty much guarantees that I will block wanted messages and allow unwanted messages.    I don't want to explain to a C-level executive that a message was mishandled because "the random number generator told me to do it."
>
> PCT is also a significant data collection effort.   That collection effort may represent a significant processing load, since every non-authenticated record requires looking back over all received messages in a chosen time period.   Obviously, that algorithm can be tuned, but the tuning process is costly in time, labor, and stability risk.
>
> I suppose that the issue here is that domain owners are concerned about the message recipients who never send RUA reports.   Once enforcement is turned on, SMTP reject and non-delivery reports provide feedback from more sources (any source that does not discard silently).   The domain owner is unlikely to get non-delivery reports from spam sources, so any notification about messages that are blocked for DMARC-related reasons will be indications of  legitimate messages that were handled contrary to domain owner preferences.   I understand the concern, I just don't see it as compatible with my own security needs.
>
> A partial solution lies in my proposal for an intermediate enforcement option.   This option should be called "relaxed" mode, for consistency with other standards.     The domain owner chooses whether
> These are independently selectable enforcements; and they provide a domain owner the opportunity to get reject and NDR information on a limited scale, based on the feature selected and the weak nature of the test.
>
> Domain owners who want to tolerate mailing list messages will stay in relaxed mode permanently, and it provides more security than P=NONE.  Domain owners that want to block mailing list messages would eventually switch to "strict", which is the same as our current P=REJECT.
>
> Doug Foster
>
>
>
>
> On Tue, Jul 13, 2021 at 2:10 PM Todd Herr <todd.herr=[email-masked]> wrote:
>>
>> On Tue, Jul 13, 2021 at 7:03 AM Douglas Foster <[email-masked]> wrote:
>>>
>>> I understand that under the current specification, PCT has been useful because P=NONE with PCT=100 produces different results than QUARANTINE with PCT=0.   This is an anomaly that I would hope we can fix, but if not, we need to specify that the only valid settings are PCT=0 or PCT=100.   The specification should force numbers between 1 and 99 to be interpreted as either 0 or 100.
>>>
>>> The current PCT specification is fatally flawed because the denominator is undefined and unstable.  Suppose that a domain owner concludes that most but not all of his traffic will produce DMARC PASS.   Should the percentage be based on message volume or Source IP counts?    Either way, the volume distribution received by any single evaluator will be different than the volume distribution sent out.
>>>
>>> But the larger problem is that the evaluator is performing a conditional probability, because the policy is only applied to messages that produce DMARC FAIL.    If there is no impersonation, an unauthenticated message has a 100% probability of being legitimate.    The denominator is determined by the volume of impersonation messages, not by the volume of legitimate messages.   The percentage offered by the sending domain owner is useless.
>>>
>>> Next, assume that an accurate probability can be determined, and that 80% of unauthenticated messages are legitimate and 20% are impersonations.   Does it make sense to apply that probability rule to message disposition?    It will produce these results:
>>>
>>> Therefore, the correct decision is applied only 68% of the time, and the wrong decision is applied 32% of the time.   This is unsatisfactory for protecting against ransomware, and also unsatisfactory for reliably delivering wanted messages.
>>>
>>> The actual volume of impersonating messages will be determined by the spammer, not by the domain owner, so the whole notion of choosing a percentage is flawed.    The domain owner does not have the information needed to provide a usable percentage.   The message evaluator can only determine the percentage by carefully examining many messages and categorizing the source.  Once the source is categorized, guessing is no longer necessary and the percentage is irrelevant.
>>>
>>>
>>
>> I believe you'll find that your ideas, or at least sentiments quite similar to them, are captured in draft-ietf-dmarc-dmarcbis-02
>>
>> First, draft-ietf-dmarc-dmarcbis-02 makes a small but substantial change to the definition of the pct tag from what's currently in RFC 7489. Where RFC 7489 reads:
>>
>> Since the concept of applying DMARC policy to messages that produce a DMARC result of "pass" doesn't exist, it doesn't make sense to claim that "pct" applies to the entire mailstream.
>>
>> Next, draft-ietf-dmarc-dmarcbis-02 contains a substantial rewrite of the Message Sampling section (now section 6.7.4) that goes to great lengths to attempt to show that the desired pct value really can't be counted on to be applied as asked for, and what might actually happen could vary widely from what's desired.
>>
>> 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: Dave Crocker <[email-masked]>
Date: Tue, 20 Jul 2021 09:38:56 -0700

> Note that the second of those is subtly different to your

Not sure it's that subtle, but am sure the difference is profoundly 
important.

A constant misunderstanding of efforts in this realm of effort is a 
belief that perfection is attainable.  It isn't.  Therefore any 
characterization needs to use language of approximations, estimations, 
heuristics and trade-offs.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Jul 2021 09:39:39 -0700

On 7/20/2021 7:54 AM, Barry Leiba wrote:
> I would like to see us deprecate PCT entirely,

+1

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dotzero <[email-masked]>
Date: Tue, 20 Jul 2021 13:16:52 -0400

+1

Michael Hammer

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 20 Jul 2021 20:52:19 +0200

>>> I would like to see us deprecate PCT entirely,

if this was postfix it would not be accepted, old habist must stay to be 
backward compatible, sadly not all understand why

with all that changes it could end with no one uses this good software 
writed after c code i provided :(

hope for there LTS of it all

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Jul 2021 16:13:06 -0400

One of the points of "deprecation" is that we don't eliminate it
entirely, but say that it's no longer used.  New implementations no
longer generate it, but implementations that are interested in
backward compatibility will still include support for it on receipt.

Eventually, when we see that its use is rare enough, the community
might move to no longer include support (no longer needing backward
compatibility).  But I expect that support on receipt would remain for
some time.

Barry

---

From: Dotzero <[email-masked]>
Date: Tue, 20 Jul 2021 17:04:20 -0400

> compatibility).  But I expect that support on receipt would remain for

As soon as we say deprecated, the justifications for backwards
compatibility become tenuous. If a sender has no reasonable expectation
that most validators will respect their request, why would they make such a
request (other than in ignorance). I think very few would argue that using
percent is a long term strategy for any given domain. Either percent is
useful or it is not.

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2021 17:09:43 -0400

>percent is a long term strategy for any given domain. Either percent is

Considering how little it's used, I think we have decided that it's not.

Has anyone ever used it the way originally anticipated, set it to 10% on Monday,
look for trouble, 20% on Tuesday, look for more trouble, ... ?

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Jul 2021 17:10:23 -0400

> compatibility become tenuous. If a sender has no reasonable
> expectation that most validators will respect their request, why would
> they make such a request (other than in ignorance). I think very few
> would argue that using percent is a long term strategy for any given
> domain. Either percent is useful or it is not.

I don't understand what you're objecting to: the whole point of
deprecation is to tell the sender not to make the request.  Backward
compatibility is purely on the receiver -- are there still enough old
senders who haven't updated their software, such that it's worth
supporting PCT if I receive it... or are the consequences of my
ignoring it such that it doesn't matter?  That's up to the judgment of
the receivers.

If we deprecate it, compliant senders will simply stop sending it.
Which is what it seems that we want.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Jul 2021 14:22:41 -0700

On 7/20/2021 1:13 PM, Barry Leiba wrote:
> might move to no longer include suppor

This is a natural, and considerate, model.  In the Internet, I believe 
it also has been shown not to work.  Really.

If something is to be removed from a protocol, it needs to be removed.  
So, remove it.

If there is a concern about noting the removal, add an appendix that 
references the removed feature, explaining why it was removed, and 
citing the previous specification.

Do NOT make it 'deprecated'. Don't continue it's specification. Do NOT 
make its use optional.  Make its use a matter of private choice, beyond 
the four walls of the public protocol specification.

"Deprecated" makes things complicated and conditional.  Neither of those 
are protocol attributes to aspire to.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2021 22:04:13 -0400

>If something is to be removed from a protocol, it needs to be removed.  

Since you're supposed to ignore unknown tags in the DMARC record, that seems
straightforward enough.

I suppose we should have a Former DMARC Tags registry to prevent them
from being recycled with a different meaning.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Jul 2021 19:45:32 -0700

> from being recycled with a different meaning.

Or keep the current entry, changing the specification citation to NONE, 
or even just keep the existing one.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: tjw ietf <[email-masked]>
Date: Tue, 20 Jul 2021 23:47:23 -0400

I like Dave’s idea here about leaving them changing their value to none. 

Sent from my iPhone

> On Jul 20, 2021, at 22:45, Dave Crocker <[email-masked]> wrote:
> 
> Or keep the current entry, changing the specification citation to NONE, or even just keep the existing one.
> 
> d/
> 
> -- 
> Dave Crocker
> [email-masked]
> 408.329.0791
>

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2021 00:25:56 -0400

Seems like a reasonable way to do it.

Please consider the environment before reading this message.
John Levine, [email-masked] 

> On Jul 20, 2021, at 23:47, tjw ietf <[email-masked]> wrote:
>

---

From: Laura Atkins <[email-masked]>
Date: Wed, 21 Jul 2021 09:28:36 +0100

This is going to cause difficulties in deployment for a lot of companies and domains. Experience tells us that p=quarantine pct=0 detects forwarders and other types systems that modify and break DMARC authentication. These systems are undetectable when p=none is in place. 

I understand and support removing PCT 1 - 99, but think that removing pct=0 will make it even more difficult for companies to deploy DMARC. 

larua 

> On 20 Jul 2021, at 17:39, Dave Crocker <[email-masked]> wrote:
> 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Douglas Foster <[email-masked]>
Date: Wed, 21 Jul 2021 07:03:16 -0400

Barry's comment:

When we use P=REJECT, we assert that anything which cannot be confirmed is
unacceptable.   That makes for two pretty disjoint groups.   If
Authentication is only to be used to validate a whitelisting decision, then
a one-sided test would be sufficient.   In practice, the primary use for
DMARCv1 is to block messages, and much of our discussion has been around
the unwanted disposition that this places on mailing lists.

DKIM treats an invalid signature as non-existent.   It also treats a DKIM
signature as fully optional.   DMARCv1 changes the rules to gather more
usable information from the message.    DMARCv1 with P=REJECT says that a
message which lacks authentication is unacceptable, and since any message
might be forwarded, it has effectively made DKIM non-optional..  So we have
already modified the interpretation of DKIM.

I have observed that IF the domain owner indicates that all messages
originate with DKIM signatures, then the presence of a signature is no
longer optional at the evaluation point.    As I have said previously, this
provides a valid basis for partitioning messages between verified,
ambiguous, and repudiated.   If you accept the premise that mailing list
messages should not always be repudiated, then nothing we have done up to
this point has provided a reliable way to repudiate.   I am saying that
this is a problem that we can fix.

Upward Compatibility

Yes, I have gone radical, and I am no longer willing to be limited by the
design limitations of DMARCv1.   While DMARCv1 was apparently a
great success for PayPal, I perceive it as a failure when implemented
generally:

·         DMARCv1 has a significant problem with mailing lists, and the
mailing list interest has been well represented in this group.   Until my
proposal, the mailing list problem remained poorly addressed, even with ARC.

·         DMARCv1 has poor implementation support.   I remember someone
presenting a statistic to this group that only 6% of DMARC policies are
enforceable (p=reject or quarantine).    If this is even close to correct,
after 10 years of DMARCv1, it suggests a significant failure to capture the
affection of domain owners.

·         DMARCv1 has poor product support.   Many lower-end email
filtering products do not implement DMARC at all, which is not terribly
surprising.   But several high-end solutions implement DMARC enforcement
within their filter for incoming mail, while implementing DMARC violations
within their secure webmail product for outbound mail.   In-between these
extremes are some products that implement DMARC without adequate exception
methods, so the first false positive will require the feature to be
disabled.

I am no longer prepared to put window dressing on DMARCv1.   We need
DMARCbis to have a better design.

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2021 13:19:28 -0400

It appears that Laura Atkins  <[email-masked]> said:
>-=-=-=-=-=-
>
>This is going to cause difficulties in deployment for a lot of companies and domains. Experience tells us that p=quarantine pct=0 detects forwarders
>and other types systems that modify and break DMARC authentication. These systems are undetectable when p=none is in place. 

I can see how that would be useful to help debug your mailing list software but it's not so clear
how you use it as a sender.

Is the idea that you see a bunch of fails in the report that look like lists, then turn on pct=0
and see if they go away?

I suppose we could leave pct=0 as a hint to forwarders to turn on their DMARC evasion hacks.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Jul 2021 10:24:35 -0700

On 7/21/2021 1:28 AM, Laura Atkins wrote:
> This is going to cause difficulties in deployment for a lot of 
> companies and domains. Experience tells us that p=quarantine pct=0 
> detects forwarders and other types systems that modify and break DMARC 
> authentication. These systems are undetectable when p=none is in place. 

How is this 'detection' actually used?  That is, what is then done 
differently?

> I suppose we could leave pct=0 as a hint to forwarders to turn on their DMARC evasion hacks.

Why doesn't seeing DMARC as seeing that it isn't p=none outght to 
suffice for that?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 21 Jul 2021 19:26:21 +0200

On Wed 21/Jul/2021 10:28:36 +0200 Laura Atkins wrote:
> [deprecate PCT entirely] is going to cause difficulties in deployment for a
> lot of companies and domains. Experience tells us that p=quarantine pct=0

+1, although some DMARC records in the wild betray a poor understanding of how it works, pct is a useful ratchet and we should keep it.

> I understand and support removing PCT 1 - 99, but think that removing pct=0 
> will make it even more difficult for companies to deploy DMARC.

My main objection to removing pct 1-99 is that it would make for a nasty wording, not to mention the hassle of backward compatibility.  (Didn't we say we're not going to make DMARCv2?)

Indeed, since pct=100 is the default, what would we use for pct=0?  Just-kidding=1?

In addition, since I cash domain data and have a sample of 121,329 domain records, 5,980 (~4.9%) of which have a DMARC record, I can try to answer the question that John asked yesterday at 5pm.  Some domains do seem to evolve their pct.  I found 214 domains having a two-digit pct.  It is only ~3.6% of DMARC records, but, if you concede any statistical relevance to my data, it proves that the pct feature is more or less as important to DMARC as DMARC itself is important to email in general.  That is, by domain numbers, even if it is not so important, oversimplifying feels like throwing the baby out with the bathwater.

Of those 214 domains experimenting with pct, 115 (~53.7%) did not change it yet, 51 (~23.8%) failed to serve a DMARC record, 43 (~20%) raised it to full percentage, and 5 (~2.3%) played other changes.  Change details are as follows, newest to oldest:

umn.edu                       had      pct=0  on 2021-07-21 15:54:31,  now    pct=100
constantcontact.com           had     pct=10  on 2021-07-21 05:30:27,  now    pct=100
nannyjob.co.uk                had     pct=50  on 2021-07-20 21:06:47,  now    default
mailerlite.com                had      pct=5  on 2021-07-20 16:48:01,  now    pct=100
kernel.org                    had      pct=1  on 2021-07-18 20:25:34,  now    default
db.com                        had     pct=15  on 2021-07-14 16:12:38,  now     pct=25
developers.italia.it          had      pct=5  on 2021-07-13 19:19:45,  now    default
revfr.today                   had     pct=30  on 2021-07-12 16:29:08,  now  not found
caser.today                   had     pct=30  on 2021-07-12 05:31:20,  now  not found
ericsson.com                  had      pct=0  on 2021-07-08 10:53:37,  now    default
crif.com                      had     pct=25  on 2021-07-06 14:28:33,  now    default
p-a-finbergadvisor.com        had      pct=1  on 2021-06-10 11:10:28,  now    default
economiasviluppo.com          had      pct=1  on 2021-06-07 22:07:50,  now    default
medody.com                    had     pct=40  on 2021-05-22 15:19:27,  now  not found
pafinberg.net                 had      pct=1  on 2021-05-21 09:07:51,  now    default
xss.de                        had      pct=1  on 2021-05-20 23:35:57,  now    default
paddle.com                    had      pct=5  on 2021-05-02 15:39:05,  now    pct=100
dnswl.org                     had     pct=25  on 2021-04-27 19:50:49,  now    default
rusoil.net                    had      pct=1  on 2021-04-22 20:35:12,  now    default
qa.jcb.co.jp                  had     pct=50  on 2021-03-12 17:58:04,  now    default
rni.com.pk                    had      pct=0  on 2021-03-11 04:00:07,  now  not found
cloudflare.com                had     pct=25  on 2021-03-08 17:50:09,  now    pct=100
nw.mailzaap.com               had      pct=5  on 2021-02-22 17:58:45,  now  not found
nw.risparmisubito.it          had      pct=5  on 2021-02-14 07:53:21,  now  not found
nw.promopremium.eu            had      pct=5  on 2021-02-13 14:54:37,  now  not found
nw.scontiok.com               had      pct=5  on 2020-12-15 16:05:54,  now  not found
hw.ac.uk                      had      pct=5  on 2020-11-30 17:32:15,  now    default
karta.website                 had     pct=30  on 2020-11-25 04:55:33,  now  not found
veicolimilano.it              had      pct=1  on 2020-10-07 02:02:26,  now    default
jagoanhosting.com             had     pct=80  on 2020-09-25 02:42:44,  now    default
vshosting.cz                  had      pct=1  on 2020-08-11 18:05:14,  now    default
techno-digm.com               had      pct=1  on 2020-08-05 08:45:36,  now  not found
nw.graziepromo.com            had      pct=5  on 2020-08-04 09:09:04,  now  not found
outreach.rehab4addiction.uk   had     pct=50  on 2020-07-31 10:09:39,  now     pct=20
xyonet.com                    had      pct=5  on 2020-07-30 22:57:33,  now    default
hanoi.gov.vn                  had     pct=20  on 2020-06-17 01:54:54,  now    default
silvanaeditoriale.it          had     pct=50  on 2020-05-08 17:22:06,  now     pct=25
hale.com.hk                   had     pct=90  on 2020-02-26 14:37:42,  now  not found
pasteur-cayenne.fr            had      pct=5  on 2019-12-27 04:27:44,  now     pct=90
nw.mailrogue.com              had      pct=5  on 2019-11-21 20:34:34,  now    default
delivery-571.info             had     pct=40  on 2019-11-10 12:31:25,  now  not found
opensystems.co.bw             had     pct=60  on 2019-10-17 01:26:10,  now  not found
pafinberg.com                 had     pct=20  on 2019-10-09 17:29:32,  now    default
efaxreceive.xyz               had     pct=40  on 2019-09-23 15:58:07,  now  not found
gameview.my                   had     pct=20  on 2019-09-18 07:58:00,  now  not found
nationizable.icu              had     pct=40  on 2019-09-02 17:16:37,  now  not found
designifican.icu              had     pct=40  on 2019-08-09 20:02:11,  now  not found
maersk.com                    had      pct=1  on 2019-07-17 09:03:42,  now    default
mebnet.net                    had     pct=20  on 2019-06-28 04:33:46,  now    default
qlc.in                        had      pct=5  on 2019-06-04 00:21:26,  now    default
primefinance.com              had     pct=15  on 2019-05-23 18:48:43,  now    default
corrlinks.com                 had     pct=25  on 2019-02-21 10:51:27,  now    default
0086.info                     had      pct=5  on 2019-02-03 17:30:23,  now  not found
studio-im.com                 had      pct=5  on 2019-01-24 13:39:42,  now  not found
crowdselector.eu              had     pct=40  on 2018-11-06 12:06:59,  now  not found
eehmke.de                     had     pct=25  on 2018-10-16 13:52:43,  now    default
learningcompass.ga            had     pct=50  on 2018-07-24 16:00:08,  now  not found
women.it                      had      pct=2  on 2018-05-30 17:48:18,  now  not found
ucdavis.edu                   had      pct=5  on 2018-04-29 04:19:01,  now    default
nasaprolifeone.com            had     pct=30  on 2018-02-20 03:30:01,  now  not found
korrumpedia.org               had     pct=30  on 2018-02-17 00:56:57,  now  not found
nasaprolifeadmin.com          had     pct=30  on 2018-02-15 23:59:32,  now  not found
campaniaorlreaders.com        had     pct=30  on 2018-02-15 22:47:03,  now  not found
campaniaorlreader.com         had     pct=30  on 2018-02-15 18:18:45,  now  not found
emailepost.com                had     pct=30  on 2018-02-15 14:36:54,  now  not found
servicepost.net               had     pct=30  on 2018-02-14 05:46:13,  now  not found
ipostica.com                  had     pct=30  on 2018-02-14 03:02:30,  now  not found
postaname.net                 had     pct=30  on 2018-02-13 16:48:51,  now  not found
nasaprolife.com               had     pct=30  on 2018-02-13 14:01:46,  now  not found
nuovoemail.net                had     pct=30  on 2018-02-13 12:38:22,  now  not found
postaspa.com                  had     pct=30  on 2018-02-07 04:22:28,  now  not found
polinpdg.ac.id                had     pct=10  on 2018-02-06 03:06:29,  now  not found
popularanimal.net             had     pct=30  on 2018-01-24 19:31:14,  now  not found
bnl.gov                       had     pct=10  on 2018-01-24 02:12:25,  now    pct=100
mail1.datongcloud.com         had     pct=50  on 2018-01-12 18:25:53,  now  not found
hulusungaitengahkab.go.id     had     pct=20  on 2018-01-01 04:08:33,  now    default
haladzhi.com.ua               had     pct=30  on 2017-11-24 01:59:41,  now  not found
demmarkita2.com               had     pct=20  on 2017-10-18 13:56:23,  now  not found
lada-date-brides.com          had     pct=30  on 2017-10-11 05:13:01,  now  not found
know.kiev.ua                  had     pct=30  on 2017-10-09 14:10:39,  now  not found
opentext.com                  had     pct=10  on 2017-09-28 22:43:18,  now    default
modernposta.net               had     pct=30  on 2017-09-25 15:29:03,  now  not found
stratoplan.ru                 had      pct=5  on 2017-09-18 04:56:28,  now    default
etc-brainwork-sev.com         had     pct=30  on 2017-09-12 21:52:19,  now  not found
aabl.in                       had     pct=50  on 2017-08-27 15:41:27,  now  not found
voxel.larrylarson.com.br      had      pct=5  on 2017-08-24 17:25:42,  now  not found
framestore.com                had      pct=6  on 2017-08-23 10:09:28,  now    pct=100
eu.org                        had     pct=10  on 2017-07-25 19:42:09,  now    default
terradox.ro                   had      pct=5  on 2017-07-03 07:35:55,  now  not found
macsales.com                  had      pct=0  on 2017-06-22 19:46:57,  now    pct=100
opayq.com                     had      pct=0  on 2017-06-09 12:44:37,  now     pct=10
ipoggioli.site                had      pct=0  on 2017-03-08 12:21:11,  now  not found
td-gratis.ru                  had     pct=25  on 2016-11-20 00:05:54,  now  not found
lqfconos.com                  had      pct=1  on 2016-10-24 20:00:38,  now    default
systemcentral.net             had      pct=1  on 2016-09-16 16:01:07,  now    default
spectranet.in                 had     pct=50  on 2016-03-14 11:38:23,  now  not found
unimelb.edu.au                had     pct=10  on 2016-02-28 02:36:47,  now    default
savages.com                   had      pct=5  on 2015-11-23 19:50:55,  now    default
waltermoreno.com              had      pct=1  on 2015-05-02 22:09:08,  now  not found

Best
Ale
--

---

From: Laura Atkins <[email-masked]>
Date: Wed, 21 Jul 2021 18:26:46 +0100

> On 21 Jul 2021, at 18:19, John Levine <[email-masked]> wrote:
> 

We discussed this on the phone call. We’ve discussed this on the list. You can see the summary of the notes from the call in the message from Barry with the subject line [dmarc-ietf] Notes from DMARC interim teleconference, 27 May 2021. You can also review the list archives for previous discussions of this and why pct=0 is important for deployment. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Laura Atkins <[email-masked]>
Date: Wed, 21 Jul 2021 18:30:23 +0100

> On 21 Jul 2021, at 18:24, Dave Crocker <[email-masked]> wrote:
> 
> How is this 'detection' actually used?  That is, what is then done differently?

Please review the list archives for previous discussion of why p=0 is important. 

The part of the message you clipped indicates I was specifically commenting on removing pct=0, which group consensus from May 27 says we keep. If it’s possible to remove 1 - 99 that gets a +1 from me.

> Why doesn't seeing DMARC as seeing that it isn't p=none outght to suffice for that?

There was a long discussion on this list at the end of 2020 describing why pct=0 is an important step in deployment. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 21 Jul 2021 19:41:59 +0200

On Wed 21/Jul/2021 19:24:35 +0200 Dave Crocker wrote:
> Why doesn't seeing DMARC as seeing that it isn't p=none ought to suffice for 
> that?

Some lists operate the evasion hack, a.k.a. From: munging, only if the sender 
has p=quarantine or p=reject, some do it unconditionally, some only if the mail 
is outbound, some only if the receiver is mail.ru.  Behavior doesn't seem to be 
settled yet.

We should add a section on From: munging in the spec.

Best
Ale
--

---

From: Matthäus Wander <[email-masked]>
Date: Wed, 21 Jul 2021 20:05:41 +0200

Alessandro Vesely wrote on 2021-07-21 19:41:
> Some lists operate the evasion hack, a.k.a. From: munging, only if the 
> sender has p=quarantine or p=reject, some do it unconditionally, some 
> only if the mail is outbound, some only if the receiver is mail.ru.  
> Behavior doesn't seem to be settled yet.
> 

It's explained as mitigation in RFC7960:
<https://datatracker.ietf.org/doc/html/rfc7960#section-4.1.3.1>

What's seems to be missing is a recommendation to not change DMARC 
validation behavior subject to p= or other conditions. A conditional 
validation makes p=none less useful for monitoring of potential delivery 
problems.

Regards,
Matt

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Jul 2021 15:00:12 -0400

> When we use P=REJECT, we assert that anything which cannot be
> confirmed is unacceptable.   That makes for two pretty disjoint
> groups.   If Authentication is only to be used to validate a
> whitelisting decision, then a one-sided test would be sufficient.   In
> practice, the primary use for DMARCv1 is to block messages, and much
> of our discussion has been around the unwanted disposition that this
> places on mailing lists.

Indeed; there is definitely a problem between DMARC's p=reject and
mailing lists.

> DKIM treats an invalid signature as non-existent.   It also treats a
> DKIM signature as fully optional.   DMARCv1 changes the rules to
> gather more usable information from the message.    DMARCv1 with
> P=REJECT says that a message which lacks authentication is
> unacceptable, and since any message might be forwarded, it has
> effectively made DKIM non-optional..  So we have already modified the
> interpretation of DKIM.

Here, again, I disagree with your premise: we have not modified the
interpretation of DKIM.  Senders still decide whether to sign with
DKIM or not, and you're correct that it's a poor quality deployment to
use p=reject (or even quarantine) without also deploying DKIM signing.
But the interpretation has not changed: a valid DKIM signature still
means the same as it always did, and the absence of a valid DKIM
signature still means the same as well.  We have not created -- and
must not create -- an additional state that has been proscribed for a
number of good reasons.

> longer optional at the evaluation point.    As I have said previously,
> this provides a valid basis for partitioning messages between
> verified, ambiguous, and repudiated.   If you accept the premise that
> mailing list messages should not always be repudiated, then nothing we
> have done up to this point has provided a reliable way to repudiate.
> I am saying that this is a problem that we can fix.

It does not provide such a valid basis.  With your proposal, any
attacker can move her message from "repudiated" to "ambiguous" simply
by attaching a fake DKIM signature that she knows will never validate.
That alone is a reason this plan won't work.

> Yes, I have gone radical, and I am no longer willing to be limited by
> the design limitations of DMARCv1.

I think that's a fine approach, but it has to come with proposals that
do not violate the other protocols that we're relying on.

Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 22 Jul 2021 20:32:01 +0200

On Wed 21/Jul/2021 20:05:41 +0200 Matthäus Wander wrote:
>> has p=quarantine or p=reject, some do it unconditionally, some only if the 
>> mail is outbound, some only if the receiver is mail.ru. Behavior doesn't seem 
>> to be settled yet.
>>
> What's seems to be missing is a recommendation to not change DMARC validation 
> behavior subject to p= or other conditions. A conditional validation makes 
> p=none less useful for monitoring of potential delivery problems.

I agree that it's easier to deal with From: munging when it's done uniformly on 
all messages.  However, I'm not sure whether to actually RECOMMEND to do so.

How about something more or less like the following?

     *Mailing Lists*

     Mailing lists are characterized by changing the bounce address
     (RFC5321.MailFrom) on forwarding, see SMTP ([RFC5321]).  Described in
     Internet Mail Architecture ([RFC5598]) as a kind of Mediators, several
     mailing lists do additional changes that break most original DKIM
     signatures.  Before DMARC, this wasn't a problem.  As DMARC becomes more
     widely supported and generic mailbox providers public strict DMARC
     policies, mitigation as described in Interoperability Issues between DMARC
     and Indirect Email Flows ([RFC7960]) becomes necessary.

     We RECOMMEND that mailing list managers (MLMs) change the From: address
     (RFC5322.From) in order to become the owner of the main DMARC identifier.
     For example, if the incoming message has:

         From: Original Author <[email-masked]>

     then the forwarded message SHOULD change it, for example like so:

         From: Original Author via list-tag <[email-masked]>

     See [RFC7960] for a full explanation of whys and hows.

     For uniform behavior, MLMs are better off applying the same mitigation
     technique irrespective of the current content of any DMARC records.
     However, some MLMs are known to decide whether to apply that change or
     not based on the existence of an author's domain DMARC record and the
     value of the "p" tag therein.  In any case, MLMs MUST NOT consider the
     value of the "pct" tag in order to make such decision.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2021 14:51:05 -0400

It appears that Alessandro Vesely  <[email-masked]> said:
>all messages.

Lists change messages in all sorts of ways, not just for DMARC, and if
you want to try to unmunge them (mostly a losing battle in my
experience) you end up with an ever growing list of patterns and
replacements.

>  However, I'm not sure whether to actually RECOMMEND to do so.

That's simple: no.  I can't imagine why we would expect list operators to take list
management instructions from the people who screwed up their lists in the first place.

Also remember that ARC is supposed eventually to remove the need for anti-DMARC munging.

R's,
John

---

From: Дилян Палаузов <[email-masked]>
Date: Thu, 22 Jul 2021 21:56:42 +0300

Hello Ale,

please explain why this recommendation is done …

>      value of the "pct" tag in order to make such decision.
by appending:

The reason is, that operators can verify the correct setup, before
switching to a strict DMARC policy.  After installing “pct=0;p=reject"
the domain owner can verify by reading the aggregate reports that 100%
of the messages from the owned domain have aligned DKIM.  (Otherwise
MLM-NOT-mаngled messages will be reported as failed, too).

See also the last paragraph of 
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-02#section-6.7.4.2
Shortcomings of the "pct" Tag
      certain "p=" values to alter DMARC processing and/or reporting
for
<<<

I think this paragraph needs to be changed.  Proposed new wording:

*  "0" - A request that zero percent of messages producing a DMARC
"fail" result have the specified policy applied.  While this is
seemingly a nonsensical request, MLM modifying the message shall
rewrite the From: header in this case.  This way the initial domain
owners, by evaluating aggregate reports, can verify, that their setup
is correct, before enforcing strict DMARC policy.

Greetings
  Дилян

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 22 Jul 2021 21:23:04 +0200

> experience) you end up with an ever growing list of patterns and

Yeah, for example X-Mailman-Original-DKIM-Signature.  It still seems to be 
manageable, though.

> management instructions from the people who screwed up their lists in the first place.

:-)

Yet, From: munging itself resulted from cooperation between dmarcers and MLM 
people, didn't it?

> Also remember that ARC is supposed eventually to remove the need for anti-DMARC munging.

What I imagine can happen is that receivers who can work out how to trust ARC 
will unmunge messages based on Original-From:, Author:, or similar field when 
ARC validates it.  Unmunging based on undoing list changes is an alternative. 
Neither method seems to reliably work every time for every one.  Therefore, 
From: munging is going to stay.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 22 Jul 2021 15:51:25 -0400

On Thu, 22 Jul 2021, Alessandro Vesely wrote:
>> That's simple: no.

> Yet, From: munging itself resulted from cooperation between dmarcers and MLM 

No, it came from AOL and Yahoo unilateraly using DMARC to outsource the 
cost of their security breaches, with the entirely predictable (and 
predicted) effect of breaking every mailing list in the world.  List 
operators had to scramble and come up with some hack to mitigate the 
damage when I became clear that AOL and Yahoo did not care.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 23 Jul 2021 12:08:16 +0200

On Thu 22/Jul/2021 21:51:25 +0200 John R Levine wrote:
> No, it came from AOL and Yahoo unilaterally using DMARC to outsource the cost of 
> their security breaches, with the entirely predictable (and predicted) effect 
> of breaking every mailing list in the world.  List operators had to scramble 
> and come up with some hack to mitigate the damage when I became clear that AOL 
> and Yahoo did not care.

That certainly was the efficient cause of the trouble.  But you must remember 
that the possible solutions were discussed on this list with MLM participants a 
few years ago.  For example:

https://mailarchive.ietf.org/arch/msg/dmarc/KvSFv66Mz8UipXQ0477UgO5WKio/

Best
Ale
--

---

From: Benny Pedersen <[email-masked]>
Date: Fri, 23 Jul 2021 14:23:01 +0200

> https://mailarchive.ietf.org/arch/msg/dmarc/KvSFv66Mz8UipXQ0477UgO5WKio/

all this is solved if maillists stop dkim signing of non origination 
postings and only do the arc sealing so all dmarc testers can see 
originating spf, dkim pass

take sendgrid, thay forwarded netflix phishing emails, and thay belived 
dmarc protected there ignorance to some kind out off there services

never trust a forwarding server that does there own dkim signing, period

dmarc needs openARC testing to all above to work, then maillist can 
break maillists to there own stupid needs without breaking dkim cant be 
verified on dmarc recipient servers

hope the best for the future

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 24 Jul 2021 12:23:11 +0200

On Fri 23/Jul/2021 14:23:01 +0200 Benny Pedersen wrote:
> all this is solved if maillists stop dkim signing of non origination postings 
> and only do the arc sealing so all dmarc testers can see originating spf, dkim 
> pass

ARC doesn't exclude DKIM.  Actually, the latter has a larger use base and it 
would be an error to stop supporting it.

> take sendgrid, thay forwarded netflix phishing emails, and thay belived dmarc 
> protected there ignorance to some kind out off there services
> 

We always knew that verified authenticity wouldn't imply trust, irrespective of 
forwarding.

> dmarc needs openARC testing to all above to work, then maillist can break 
> maillists to there own stupid needs without breaking dkim cant be verified on 
> dmarc recipient servers

ARC is not a part of DMARC, despite the acronym being a substring.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Sun, 25 Jul 2021 13:28:12 -0400

> Ale said:
"ARC is not a part of DMARC, despite the acronym being a substring."

Is this really true?  Some time ago, the chairs said that ARC was the
candidate solution to the mailing list problem, and that DMARCbis would not
fly without a mailing list solution.  More recently, we seem to be
proceeding with a plan to leave the based design of DMARCv1 untouched, with
all of its limitations.   So perhaps the politics have changed.

I have tried to fall in love with ARC, without success.   I have not seen
anyone describe an algorithm for parsing an ARC chain to draw a
conclusion, although the effort seems to require an extraordinary amount of
software development and processing effort.  Having the outlines of this
algorithm seems important, if we expect both implementers and evaluators
for ARC.

But even with an algorithm, the goal seems elusive.  Since any liar can
start an ARC chain and insert a set of unverifiable A-R assertions, it
seems that trusting an ARC set requires prior knowledge of whom to trust,
and when that information is available, ARC chain evaluation becomes
redundant.

Doug Foster

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 26 Jul 2021 10:38:00 +0200

On Sun 25/Jul/2021 19:28:12 +0200 Douglas Foster wrote:
> Is this really true?  Some time ago, the chairs said that ARC was the candidate 
> solution to the mailing list problem, and that DMARCbis would not fly without a 
> mailing list solution.

The mailing list solution that seems to be emerging is From: munging.  There 
are other possibilities, see Section 4.1.3.3 of rfc7960.  A MLM needs to adopt 
a solution that works for all subscribers, not only for the ones whose 
receivers implement DKIM or some other solution-specific protocol.

There are several ways to munge From: in order to minimize end-user 
inconveniences.  Among these, there are cooperative methods that allow 
receivers to unmunge From: on delivery.  The MLM munges From:, which works for 
all, but some of the receivers restore the original From: value based on 
additional authentication techniques.  ARC is one such technique.  MLM 
transformation reversion is another one.

Are such additional authentication techniques, that help repairing DMARC 
damage, themselves part of DMARC?  In a proper sense they're not, in some other 
sense however they have to be.  For example, for questions concerning DMARC 
reports:

* It has been established that ARC data is part of aggregate reports, but it's 
not clear what data is to be included in which reports.

* In what cases should results of MLM transformation reversion be included in 
the aggregate reports destined to the original author domain?

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 26 Jul 2021 12:06:41 -0400

>seems that trusting an ARC set requires prior knowledge of whom to trust,

Yes, that's a problem although in practice, the big mail providers have their
own data to know where the real lists are, and small providers don't get list
mail from all that many sources so it's not too painful to make a manual list.

>and when that information is available, ARC chain evaluation becomes >redundant.

No.  Please review the endless previous discussions of this issue.

R's,
John