Subject: [ietf-smtp] [email-masked] and DMARC with p=quarantine; pct=0

From: Дилян Палаузов <[email-masked]>
Date: Fri, 25 Jan 2019 11:29:45 +0000

Hello,

for the message

To: [email-masked]
Message-ID: <[email-masked]>
Date: Thu, 17 Jan 2019 10:43:41 +0100
Subject: Re: [ietf-smtp] SMTP Over TLS on Port 26 - Implicit TLS Proposal
Sender: "ietf-smtp" <[email-masked]>
X-Original-From: Evert Mouw <[email-masked]>
From: Evert Mouw <post=[email-masked]>

DNS TXT _dmarc.evert.net is “v=DMARC1; p=reject; fo=1; rua=mailto:[email-masked]; ruf=mailto:[email-masked];”, the MLM
changed From: and no reports were generated, based on broken DMARC policy.  Likewise for the message:

Date: Wed, 16 Jan 2019 10:20:23 -0800
Message-ID: <[email-masked]>
To: Gene Hightower <[email-masked]>
Cc: John R Levine <[email-masked]>, ietf-smtp <[email-masked]>
Sender: "ietf-smtp" <[email-masked]>
X-Original-From: John Bucy <[email-masked]>
From: John Bucy <jbucy=[email-masked]>

DNS TXT _dmarc.google.com is “v=DMARC1; p=reject; rua=mailto:[email-masked]”, the MLM changed From: and no
DMARC failure reports are generated.

For the messages from @akamai.com, like:

From: "Salz, Rich" <[email-masked]>
To: John R Levine <[email-masked]>, John C Klensin <[email-masked]>
Date: Fri, 25 Jan 2019 01:44:30 +0000
Message-ID: <[email-masked]>
Subject: Re: [ietf-smtp] [Uta] New Version Notification for
 draft-levine-additional-registered-clauses-00
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: "ietf-smtp" <[email-masked]>

DNS TXT _dmarc.akamai.com contains “v=DMARC1; p=quarantine; pct=0; rua=mailto:[email-masked], mailto:
[email-masked]; ruf=mailto:[email-masked]; sp=none”.  The MLM does not rewrite From:.  Delivering the
email to the mailing lists recipients leads to failed DMARC and a (not aggregated) report is generated per delivered
message.

Shouldn’t [email-masked] change the From:, when for the domain p=quarantine is set, just as for p=reject, in order
to avoid generating useless reports, and ensuring delivered emails? (Handling “quarantine” as “reject” on the
recipients’ side is not neccesary wrong).

Regards
  Дилян

---

From: [email-masked]
Date: Fri, 25 Jan 2019 09:46:30 -0500

> Shouldn’t [email-masked] change the From:,

It looks like it did in fact do so. Or something changed it. I'm pretty sure
that Evert didn't send it with that From: line.

---

From: "John Levine" <[email-masked]>
Date: 25 Jan 2019 12:24:39 -0500

>> From: Evert Mouw <post=[email-masked]>

Yes, that's how the IETF's anti-DMARC hack rewrites addresses when it needs to.

R's,
John

---

From: [email-masked]
Date: Fri, 25 Jan 2019 14:34:05 -0500

> Yes, that's how the IETF's anti-DMARC hack rewrites addresses when it needs to.

That's why I was confused by the original query that asked "Shouldn't it rewrite
the From:?".  Although looking at the Cyrillic in the person's name, I'm wondering
now if it wasn't a language problem and they were asking whether re-writing it
was in fact the right thing to do.  The difference between "Shouldn't It do this"
and "Should it not do this?"

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 25 Jan 2019 10:06:21 -1000

On Fri, Jan 25, 2019 at 1:29 AM Дилян Палаузов <[email-masked]>
wrote:

> [email-masked]; ruf=mailto:[email-masked]; sp=none”.
> The MLM does not rewrite From:.  Delivering the
> email to the mailing lists recipients leads to failed DMARC and a (not
> aggregated) report is generated per delivered
> message.
>
> Shouldn’t [email-masked] change the From:, when for the domain
> p=quarantine is set, just as for p=reject, in order
> to avoid generating useless reports, and ensuring delivered emails?
> (Handling “quarantine” as “reject” on the

Based on the definition of how "pct" is handled, 0% of the messages going
through DMARC evaluation should be affected. The DMARC spec says:

(6.3) Percentage of messages from the Domain Owner's mail stream to which
the DMARC policy is to be applied.  However,

(6.6.4) If the "pct" tag is present in the policy record, the Mail Receiver
MUST NOT enact the requested policy ("p" tag or "sp" tag") on more than the
stated percent of the totality of affected messages.

When implementers are doing "funny stuff" like selectively manipulating
from addresses, it is debatable as to what the absolute "right" thing is
since the definition of non-sampled message treatment is one level less
than the "p=" specification - in this case that would be "none".

--Kurt

---

From: Dilyan Palauzov <[email-masked]>
Date: Fri, 25 Jan 2019 22:46:47 +0100

Hello Kurt,

somebody wrote somewhere (I can search for this statement if necesssary), that p=quarantine; pct=0; is the way to test, whether the DMARC setup is working correctly and get failure reports.

So the difference between p=quarantine; pct=0;  and p=none is that in the former case a verification of a presumably ready setup is done.  During this verification, I think, From: (@akamai.com) should be changed by MLMs, as if pct wasn’t zero, in order to be sure that things will continue to run smoothly once pct is increased.

With other words, pct being present, zero or absent has no impact on the non-aggregate failure reports per message.

There is no such thing as “level”: quarantine is not one level less that reject.

Regards
  Дилян

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 25 Jan 2019 12:01:59 -1000

On Fri, Jan 25, 2019 at 11:46 AM Dilyan Palauzov <[email-masked]>
wrote:

> Hello Kurt,
>
> somebody wrote somewhere (I can search for this statement if necesssary),
> that p=quarantine; pct=0; is the way to test, whether the DMARC setup is
> working correctly and get failure reports.
>

There have been some claims to this effect, but it depends entirely on
implementation-dependent (non-specified) behaviour.

> So the difference between p=quarantine; pct=0; and p=none is that in the
> former case a verification of a presumably ready setup is done. During this
> verification, I think, From: (@akamai.com) should be changed by MLMs, as
> if pct wasn’t zero, in order to be sure that things will continue to run
> smoothly once pct is increased.
>
> With other words, pct being present, zero or absent has no impact on the
> non-aggregate failure reports per message.
>

You are correct regarding the non-effect of pct for reporting. Citing the
spec (https://tools.ietf.org/html/rfc7489) again:  (6.6.4) 'regardless of
whether or not the "pct" tag is present, the Mail Receiver MUST include all
relevant message data in any reports produced." It does not say anything
about other manipulations of the header fields.

There is no such thing as “level”: quarantine is not one level less that
> reject.

Yes there is such a concept and quarantine is one level less than reject.
Continuing the citation above:

If email is subject to the DMARC policy of "quarantine", the Mail Receiver
SHOULD quarantine the message.  If the email is not subject to the
"quarantine" policy (due to the "pct" tag), the Mail Receiver SHOULD apply
local message classification as normal.
If email is subject to the DMARC policy of "reject", the Mail Receiver
SHOULD reject the message (see Section 10.3).  If the email is not subject
to the "reject" policy (due to the "pct" tag), the Mail Receiver SHOULD
treat the email as though the "quarantine" policy applies.  This behavior
allows Domain Owners to experiment with progressively stronger policies
without relaxing existing policy.

The spec does not use the term "level", but I don't think that it is
misplaced to use that term since it does refer to "progressively stronger
policies".

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 25 Jan 2019 17:12:40 -0500

In article <[email-masked]> you write:
>somebody wrote somewhere (I can search for this statement if necesssary), that p=quarantine; pct=0; is the way to test, whether the
>DMARC setup is working correctly and get failure reports.

There are certainly people who believe that, but they are mostly wrong.

You get the same failure reports with p=none as p=reject, so that's
not it.  I have p=none on all my domains and have collected 170,000
aggregate reports and 77,000 failure reports so I speak from
experience here.

What pct=0 might or might not do is to trigger recipient filtering
rules and mailing list rewrite rules, but that is entirely up to the
people who run the lists.  They can and will do whatever they want.

R's,
John

---

From: Дилян Палаузов <[email-masked]>
Date: Fri, 25 Jan 2019 23:26:53 +0000

Hello,

at a high level the common interest is to reach a state, where deployed DMARC works in practice reliably:
- verifiers and signers are compatible
- signature are not broken on their way to the recipients, so no bad delivery
- the path from sender to recipient always works reliably and whenever something does not work as expected an individual
failure report is sent
…

Receiving aggregate report, stating 0,1% of mails do not verify DKIM, shows that signers and verifiers in that
combination are not compatible.  The aggregate report does not say whether the the signer or the verifier does bad job,
it just proves that DMARC is not going to work 100% reliably.  This is bad for both parties, as it just means that DMARC
shall not be trusted as it in practice does not work as expected (and therefore deploying it is…)

The individual failure reports provide the means to find exactly what is going wrong, on which system.  To tackle a
failure report I want to be sure that something wrong happened.  A failure report for p=none cannot mean, that something
wrong happened, in particular it does not mean that DMARC is violated.  So sending a report on p=none makes no sense.

Shall a failure report be sent for p=quarantine; pct=0?  
https://mailarchive.ietf.org/arch/msg/ietf-dkim/fUGKyF0iE6DmKPJj-qH4XHz4_Lg says “p=reject;pct=0; is to force MLMs to
rewrite From:, so as to
avoid useless reports”.

This is discussable but the common aim is to have a state, where reports get very seldom and every report has an added
value — indicates a problem that is investigated.  Sending too much reports, on real and unreal troubles, makes tracking
manually all reports impossible and does not help to make DMARC reliable.  Keep in mind that not every person deploying
DMARC or mailing lists understands DMARC or acknowledges that its MLM modifies messages but does not change the From:
sender.

The current discussion does not lead in the direction of reaching the state, where reports are sent seldom and indicate
troubles, which troubles shall and can be handled in a way, that prevents happening them again in the future.  That
said, the current setups in general do not permit to improve the accuracy of DKIM/DMARC evaluations.

There are not only theoretical, but also practical concerns.  Having DKIM-Signature: r=y; … in a message, sent over a
mailing list, the From: is changed and DKIM invalidated.  Per RFC 6651 a report is sent.  But this report is useless, as
the MLM broke the intentionally the DKIM-Signature, so there is no information to extract from the report and there is
no approprite handling.

In summary, the specifications shall be read in such a way, that:
* reports shall only be sent, when the recipient of the report can and shall take actions to improve the accuracy of
DMARC/DKIM, and
* for the purposes of testing there must be a way only to get reports for bad situations, without having the bad
consequences.

Regards
  Дилян

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 25 Jan 2019 14:15:16 -1000

This is worthwhile, if aspirational, input to a future phase of the DMARC
WG (added to the distro and moving SMTP to BCC). It is, as you observe, not
the current state of the spec.

One further complication is that relatively few receivers generate forensic
report (ruf), in part due to privacy concerns. As a result, even if the
process worked the way you advocate, you won't get much if any information.

--Kurt

On Fri, Jan 25, 2019 at 1:27 PM Дилян Палаузов <[email-masked]>
wrote:

> - the path from sender to recipient always works reliably and whenever
> something does not work as expected an individual
> failure report is sent
> …
>
> combination are not compatible.  The aggregate report does not say whether
> the the signer or the verifier does bad job,
> it just proves that DMARC is not going to work 100% reliably.  This is bad
> for both parties, as it just means that DMARC
> The individual failure reports provide the means to find exactly what is
> going wrong, on which system.  To tackle a
> failure report I want to be sure that something wrong happened.  A failure
> report for p=none cannot mean, that something
> wrong happened, in particular it does not mean that DMARC is violated.  So
> sending a report on p=none makes no sense.
>
> https://mailarchive.ietf.org/arch/msg/ietf-dkim/fUGKyF0iE6DmKPJj-qH4XHz4_Lg
> says “p=reject;pct=0; is to force MLMs to
> rewrite From:, so as to
> avoid useless reports”.
>
> This is discussable but the common aim is to have a state, where reports
> get very seldom and every report has an added
> value — indicates a problem that is investigated.  Sending too much
> reports, on real and unreal troubles, makes tracking
> manually all reports impossible and does not help to make DMARC reliable.
> Keep in mind that not every person deploying
> DMARC or mailing lists understands DMARC or acknowledges that its MLM
> modifies messages but does not change the From:
> sender.
>
> The current discussion does not lead in the direction of reaching the
> state, where reports are sent seldom and indicate
> There are not only theoretical, but also practical concerns.  Having
> DKIM-Signature: r=y; … in a message, sent over a
> mailing list, the From: is changed and DKIM invalidated.  Per RFC 6651 a
> report is sent.  But this report is useless, as
> the MLM broke the intentionally the DKIM-Signature, so there is no
> information to extract from the report and there is
> no approprite handling.
>
> * reports shall only be sent, when the recipient of the report can and
> shall take actions to improve the accuracy of
> DMARC/DKIM, and