Subject: [dmarc-ietf] Ticket #39 - remove p=quarantine

From: "John R Levine" <[email-masked]>
Date: 1 Dec 2020 18:17:01 -0500

We would like to close this ticket by Dec 15, two weeks from now, so short
trenchant comments are welcome.

#39 proposes that we remove p=quarantine.  I propose we leave it in, even if it
is not very useful, because trying to remove it would be too confusing.

R's,
John

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

Is p=quarantine needed?

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 1 Dec 2020 15:55:51 -0800

> is not very useful, because trying to remove it would be too confusing. 

If it is confusing to remove it, it is probably confusing to keep it, 
albeit a different confusion.

Since protocol specifications need to be precise in their semantics, so 
they are understood the same way by both producers and consumers, I 
suspect the issue, here, is a failure to adequately specify the meaning 
or a failure to specify something that is mutually useful and desired.

So rather that be administratively expeditious for the working group 
process, I suggest this issue gets some meaningful discussion.  My email 
archive indicates it hasn't gotten any discussion at all.

Just waving this through because it will be a hassle to deal with it 
invites random differences in its use, and that is death to 
interoperability.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Douglas Foster <[email-masked]>
Date: Tue, 1 Dec 2020 19:16:09 -0500

I have always assumed that p=quarantine and pct<>100 were included to
provide political cover for "Nervous Nellies" who were afraid to enable
p=reject.

As an example, suppose Nellie makes the decision enable p=quarantine and
then goes badly:

If the recipient reports reject instead of quarantine, she can say:   "They
were not supposed to review it!  They did not follow instructions!"

If the recipient reports quarantine as requested, she can say:   "They
agreed to look at it.   We can assume that they will release it to the user
after seeing that the message is innocuous, but the quarantine disposition
decision is not shown in the DMARC reports."

--

As an email gateway administrator, what I reject and what I quarantine will
be determined by my confidence level in my system's risk assessment.
 Sender request will have nothing to do with it.

Pct<>100 is pretty much similar.   A sender can specify pct=20, but that
does not mean that I am going to allow spam into my system 80% of the time
simply to make the sender happy.   Nonetheless, p=quarantine and pct=20
might allow some organizations to move away from p=none, thinking that they
are taking "baby steps", and that is a good thing.

Disabling a deployed feature is a big deal.   Leaving it deployed is a
useful ruse to promote deployment.   I favor leaving both mechanisms in
place.

Doug Foster

On Tue, Dec 1, 2020 at 6:56 PM Dave Crocker <[email-masked]> wrote:

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

---

From: Steven M Jones <[email-masked]>
Date: Tue, 1 Dec 2020 17:42:45 -0800

On 12/1/20 4:16 PM, Douglas Foster wrote:
> provide political cover for "Nervous Nellies" who were afraid to 
> enable p=reject.

p=none, p=quarantine, and the pct= option were all included so that 
organizations could set policies according to their own risk/reward 
evaluation, including changes to those evaluations over time.

> Pct<>100 is pretty much similar.   A sender can specify pct=20, but 
> that does not mean that I am going to allow spam into my system 80% of 
> the time simply to make the sender happy.

I really hope no casual readers get the impression that DMARC bypasses 
spam filtering. DMARC evaluations are expected to be independent of spam 
evaluations. If there's any overlap here, perhaps it would be for DMARC 
(and/or underlying protocols) to provide reliable domain attribution to 
drive a local policy decision about filtering.

> Leaving it deployed is a useful ruse to promote deployment.   I favor 
> leaving both mechanisms in place.

While I deplore characterizing these policy elements as a "ruse," I 
agree that p=quarantine should be kept.

--S.

---

From: Seth Blank <[email-masked]>
Date: Tue, 1 Dec 2020 18:06:13 -0800

Doug, please keep your arguments focused on the technical merits of the
matter, and do not make dismissive comments about users and their
motivations. Those you refer to as nervous nellies are the domain owners
who this protocol is designed for, many of whom are legitimately worried
about blocking good mail along with bad, especially in complicated
environments. We cannot dismiss a large class of users as being silly just
because their operational experience or business needs are different than
our own.

Seth, as Chair

On Tue, Dec 1, 2020 at 4:16 PM Douglas Foster <
[email-masked]> wrote:

> If the recipient reports reject instead of quarantine, she can say:
>  "They were not supposed to review it!  They did not follow instructions!"
>
> As an email gateway administrator, what I reject and what I quarantine
> will be determined by my confidence level in my system's risk assessment.

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2020 21:16:51 -0500

>evaluation, including changes to those evaluations over time.

Do you think there was a shared understanding of how p=quarantine
would be implemented? Put the mail in a spam folder? Put it in some
separate place that you can check? (Mimecast does that with some
dubious mail) Put it in the inbox with a warning label?

I have no idea, my mail system just ignores it so I was wondering what
other people do.

R's,
John

---

From: Dotzero <[email-masked]>
Date: Tue, 1 Dec 2020 22:01:53 -0500

> evaluation, including changes to those evaluations over time.

Absolutely agree with Steve on this. The key phrase is "risk/reward
evaluation". As about the first person to publish DMARC records (before the
specification was public), I went straight to p=reject, but I had the
benefit of feedback from participating mailbox providers before we even had
an agreed upon reporting format. Even with that, I missed one oddball
server for both DKIM signing and SPF. The organization I worked for had a
number of heavily abused domains from a direct domain abuse perspective.
None of the mail was going through mailing lists or other intermediaries
other than a very small fraction of a percent going through vanity domains,
etc. My point is that if my circumstances were different I might have gone
through p=quarantine or even stayed there permanently.

> drive a local policy decision about filtering.

DMARC does one thing and one thing only - It mitigates direct domain abuse.
It does not stop spam, phishing or a multitude of other problems.

> agree that p=quarantine should be kept.

Again, I agree with Steve on this.

Michael Hammer

---

From: Steven M Jones <[email-masked]>
Date: Tue, 1 Dec 2020 19:03:49 -0800

> dubious mail) Put it in the inbox with a warning label?

Not in the sense of, "All Receivers should do at least X for 
quarantine." Rather that the Domain Owner is requesting whatever the 
Receiver implements between rejecting the message and putting it in the 
inbox, and is willing to apply. Discussions of this nature usually 
included a recognition - if not a blunt statement - that the Receiver 
will do whatever they deem best in whatever situation was under 
consideration.

So even if the use case of a small Receiver without a quarantine 
function wasn't explicitly mentioned on this or that occasion, they 
would be covered under the, uhm, /force majeure/ clause of Receiver agency.

That "clause" came up a _lot_ ...

--S.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 1 Dec 2020 19:09:35 -0800

> DMARC does one thing and one thing only - It mitigates direct domain 

It mitigates direct domain abuse in the rfc5322.From field.

It doesn't mitigate domain abuse anywhere else.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Tue, 1 Dec 2020 19:41:26 -0800

On 12/1/2020 7:03 PM, Steven M Jones wrote:
> Rather that the Domain Owner is requesting whatever the Receiver 
> implements between rejecting the message and putting it in the inbox, 
> and is willing to apply. 

Yes, but...

The premise that an author domain owner can, in any way, direct the 
message disposition decisions of a receiving system is simply false. 
It's false to a level of silliness, if one adequately considers the 
complete independence of the receiver from the domain owner.

The domain owner can, perhaps, express something about the owner's own 
concerns for mail that fails dmarc, but that's different from saying 
anything about the receiver's decisions about how to respond to those 
expressed concerns.

That is, the language expressing the semantics should be changed to be, 
in a sense, egocentric.  How do I, the domain owner feel about (assess) 
the meaning of a DMARC failure?

I'd frankly recommend changing the labels for these expressions, but 
expect folk to argue that there is too much installed base and 
operational history.  After all, we left "Mail From" in place, even 
after finally realizing it means "Error Return", which is completely 
different...

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2020 23:15:23 -0500

In article <[email-masked]> you write:
>> would be implemented? ...

>inbox, and is willing to apply.

I get that but I'm wondering if there is any consistency in what that turns out to be.

It is easy to explain what rejecting a message means, and pretty easy
to explain do what you would have done if DMARC didn't exist, but that
middle region is murky.

R's,
John

---

From: Laura Atkins <[email-masked]>
Date: Wed, 2 Dec 2020 09:47:56 +0000

> On 1 Dec 2020, at 23:17, John R Levine <[email-masked]> wrote:
> 

p=quarantine is quite useful, particularly for those folks who are trying to get to a p=reject state. 

In practice, senders who publish p=none don’t find all of the indirect mail flows as some mailing lists do nothing to transform the 5322.from address for a p=none policy. Senders have found that when they switch from p=none to p=quarantine pct=0 they regularly find mail that was not failing for a p=none. 

p=quarantine should stay in, especially if the goal is to encourage senders to publish a p=reject. It’s a valuable step in the deployment process. 

laura 

-- 
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: Steven M Jones <[email-masked]>
Date: Wed, 2 Dec 2020 01:55:45 -0800

On 12/1/20 7:41 PM, Dave Crocker wrote:
>> Rather that the Domain Owner is *requesting* whatever the Receiver 

Yes, you are absolutely right. But this is why I wrote "requesting" 
rather than "commanding (with all the guarantees King Canute had when he 
commanded the tide to halt)" -- the latter phrasing is just /slightly/ 
too ponderous even for me... Does "requesting" really imply control over 
the outcome, rather than the expression of a desire?

> operational history.

Ah, now maybe we're getting somewhere. But if you toss that notion out, 
you have to follow up with an example or two. Which labels, and changing 
them in what way?

--S.

---

From: Дилян Палаузов <[email-masked]>
Date: Wed, 02 Dec 2020 13:15:47 +0200

Hello,

On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote:
> > #39 proposes that we remove p=quarantine.  I propose we leave it
> > in, 
> > even if it

This was discussed under the subject “Abolishing DMARC policy
quarantine” in June 2019.  There was no consensus.  SMTP offers this
distinciton and this is mirrored in DMARC.  In particular, senders are
free to publish p=quarantine and receipients are free to interpret it
as p=reject.  Senders can publish p=reject and receivers are free to
interpret it as p=quarantine.

Moreover, some destination addresses do not have the concepts of a
quarantine.  E.g an address that accepts commands for mailing lists
managements.  Such addresses can either accept or reject the message -
there is no quarantine, so interpreting published p=quarantine as
p=reject is feasible.

Recalling the discussion from June 2019 I do not count on any different
consensus, if it the discussion happens here again now.

Greetings
  Дилян

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 2 Dec 2020 12:46:36 +0100

> I have no idea, my mail system just ignores it so I was wondering what

Zdkimfilter writes a prominent comment in the A-R field.  It is up to the MDA 
to interpret it.  The suggested interpretation is to set KEYWORDS='$Junk', 
which some MUAs interpret as displaying the message in some sort of quirks mode.

p=quarantine is a useful option ans should be continued.

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Wed, 2 Dec 2020 08:17:58 -0500

You are absolutely correct. It also doesn't prevent direct domain abuse
when someone uses snail mail.

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Dec 2020 06:09:00 -0800

On 12/2/2020 1:55 AM, Steven M Jones wrote:
>
> hen he commanded the tide to halt)" -- the latter phrasing is just 
> /slightly/ too ponderous even for me... Does "requesting" really imply 
> control over the outcome, rather than the expression of a desire?
>
My point is that I think the language MUST NOT be cast as saying 
anything about receiver behavior.  Rather, it must only talk about the 
domain owner's assessment of message validity, or the like.

> Ah, now maybe we're getting somewhere. But if you toss that notion 
> out, you have to follow up with an example or two. Which labels, and 
> changing them in what way?
>
Well, I share that view of accompanying obligation... when I can.  I 
couldn't think of a reasonable 'hook' for the language, in the previous 
message.

But above, I see I wrote a perspective that might be useful: validity.

So, perhaps, something like:

    *p*: Domain Owner Assessment Policy (plain-text; REQUIRED for policy
    records). Indicates the severity of concern the domain owner has,
    for mail using its domain but not passing DMARC validation. Policy
    applies to the domain queried and to subdomains, unless subdomain
    policy is explicitly described using the "sp" tag. This tag is
    mandatory for policy records only, but not for third-party reporting
    records (see Section 7.1
    <https://tools.ietf.org/html/rfc7489#section-7.1>). Possible values
    are as follows:

        *none*: The Domain Owner offers no expression of concern.

        *quarantine:* The Domain Owner considers such mail to be
        suspicious. It is possible the mail is valid, although the
        failure creates a significant concern.

        *reject: *The Domain Owner considers all such failures to be a
        clear indication that the use of the domain name is not valid. 
        See Section 10.3
        <https://tools.ietf.org/html/rfc7489#section-10.3> for some
        discussion of SMTP rejection methods and their implications.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Dec 2020 06:13:44 -0800

On 12/2/2020 5:17 AM, Dotzero wrote:
> You are absolutely correct. It also doesn't prevent direct domain 
> abuse when someone uses snail mail.

I suppose, with some effort, you could have offered an even less useful 
example.  But since I was being quite serious about the qualification I 
offered and since it's important to be clear about DMARC's scope of 
utility, a more useful example is that DMARC does nothing about use of 
the domain name anywhere else in a message. Not the display name, not 
the Subject line and not the Body.

As mitigation of direct abuse goes, that means that DMARC's scope of 
mitigation is impressively narrow.

For most things involving significant threats, such a narrow effect 
would not comfortably be described with the implication of such a 
broader scope as you (and others) use.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Dec 2020 06:18:22 -0800

On 12/2/2020 3:15 AM, Дилян Палаузов wrote:
>>  My email archive indicates it hasn't gotten any discussion at all. 
> quarantine” in June 2019.

I see that was quite a lengthy thread.  Thanks for the research. My 
assessment was based on looking for the cited ticket number.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Benny Lyne Amorsen <[email-masked]>
Date: Wed, 02 Dec 2020 15:28:41 +0100

Dave Crocker <[email-masked]> writes:

>  p: Domain Owner Assessment Policy (plain-text; REQUIRED for policy
>  records). Indicates the severity of concern the domain owner has, for
>  mail using its domain but not passing DMARC validation. Policy
>  records (see Section 7.1). Possible values are as follows:
>
>  none: The Domain Owner offers no expression of concern. 
>
>  quarantine: The Domain Owner considers such mail to be suspicious. It
>  is possible the mail is valid, although the failure creates a
>  significant concern.
>
>  reject: The Domain Owner considers all such failures to be a clear
>  indication that the use of the domain name is not valid.  See Section
>  10.3 for some discussion of SMTP rejection methods and their
>  implications.

Perhaps, in retrospect, the p= should have had something like the
following values:

none
untrustworthy
invalid

p= mistakenly chose to use the language of receiver actions to describe
what is actually domain-owner judgements. This is unfortunate, since it
risks making the sender believe that it is possible to dictate receiver
policy.

Perhaps new names can be found, and the old ones kept as historical
aliases?

/Benny

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Dec 2020 06:32:09 -0800

> Perhaps new names can be found, and the old ones kept as historical

Yes!  I would deeply wish we could change the vocabulary to something 
like this.

However I'd expect too much persistence, due to operational history.  
Still, it would be really nice if the working group could convince 
itself to specify a better vocabulary.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dotzero <[email-masked]>
Date: Wed, 2 Dec 2020 09:47:07 -0500

> risks making the sender believe that it is possible to dictate receiver
p= DID NOT mistakenly choose to use the language of receiver actions. p=
represents the domain-owner request to the receiver as to the disposition
of messages which fail to validate. Any reading of "concern" is supposition
on the part of yourself or other self appointed interpreters of the mind of
the domain-owner or administrator. The vocabulary is perfectly fine as it
accurately describes the request being made. It makes no attempt to read
the underlying reasoning behind the request because, surprisingly, there is
likely to be a wide range of underlying reasoning behind why various
domains publish the policies they publish. This is an interoperability
standard, not a seance.

Michael Hammer

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Dec 2020 11:08:13 -0800

> domains publish the policies they publish. This is an interoperability

Not sure I agree.

I have long held a quiet dislike for "quarantine" because that has a
particular meaning to milter implementations.  Specifically, milter can
render one of several final results about a message, one of which is
actually called "quarantine".  It means "park this in the queue
indefinitely until a human decides what to do with it."  There's no
indication to the operator that such a job is waiting for review unless one
goes and looks for such things.  The upshot of this is that quarantining in
that environment can become a denial of service attack if I send you enough
messages that end up getting handled that way and your queue disk fills, or
the queue takes an inordinately long time to process because these have
piled up and need to be inspected.

Certainly not all implementers will trip on this (maybe none will) but it's
an argument to me in favor of picking a word or set of words that describe
what the domain owner thinks of the message, rather than what the domain
owner thinks you should do with it.

-MSK (hatless)

---

From: Benny Lyne Amorsen <[email-masked]>
Date: Wed, 02 Dec 2020 23:35:35 +0100

Dotzero <[email-masked]> writes:

> p= DID NOT mistakenly choose to use the language of receiver
> actions. p= represents the domain-owner request to the receiver as to
> the disposition of messages which fail to validate. Any reading of
> "concern" is supposition on the part of yourself or other self
> appointed interpreters of the mind of the domain-owner or
> administrator. [..] This is an interoperability standard, not a
> seance.

Am I particularly thin-skinned for considering this language
inflammatory?

The thing is, domain owners can request anything they want, but why
should anyone listen? Particularly if they are rude about it instead of
asking nicely.

When someone brings up a concern they have and explain why it is of
benefit to either the recipient or the community to take certain
actions, that will likely be heard. However, unexplained edicts are
unlikely to be taken very seriously.

---

From: Dotzero <[email-masked]>
Date: Wed, 2 Dec 2020 23:29:59 -0500

> Am I particularly thin-skinned for considering this language

Your assertion that the drafters of DMARC mistakenly chose the language of
receivers is inflammatory. I don't remember you as part of the group that
developed DMARC. To make assertions regarding what people were thinking
when one wasn't present falls into the same realm as seances.

> should anyone listen? Particularly if they are rude about it instead of

The thing is, Validators and Receivers will do what they will do. It is
important to remember that DMARC only allows for "neutral" statements (no
policy) or negative assertions (quarantine or reject). It does not allow
for positive assertions (deliver my message to the inbox) nor does it allow
assertions for anything except the domain owners own domain) To the extent
that domain owner requests make sense they will be considered and used by
Validators and Receivers. To the extent they don't, they won't be used. It
really is that simple. Would any Validator or Receiver take seriously a
DMARC policy assertion of p=reject based on an SPF record using  *0.0.0.0/0*
-all? Doubtful.

> unlikely to be taken very seriously.

How seriously should someone's "concern" be taken when it is phrased as an
assertion of knowing what was in the minds of people when that someone
wasn't present. That someone might have phrased it as a question rather
than a declarative. As far as unexplained "edicts", quite a few receivers
use SPF/DKIM/DMARC in their calculus as to how they handle mail destined
for their systems. So there is clearly some perceived benefit or they
wouldn't be doing so.

Michael Hammer

---

From: "Jim Fenton" <[email-masked]>
Date: Wed, 02 Dec 2020 21:51:31 -0800

> spam filtering. DMARC evaluations are expected to be independent of 
> spam evaluations. If there's any overlap here, perhaps it would be for 
> DMARC (and/or underlying protocols) to provide reliable domain 
> attribution to drive a local policy decision about filtering.

Agree about not bypassing spam filtering. But not about the 
“independent of spam evaluations” part. Spam filters are going to 
use any message characteristic that they find useful, including whether 
the message is signed, passes SPF, has an aligned From address, has a 
DMARC record of a certain type, etc. to make a decision. It’s what 
spam filters do, and we have no say about that.

-Jim

---

From: "Jim Fenton" <[email-masked]>
Date: Wed, 02 Dec 2020 22:03:24 -0800

On 2 Dec 2020, at 1:47, Laura Atkins wrote:

> In practice, senders who publish p=none don’t find all of the 
> indirect mail flows as some mailing lists do nothing to transform the 
> 5322.from address for a p=none policy. Senders have found that when 
> they switch from p=none to p=quarantine pct=0 they regularly find mail 
> that was not failing for a p=none.

I’m really confused by this. It sounds like the 5322.from address 
rewriting is creating additional errors that didn’t exist beforehand, 
and that’s the opposite of the intended purpose. Isn’t the purpose 
of rewriting the 5322.from address to change the domain to that of the 
mediator, which should redirect reporting to the mediator rather than 
the original sender?

-Jim

---

From: "Jim Fenton" <[email-masked]>
Date: Wed, 02 Dec 2020 22:12:09 -0800

>        discussion of SMTP rejection methods and their implications.

The problem is that _quarantine_ and _reject_ are imperative verbs. The 
specification can use any definition, but if it uses imperative words, 
they are going to be taken as imperative.

Maybe _discardable_ should be used instead.

Why do I have a feeling of deja vu?

-Jim

---

From: Laura Atkins <[email-masked]>
Date: Thu, 3 Dec 2020 09:28:21 +0000

> On 3 Dec 2020, at 06:03, Jim Fenton <[email-masked]> wrote:
> 
> I’m really confused by this. It sounds like the 5322.from address rewriting is creating additional errors that didn’t exist beforehand, and that’s the opposite of the intended purpose. Isn’t the purpose of rewriting the 5322.from address to change the domain to that of the mediator, which should redirect reporting to the mediator rather than the original sender?

What I am trying to say is that as I understand it from the folks who professionally deploy DMARC, they regularly use p=quarantine pct=0 as part of the deployment process. There are DMARC failures that go undetected in a p=none situation but that is detected in a p=quarantine  pct=0 situation.  My understanding was this was related to indirect flows through mailing lists and how mailing lists are handling the header transformation but it’s possible I got that piece incorrect. 

p=quarantine is valuable for other reasons as well, and I think it should be kept. 

laura 

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Dec 2020 04:57:43 -0800

On 12/2/2020 10:12 PM, Jim Fenton wrote:
> The problem is that /quarantine/ and /reject/ are imperative verbs.

As I said, I suspect that changing the vocabulary is not operationally 
practical  at this point.  It would be great for the folk already using 
DMARC to state a willingness to employ alternative vocabulary; but I'm 
not expecting them to.

If we get feedback to the contrary, we can have a vocabulary debate.  My 
own advice would be to avoid vocabulary that is directive about 
disposition and more declarative about status.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Todd Herr <[email-masked]>
Date: Thu, 3 Dec 2020 09:21:44 -0500

On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins <[email-masked]> wrote:

> In practice, senders who publish p=none don’t find all of the indirect
> mail flows as some mailing lists do nothing to transform the 5322.from
> address for a p=none policy. Senders have found that when they switch from
> p=none to p=quarantine pct=0 they regularly find mail that was not failing
> for a p=none.
>
>
> rewriting is creating additional errors that didn’t exist beforehand, and
> that’s the opposite of the intended purpose. Isn’t the purpose of rewriting
> the 5322.from address to change the domain to that of the mediator, which
> should redirect reporting to the mediator rather than the original sender?
>
>
> What I am trying to say is that as I understand it from the folks who
> professionally deploy DMARC, they regularly use p=quarantine pct=0 as part
> of the deployment process. There are DMARC failures that go undetected in a
> p=none situation but that is detected in a p=quarantine  pct=0 situation.
> My understanding was this was related to indirect flows through mailing
> lists and how mailing lists are handling the header transformation but it’s
> possible I got that piece incorrect.
>
>
Time was (and may still be) that there was a very specific type of mailing
list for which p=quarantine, pct=0 was required to get accurate DMARC
reporting, and that was for mail that transited Google groups. There've
been a couple of public discussions of the topic over on mailop, including
a thread from April 2018 with the subject of "DMARC p=quarantine pct=0".

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 703.220.4153

---

From: Michael Thomas <[email-masked]>
Date: Thu, 3 Dec 2020 09:46:13 -0800

On 12/2/20 10:12 PM, Jim Fenton wrote:
>     <https://tools.ietf.org/html/rfc7489#section-10.3
>     <https://tools.ietf.org/html/rfc7489#section-10.3>> for some
> The specification can use any definition, but if it uses imperative 
> words, they are going to be taken as imperative.
>
> Maybe /discardable/ should be used instead.
>
If it's not clear that it's "this is what I'd do" rather than some 
requirements language imperative then maybe that could be made more clear.

> Why do I have a feeling of deja vu?
No comment.

Mike

---

From: Дилян Палаузов <[email-masked]>
Date: Thu, 03 Dec 2020 21:10:51 +0200

Post Scriptum: DMARC can say one of two things:
-- all mails for a domain are DKIM-signed and aligned, according to the
domain owner
-- not all mails for a domain are DKIM-signed and aligned (e.g. when
the DMARC policy is absent, or p=none) according to the domain owner

Does the DMARC specification need to propose what to do with emails in
the first case above, when the DKIM-signature is not-valid/aligned? 
Some people will say yes.  I say no: there is no need to give one of
two possible advices on this (and there is no means to enforce the
advice)

Anyway, as I said I do not expect any consensus on this.

Please consider including in the DMARC specificaiton a discussion on
what is reasonable, e.g as outlined in the email below, and elaborate
pros and cons on r=reject and r=quarantine.

As the topic is controversal, it shall be presented as controversal in
the specification.

I do not follow the discussions here, I suppose that by now is
addressed, that „p=quarantine;pct=0“ should be interperted as „do MLM-
mungling”, and p=none to mean „no MLM mungling”.

⇐⇐⇐⇐⇐
From: Vladimir Dubrovin <[email-masked]>
To: Dotzero <[email-masked]>, Vladimir Dubrovin
<dubrovin=[email-masked]>
CC: IETF DMARC WG <[email-masked]>, Дилян Палаузов
<[email-masked]>
Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Date: Fri, 14 Jun 2019 19:25:02 +0300

Nope, I mean 2 different things. 

1. Why quarantine is useful (with pct=0).  

For example this mailing list ([email-masked]) performs From rewrite
(aka From munging), e.g. [email-masked] is replaced with
dubrovin=[email-masked]. It's because corp.mail.ru has a
strict DMARC policy (reject). [email-masked] is not overwritten,
because gmail.com has p=none and ietf.org only overwrites From only for
domains with "quarantine" and "reject" policies. It's quite common
behavior.

If you are implementing DMARC for a new domain (let's say example.org),
you usually start with "p=none". With p=none you receive reports for
failed DMARC for different lists, like ietf.org. Before switching to
stronger policy (p=reject), you may want to know which mailing list
will still fail DMARC, and which lists perform From munging and, as a
result, do not fail DMARC. For this purpose, before switching to
"p=reject" it's useful to switch to "p=quarantine;pct=0". After this,
you will only see mailing lists without From munging in DMARC reports.

2. Why quarantine should not be used with pct different from 0

If you start enforsing strong DMARC policy with "p=reject" and you have
some previously uncatched misconfiguration (e.g. wrong envelope-from
address in some once-in-the-month mailing), you see DMARC failures  in
your logs and you can react to this failures and even re-send the
messages affected. 
If you start with "p=quarantine" you have no feedback except reports,
and reports are received with a huge lag (up to 2 days) and do not
provide sufficient information to catch the exact problem and you can
not re-send the quarantined messages.

⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒⇒

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2020 17:41:04 -0500

>Why do I have a feeling of deja vu?

Gee, I can't imagine.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Mon, 7 Dec 2020 17:55:15 -0800

On Wed, Dec 2, 2020 at 11:09 AM Murray S. Kucherawy <[email-masked]>
wrote:

> Certainly not all implementers will trip on this (maybe none will) but
> it's an argument to me in favor of picking a word or set of words that
> describe what the domain owner thinks of the message, rather than what the
> domain owner thinks you should do with it.
>

Hmm, reading this thread, I think one missing feature in the dmarc spec is
passing the expected disposition in the authres header, since presumably
the evaluation is at smtp time, but the mailbox
delivery itself would need to know it.  One could use the dmarc= names and
look up the dmarc policy itself to also figure that out with some amount of
work.

I know that Gmail and others put that information in the comments, but that
probably shouldn't be for something explicitly part of the spec like this.

Anyways, +1 to keeping p=quarantine as a concept, but willing to go along
with the consensus on naming.

Brandon

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2020 21:37:44 -0500

>with the consensus on naming.

I'm modestly in favor of keeping p=quarantine as a feature but utterly opposed
to changing the keywords such as "p=quarantine" in the DMARC record.

It's fine to improve the text in the RFC that describes what they mean but let
us please not make gratuitously incompatible changes.

R's,
John

---

From: Дилян Палаузов <[email-masked]>
Date: Tue, 08 Dec 2020 13:24:24 +0200

Hello,

I do no see the point of having all the discussions here, as nobody is
capable to read and understarstand all written emails in their whole
quantity.  I personally do not follow the discussions anymore, apart
from reading the subjects…

On Mon, 2020-12-07 at 17:55 -0800, Brandon Long wrote:
> 
> 
> On Wed, Dec 2, 2020 at 11:09 AM Murray S. Kucherawy
> <[email-masked]> wrote:
> > > actions. p= represents the domain-owner request to the receiver
> > > as to the disposition of messages which fail to validate. Any
> > > reading of "concern" is supposition on the part of yourself or
> > > other self appointed interpreters of the mind of the domain-owner
> > > or administrator. The vocabulary is perfectly fine as it
> > > accurately describes the request being made. It makes no attempt
> > > to read the underlying reasoning behind the request because,
> > > surprisingly, there is likely to be a wide range of underlying
> > > reasoning behind why various domains publish the policies they
> > > publish. This is an interoperability standard, not a seance.
> > > 
> > 
> > 
> > Not sure I agree.
> > 
> > I have long held a quiet dislike for "quarantine" because that has
> > a particular meaning to milter implementations.  Specifically,
> > milter can render one of several final results about a message, one
> > of which is actually called "quarantine".  It means "park this in
> > the queue indefinitely until a human decides what to do with it." 
> > There's no indication to the operator that such a job is waiting
> > for review unless one goes and looks for such things.  The upshot
> > of this is that quarantining in that environment can become a
> > denial of service attack if I send you enough messages that end up
> > getting handled that way and your queue disk fills, or the queue
> > takes an inordinately long time to process because these have piled
> > up and need to be inspected.
> > 
> > Certainly not all implementers will trip on this (maybe none will)
> > but it's an argument to me in favor of picking a word or set of
> > words that describe what the domain owner thinks of the message,
> > rather than what the domain owner thinks you should do with it.
> > 
> 
> 
> Hmm, reading this thread, I think one missing feature in the dmarc
> spec is passing the expected disposition in the authres header, since
> presumably the evaluation is at smtp time, but the mailbox
> delivery itself would need to know it.  One could use the dmarc=
> names and look up the dmarc policy itself to also figure that out
> with some amount of work.

… and in July 2019 there was a discussion with the subject „Reporting
DMARC policy in A-R header fields“ on this mailing lists.    Below is
an off-list consensensus to put the applied policy in the A-R from that
thread, that was not sent eventually over the mailing list:

From: Scott Kitterman <[email-masked]>
To: Дилян Палаузов <[email-masked]>
Subject: Re: Reporting DMARC policy in A-R header fields
Date: Wed, 31 Jul 2019 10:49:32 +0000

I agree with your statement.  MTA does the percentage test and puts the
policy to be applied in A-R for the MDA to consume.

I'm working off my phone, so typing is slow.  I don't mind being more
verbose once I'm at my laptop, but it will have to wait.  Please let me
know if it's still uncertain.

Scott K

On July 31, 2019 10:35:15 AM UTC, "Дилян Палаузов"
<[email-masked]> wrote:
>Hello Scott,
>
>you are too spare in your words.
>
>My understanding of the conversation so far is that only the MTA does
>the sampling for failed messages based on p= and
>pct= . The A-R header is supposed to carry information, whether the
>message validated or failed DMARC and for failed
>validation, what the MDA shall do with the message (basically
>quarantine or deliver).
>
>If you put the policy to be applied in the A-R, then it is not the
>policy from DNS, but rather the disposition to be
>applied.
>
>Regards
>  Дилян
>
>On Wed, 2019-07-31 at 10:28 +0000, Scott Kitterman wrote:
>> I suppose you could also add something like dmarc.pct=50 too, but I
>think that would add complexity to no benefit.  As long as you make
the
>sample decision once, it works out the same.  For the case where a
>message wasn't selected due to sampling then I'd put the policy to be
>applied in A-R so the MDA doesn't have to worry about the percentage.
>> 
>> Scott K
>> 
>> On July 31, 2019 5:56:26 AM UTC, "Дилян Палаузов"
><[email-masked]> wrote:
>> > Hello Scott,
>> > 
>> > for p=quarantine; pct=50 if the MTA does the sampling and decides
>to
>> > quarantine, and forward the email to the MDA, how can the MDA know
>> > whether it shall quarantine the message or not?
>> > 
>> > Regards
>> >  Dilyan
>> > 
>> > On July 31, 2019 1:25:23 AM GMT+03:00, Scott Kitterman
>> > <[email-masked]> wrote:
>> > > Since the status is per message, I think the MTA should do it
and
>> > other
>> > > than as perhaps a comment, it doesn't need to be in A-R.
>> > > 
>> > > Scott K
>> > > 
>> > > On July 30, 2019 2:04:28 PM UTC, "Дилян Палаузов"
>> > > <[email-masked]> wrote:
>> > > > OFF LIST
>> > > > 
>> > > > Hello Scott,
>> > > > 
>> > > > does the PCT value belong to the published policy and subject
>to
>> > > > inclusion in the A-R header?
>> > > > 
>> > > > Who is supposed to apply the sampling, based on PCT parameter:
>the
>> > > MTA,
>> > > > the MDA or both?
>> > > > 
>> > > > If both are supposed to do it, can the A-R header be extended
>in such
>> > > a
>> > > > way, that only the MTA does the sampling, and
>> > > > carries the information to the MDA?
>> > > > 
>> > > > Regards
>> > > >  Дилян
>> > > > 
>> > > > On Tue, 2019-07-30 at 13:56 +0000, Scott Kitterman wrote:
>> > > > > The published policy (that's why I suggest dmarc.policy). 
>I'm not
>> > > > sure if disposition belongs in A-R.  If it does, it'd be a
>local
>> > > policy
>> > > > override, probably policy.dmarc as described now in RFC 8616.
>> > > > > Scott K
>> > > > > 
>> > > > > On July 30, 2019 1:34:46 PM UTC, "Дилян Палаузов"
>> > > > <[email-masked]> wrote:
>> > > > > > Hello Scott,
>> > > > > > 
>> > > > > > do you want to include in the A-R header the published
>policy, as
>> > > > > > obtained from DNS (my first interpretation of your
>> > > > > > proposal), or the disposition of the message after
applying
>> > > > > > DKIM/SPF/DMARC validation, pct sampling, and the ominous
>> > > > > > reject→quarantine sampling conversions?
>> > > > > > 
>> > > > > > With disposition I mean what is called at
>> > > > > > https://tools.ietf.org/html/rfc6591#section-3.2.2
>> > Delivery-Result.
>> > > > > > For the disposition on p=reject only the MTA can make the
>> > decision
>> > > > > > based on pct to reject, so it makes sense if the
>> > > > > > result of disposition is included in the A-R header by the
>MTA
>> > and
>> > > > > > consumed by the MDA.  In turn, including pct and
>> > > > > > published DMARC policy in the A-R header, so that the MDA
>can do
>> > > > the
>> > > > > > sampling, does not make sense.
>> > > > > > 
>> > > > > > If you want to call the new parameter “policy”, then it
>shall be
>> > > > > > articulated that it means disposition, and not
>> > > > > > published policy.
>> > > > > > 
>> > > > > > I am in favour of the proposal.
>> > > > > > 
>> > > > > > It allows for forwarded emails/aliases to indicate in the
>A-R
>> > > > header,
>> > > > > > that sampling was already performed by the
>> > > > > > aliasing server, and the final server that accepts the
>email can
>> > > > skip
>> > > > > > performing the sampling again.  Performing the
>> > > > > > sampling again has the disadvantage, that the pct=
>parameter is
>> > > > > > misinterpreted, as the parameter is supposed to be
>> > > > > > applied only once.
>> > > > > > 
>> > > > > > On the other side, skipping of the second sampling by
>whatever
>> > > > server
>> > > > > > is pure theory, and has no practical impact.
>> > > > > > 
>> > > > > > Greetings
>> > > > > >  Дилян
>> > > > > > 
>> > > > > > On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote:
>> > > > > > > On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman
>wrote:
>> > > > > > > > I'd like to add the option to record DMARC results in
>an A-R
>> > > > header
>> > > > > > field
>> > > > > > > > for consumption by a downstream processor.  I think it
>would
>> > > be
>> > > > > > something
>> > > > > > > > like this:
>> > > > > > > > 
>> > > > > > > > Authentication-Results: mail-router.example.net;
>dmarc=pass
>> > > > > > > > header.from=example.com policy.dmarc=none
>> > > > > > > > 
>> > > > > > > > That would take adding an entry in the Email
>Authentication
>> > > > Methods
>> > > > > > registry
>> > > > > > > > for:
>> > > > > > > > 
>> > > > > > > > method: dmarc
>> > > > > > > > ptype: policy
>> > > > > > > > value: dmarc
>> > > > > > > > 
>> > > > > > > > Does that make sense as a way to do it?  Does anyone
>have
>> > > > > > alternative
>> > > > > > > > suggestions?
>> > > > > > > 
>> > > > > > > I think comments should be free-form.  If we want data
>that can
>> > > > be
>> > > > > > machine 
>> > > > > > > parsed, we should specify it.
>> > > > > > > 
>> > > > > > > I think the above works in ABNF terms.  It's:
>> > > > > > > 
>> > > > > > > Authentication-Results:" authserv-id; method=result
>> > > > > > ptype.property=value 
>> > > > > > > ptype.property=value
>> > > > > > > 
>> > > > > > > According to the ABNF, there can be more than one
>propspec 
>> > > > > > > (ptype.property=value) per methodspec in resinfo, so I
>think
>> > > it's
>> > > > > > legal.  It 
>> > > > > > > would just need the new registry values for dmarc.
>> > > > > > > 
>> > > > > > > Scott K
>> > > > > > > 
>> > > > > > > 

> 
> I know that Gmail and others put that information in the comments,
> but that probably shouldn't be for something explicitly part of the
> spec like this.
> 
> Anyways, +1 to keeping p=quarantine as a concept, but willing to go
> along with the consensus on naming.
> 
> Brandon

---

From: Hector Santos <[email-masked]>
Date: Tue, 08 Dec 2020 12:18:13 -0500

On 12/8/2020 6:24 AM, Дилян Палаузов wrote:> Hello,
> from reading the subjects…

+1 Major Plus One. Its all deja vu.

Optional reading. I'll use this opportunity to express my key summary 
concerns as a long time DKIM and SPF implementation and commercial 
DKIM/SPF product vendor.

FWIW.....

We have a Developer vs Administrative protocol design issue once 
again.  Too many philosophical "Administrative" subjective opinions 
trying to burn their idea into how IETF protocols is written and how 
implementations should behave operationally from an admin standpoint.

The DKIM POLICY model is a simple DNS lookup protocol, like SPF. It 
hasn't change since day one. DMARC is just the current rendition of 
the same thing since SSP - nearly 15 years - plus Reporting which was 
rejected for SSP and ADSP. Unlike SPF, what DKIM POLICY lacked 3rd 
party authorization protocol support.

But we had discussed the idea of using SPF softfails as a way to link 
together with a valid DKIM result. I recall Microsoft was exploring 
this methods as one the early explorers of ADSP. I liked the concept 
and explored it myself by looking at a possible "fuzzy" logic of the 
results, for example:

SPF PASS + DKIM PASS => Result PASS (confidence? 100%)
SPF SOFTWARE + DKIM PASS => Result PASS (confidence? 80%)
SPF NEUTRAL + DKIM PASS => Result PASS (confidence? 50%)
SPF FAIL + DKIM PASS => Result PASS (confidence? 0%, SPF fail preempts 
DKIM?)

But when it came to the new filtering protocols we were development, I 
was more interested in 100% or 0% deterministic protocol results. 
Anything in between is "fuzzy" and imo, can't make hard filtering 
unless we are now learning from the BIAS from Deep AI methods. For 
many, Pareto's 80% may be good enough for a filtering decision.

It is well established, DKIM POLICY works for 1st party signatures. We 
know this since day one.  The proof of concept was long set in stone 
and never to be killed.  We documented it in the early initial DKIM WG 
work productions - Thread Analysis and the Functional specification:

2006 RFC4686.txt  Analysis of Threats Motivating DKIM
2006 RFC5016.txt  Requirements for a DKIM Signing Practices Protocol

DKIM Policy is a powerful concept and in the words of one of the key 
cogs - "Its scary!"   Yes, for direct 1 to 1 private mail, you have a 
very powerful way to protect against domain spoofing in the same way 
SPF protects against unauthorized transports from unknown machines. 
SPF has its "in-direct" issue with routing of transports which I 
called a "Node Transition" point. DKIM was initially marketed as a 
solution to the node transition problem.

The stage was set. SSP with its 3rd party options, defined the ideas 
that a domain, like SPF, can describe which domain(s) can "notarize" 
the email.  But we did not have a way to define the authorized 3rd 
party domain.  The simple idea was to use tag= list, like a Access 
control list, for example

acl=ietf.org, gmail.com

which it reduced the need for another DNS lookup.  The acl= tag works 
for a small well organization network. But it does not scale.  ATPS 
was written to some some like of scalable using a zone record per 3rd 
party authorized domain. ATPS starts with a tag:

atps=1

and if enabled, receiver will check for the signer domain 
authorization ATPS record.   Does it work for all, no.  But it works 
for many and its been in production since 2012.

The DMARC or DKIM Policy protocol payoff does not come from positive 
passed results but rather with failed results because the protocol 
raises the bar by authorizing the receiver to reject or discard or 
quarantine a.k.a filter a message for the sake of the end-user.

Side note: There are four states for mail transport:

- Reject (SMTP does not accept it).
- Accept (user sees it in inbox, may be filtered with other things)
- Accept & Discard (lost to the user)
- Accept & quarantine (move to spam box, outside the main inbox stream)

The p= policy not only should keep quarantine, it should add p=discard

Unfortunately, a key moment came, in RFC5016, section 5. item 10, when 
the beginning of this long 14+ year "fight" with Mailing list 
administrators started, imo.  This was when all the heart aches became 
to occur, the major disagreements between Policy Advocates and Trust 
Advocates.

Read it carefully. Its about local policy (duh), but this last minute 
item provision altered the future of DKIM POLICY. Every since then, we 
had his long debate of DKIM-POLICY Model vs Mailing List Systems.  It 
basically lead to this protocol conclusion:

DKIM POLICY does not work for Mailing List unless the Mailing List 
Server vendors supports and honors the DKIM POLICY model - period. If 
it does not, it will have trouble integrating into a new DKIM with 
optional restrictive policies world.

I know of only one commercial List Software vendor,  Wildcat! List 
Server, that supports the DKIM Policy for Restrictive Policies. It 
does not have the issue with in-direct mail submissions. New 
subscribers from restrictive domains are not allowed to subscribe. If 
already a member of the list, list members from restrictive domains 
can not longer post but they can continue to receive a distribution 
(iow, a read only member).

For a long time, we had folks that believed "list servers" were so old 
in their ways they are not obligated to change or adapt to the DKIM 
policy model. I understand that. Wildcat! List Server is one of the 
older systems around.  Yet, the same folks advocated making 
non-standard provision changes to intentionally ignore restrictive 
DKIM Policies, continue distributing changed and unprotected original 
domain mail by destroying the trust of the mail system by altering the 
"READ-ONLY" field 5322.From.

Anyway, thanks for pointing this out. I second your concern. Its not 
pretty what is going on. I hope key folks with the IETF are made aware 
that this is not normal.

I believe we need to recognize the need for augmented DKIM Policy Tag 
extensions that could do the various Product Support Features some 
people are looking for.

I don't like ARC, too much overhead and its not addressing the key 
lack of authorized 3rd party domain concerns, but if GOOGLE wants to 
push this idea, than the ARC Protocol should extend DMARC with "arc=" 
related tags. I am on the fence of whether DMARCbis should mention 
ARC. I don't think so if its an experimental. I don't think we did 
this for a proposed standard to be referencing experimental work.  But 
in any case, maybe the tag "arc=1: means that it promote SPF or DKIM 
fails?

In theory when combining ARC to SPF and DKIM, we now have:

     SPF(4)+DKIM(2)+ARC(2) == Final Result(16)

There are 16 combinations for SPF, DKIM and ARC states. Some will 
fold, some will not make sense.

I won't argue the WG decision to add ARC to DMARC in some matter.  But 
don't ram it down our throats.  Allow domains to explore with an 
"ARC=1" tag in their DMARC record, then at some point in the future, 
as we learn more, it can be explored.  But imo, we should not speak of 
a DKIM Policy Protocol as if ARC is a natural part of it.

Thanks for reading.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 9 Dec 2020 16:30:19 -0600

On 12/3/20 8:21 AM, Todd Herr wrote:
> On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>>     On 3 Dec 2020, at 06:03, Jim Fenton <[email-masked] <mailto:[email-masked]>> wrote:
>>
> Time was (and may still be) that there was a very specific type of mailing list for which p=quarantine, pct=0 was required to get accurate DMARC reporting, and that was for mail that transited Google groups. There've been a couple of public discussions of the topic over on mailop, including a thread from April 2018 with the subject of "DMARC p=quarantine pct=0". 

p=quarantine pct=0 is a very useful strategy

1) It allowed us to find the mailing lists that don't munge from the From header - which would subsequently be problematic once we moved to pct=100

2) It allowed us to segregate the user complaints.  With a large change initiative you need to reduce the number of uncontrolled variables at any one time.  If we went straight to pct=100 then there would be a mix of people complaining about from munging mixed in with complaints about delivery.  Confusion would ensue and the entire premise of DMARC would have been called into question.  By using an incremental process it's easier to deflect people complaining about the Stage 1 problems after moving to Stage 2.

3) It allowed us to discover email receivers who ignore pct.  It was annoying, but also a convenient gift in disguise, since it allowed us to innocently blame the receiver when non-compliant senders objected to the necessary DMARC adaptations.

Jesse

---

From: Brandon Long <[email-masked]>
Date: Wed, 9 Dec 2020 16:04:51 -0800

> a thread from April 2018 with the subject of "DMARC p=quarantine pct=0".

Right, to be clear what is going on:
Google Groups only does 5322.From rewriting if the domain is p=quarantine
or p=reject, it ignores the value of pct because it can't know whether the
receiver will apply pct or not to that specific message.

It doesn't apply 5322.From rewriting to p=none domains so as to reduce the
amount of rewriting it does.

Because we don't do the rewriting at p=none, the dmarc reports that people
get at p=none will show the messages transiting groups failing dmarc.

When you switch to p=quarantine pct=0, no one should apply quarantine (so
it's equivalent to p=none), but Groups will start rewriting, thereby
removing all of those failures from your reports.  Yes, you won't see those
messages in the reports at all anymore because they are no longer using
your domain.

This isn't ideal, it means reports at p=none for many domains are very
noisy and so harder to use to find what needs to be fixed before going to
p=quarantine.  There's a trade-off between how best to support domains who
are in p=none and making it easier for domains to progress to p=quarantine
and p=reject.

Even without this quirk for Groups, I wouldn't remove pct.  I think
controlled rollouts and not knife-edge changes is good practice.

I see this thread is actually for removing p=quarantine, I'm voting against
removing it.  Even if we think that domains that use DMARC should all
progress to p=reject (or even that most domains should), progressive
changes and rollouts make these things possible, and p=quarantine is a
safer step than p=reject.

There is potentially an argument from the other threads where a domain
owner could instead assign a level to a domain indicating how badly they
think that abuse of the 5322.From of this domain is, and then the RFC could
indicate that receivers SHOULD/MAY treat failures at different threat
levels by rejecting or quarantining messages.  That would definitely lead
to a level of indirection in the progression of changes, since a domain's
threat level doesn't normally change... but adding yet another tag for say
confidence or rollout level on top of pct starts to really seem like
overkill.

lvl=high confidence=medium pct=0

(My mail should be protected, I'm only part way through ensuring that it
is, and this level of confidence is at 0% rollout which is equal to 100% at
the lower level)

Brandon

---

From: Michael Thomas <[email-masked]>
Date: Wed, 9 Dec 2020 17:23:10 -0800

On 12/9/20 4:04 PM, Brandon Long wrote:
>
>
> When you switch to p=quarantine pct=0, no one should apply quarantine 
> (so it's equivalent to p=none), but Groups will start rewriting, 
> thereby removing all of those failures from your reports.  Yes, you 
> won't see those messages in the reports at all anymore because they 
> are no longer using your domain.

Is that what's going on with some of the messages I see on this list? 
That seems pretty awful from a security standpoint. Basically you're 
engineering a lookalike From address attack. The one big disappointment 
from my standpoint is that MUA's don't seem to be using auth-res, etc, 
to do some basic annotation. At least Thunderbird. And I don't recall 
gmail doing anything either.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 10 Dec 2020 09:55:18 +0100

On Thu 10/Dec/2020 02:23:10 +0100 Michael Thomas wrote:
>> it's equivalent to p=none), but Groups will start rewriting, thereby removing 
>> all of those failures from your reports.  Yes, you won't see those messages 
>> in the reports at all anymore because they are no longer using your domain.

There is a reporting feature of mlm-transform that might be worth considering 
apart from any indirect mailflow revival.  By adding an Original-From: header 
field —a copy of From: on the first relay— a domain owner can ask to receive 
aggregate reports even if From: was rewritten by a MLM.

> Is that what's going on with some of the messages I see on this list? That 
> seems pretty awful from a security standpoint. Basically you're engineering a 
> lookalike From address attack. The one big disappointment from my standpoint is 
> that MUA's don't seem to be using auth-res, etc, to do some basic annotation. 
> At least Thunderbird.

You need to install DKIM Verifier[*].  It reads A-R and displays some results.

Best
Ale
-- 

[*] https://addons.thunderbird.net/en-US/thunderbird/addon/dkim-verifier/