Subject: Re: [dmarc-ietf] Forensic report loops are a problem

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 08:38:07 -0800

On 1/27/2021 7:17 PM, Steven M Jones wrote:
> 3.3. Transport
>
>    Email streams carrying DMARC failure reports MUST conform to the
>    DMARC mechanism, thereby resulting in an aligned "pass". 

    1. I haven't been tracking discussion closely.  So if this is
    something already sufficiently well-discussed and understood and
    still landed on the above normative text, I'll apologize for re-raising.

    2. But not really, because it strikes me as a serious operational
    mistake, though a well-motivated one.

Mostly this will discourage reporting.  Legitimate reporting.

Consider the challenges to ensuring a DMARC pass.  That's a pretty high 
barrier to entry against generating reports.  It should take a very, 
very substantial record of reporting problems to justify such a barrier.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 09:12:44 -0800

> Mostly this will discourage reporting.  Legitimate reporting.
Versus illegitimate ones you'd assumedly want to ignore.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 09:25:46 -0800

> Versus illegitimate ones you'd assumedly want to ignore.

So, it's probably a good thing I emphasized:

"It should take a very, very substantial record of reporting problems to 
justify such a barrier."

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 1 Feb 2021 19:08:24 +0100

On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote:
> 
> Consider the challenges to ensuring a DMARC pass.  That's a pretty high barrier 
> to entry against generating reports.

Well, if a mail site is unable to get a DMARC pass, they have more urgent 
problems to solve than setting up aggregate report generation.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 10:13:02 -0800

On 2/1/2021 10:08 AM, Alessandro Vesely wrote:
>> Consider the challenges to ensuring a DMARC pass.  That's a pretty 
>> high barrier to entry against generating reports.
>
> Well, if a mail site is unable to get a DMARC pass, they have more 
> urgent problems to solve than setting up aggregate report generation. 

No, they probably don't have more urgent problems. Sites choose not to 
adopt DMARC for a variety of reasons. It's probably a good idea to 
respect that variety.

The model that a receiving site is not allowed to report DMARC traffic 
unless that site is also generating DMARC authentication is 
Procrustean.  And as I noted, is likely counter-productive.

I understand the zeal that drives a lot of the effort to promote DMARC, 
but the danger with aggressive proselytizing is that it changes from 
serious technical and operational evaluation into purely religious fervor.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 10:15:41 -0800

On 2/1/21 9:25 AM, Dave Crocker wrote:
> "It should take a very, very substantial record of reporting problems 
> to justify such a barrier."
>
Meanwhile in 2021, the internet is a dangerous place where the default 
posture is to assume that if something can be gamed it will be gamed.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 10:16:09 -0800

> urgent problems to solve than setting up aggregate report generation.
+1

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 10:19:40 -0800

> posture is to assume that if something can be gamed it will be gamed.

Perhaps you'd put that comment into both a cost/benefit tradeoff 
consideration and in technical and operational terms that reflects 
practical limits?

d/

-- 

Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 10:25:13 -0800

> Procrustean.  And as I noted, is likely counter-productive.
There is no such thing as "DMARC authentication". The paragraph quoted 
is poorly written and should be rewritten to say that the report should 
pass either SPF or DKIM authentication as I wrote in issue #98. This has 
nothing to do with the DMARC at all. And if requiring authentication is 
"religious fervor", I really don't know what to say.

Mike

> I understand the zeal that drives a lot of the effort to promote 
> DMARC, but the danger with aggressive proselytizing is that it changes 
> from serious technical and operational evaluation into purely 
> religious fervor.
>
>
> d/
>
> -- 
> Dave Crocker
> [email-masked]
> 408.329.0791
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 10:52:11 -0800

On 2/1/2021 10:25 AM, Michael Thomas wrote:
>> The model that a receiving site is not allowed to report DMARC 
>> traffic unless that site is also generating DMARC authentication is 
> There is no such thing as "DMARC authentication".
>
Actually, there is.  DMARC's requirement for alignment with the author's 
From: field domain name asserts a specific bit of authenticated 
semantics that does not exist elsewhere.

> The paragraph quoted is poorly written and should be rewritten to say 
> that the report should pass either SPF or DKIM authentication as I 
> wrote in issue #98.
>
It might be written better, but its requirement is for support of 
applying DMARC to generated reports.  That's more than just requiring 
SPF or DKIM.

This is separate from not asserting the requirement at all, of course.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 12:34:53 -0800

On 2/1/21 10:52 AM, Dave Crocker wrote:
> Actually, there is.  DMARC's requirement for alignment with the 
> author's From: field domain name asserts a specific bit of 
> authenticated semantics that does not exist elsewhere.
>
>
The entire thrust of the paragraph needs to be rewritten to what the 
senders and receivers must do. It does not require invoking the policy 
lookup since it can make the determination to reject reports that do not 
authenticate with either SPF or DKIM itself. The section also needs to 
clarify whether spoofing the envelope-to domain in the report contents 
is allowed or not. I do not think it should be.

Mike

---

From: "John Levine" <[email-masked]>
Date: 1 Feb 2021 18:21:04 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-

>Mostly this will discourage reporting.  Legitimate reporting.

It's been like this for a decade.

>Consider the challenges to ensuring a DMARC pass.

Looking at the results I get (and understanding that the results that
arrive via private agreements are likely different), I get reports
from linkedin.com and seznam.cz that are aligned via SPF and are DMARC
reject and none, respectively, and from antispamcloud.com that are
totally broken, not even multipart/report.

I find it hard to believe that if you are going to enough effort to
maintain the data to create and send reports, you can't figure out how
to install an SPF record for your reporting domain.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 1 Feb 2021 18:21:50 -0500

Ah, we have a semantic question.  I consider a message with p=none to be aligned.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 15:23:35 -0800

> to install an SPF record for your reporting domain.

Except that the tracking/reporting functions are completely separate 
from the 'signing' side of DMARC and could easily be different parts of 
a company.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 15:49:37 -0800

On 2/1/21 3:23 PM, Dave Crocker wrote:
> from the 'signing' side of DMARC and could easily be different parts 
> of a company.
>
> d/
>
It strains credulity that one part of a company would want to send out 
reports when some other can't even sign their email. Both need access to 
the email stream for starters.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 15:52:20 -0800

On 2/1/2021 3:49 PM, Michael Thomas wrote:
> reports when some other can't even sign their email. Both need access 
> to the email stream for starters. 

No it doesn't.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dotzero <[email-masked]>
Date: Mon, 1 Feb 2021 19:05:57 -0500

On Mon, Feb 1, 2021 at 6:49 PM Michael Thomas <[email-masked]> wrote:

> It doesn't strain my credulity at all. You are assuming a single mail
stream. I saw it at my own employer before we got centralized control of
DNS and implemented email authentication. I actually know of one company
where several hundred thousand dollars of marketing emails ended up not
getting through because a marketer thought they could evade corporate
policy and the ESP gladly took the money even though the mail was getting
rejected. It's a crazy world out there.

Michael Hammer

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 16:09:42 -0800

> Ah, we have a semantic question.  I consider a message with p=none to be aligned.

This is why that paragraph needs to be made a (sub) section stating its 
motivation and done in terms of what the requirements are on the sender 
and the receiver of the report. It has nothing at all to with the DMARC 
protocol. That's what I tried to clarify in #98.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 16:12:57 -0800

On 2/1/21 4:05 PM, Dotzero wrote:
>
>
> On Mon, Feb 1, 2021 at 6:49 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
> stream. I saw it at my own employer before we got centralized control 
> of DNS and implemented email authentication. I actually know of one 
> company where several hundred thousand dollars of marketing emails 
> ended up not getting through because a marketer thought they could 
> evade corporate policy and the ESP gladly took the money even though 
> the mail was getting rejected. It's a crazy world out there.

So we're supposed to ignore security considerations because... some 
companies are a mess? That's what this really boils down to. If we're 
writing specs for the least common denominator we might just as well 
stop. But we're not, nor have we ever.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 16:16:48 -0800

On 2/1/2021 4:12 PM, Michael Thomas wrote:
> companies are a mess?

we're supposed to balance purported security considerations with 
pragmatic, real-world operational limits.

cost/benefit.  not an unusual concept.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 16:41:19 -0800

> cost/benefit.  not an unusual concept.
We have no means of evaluating what you're complaining about. It's a 
Chimera, and a long tailed one at that.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 17:23:00 -0800

> Chimera, and a long tailed one at that. 

You're probably right.  Far better to offer requirements as absolutes, 
unanchored by practical concerns.

Except that cost/benefit isn't an illusion or fabrication, but is a 
common practice, so attempting to claim it is otherwise is gaslighting.

And gaslighting is a method that creates a hostile work environment.

It's a shame the working group management hasn't put serious effort into 
curbing such behavior.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John R Levine" <[email-masked]>
Date: 1 Feb 2021 20:38:46 -0500

On Mon, 1 Feb 2021, Dave Crocker wrote:

> Except that the tracking/reporting functions are completely separate from the 
> 'signing' side of DMARC and could easily be different parts of a company.

I took a look at my aggregate reports.  The DMARC policies of the senders 
are all over the place, some none, a few quarantine, some reject, a few 
small sites (trouble.is, gspam.co.il) have no DMARC record, one has 
neither SPF nor dmarc (itdseciron04.utep.edu). I'd say about 3/4 of the 
reports have DKIM signatures, the rest that have SPF records are aligned.

One was from [email-masked] and 
esa1.hc1512-92.c3s2.iphmx.com indeed has an SPF record.

So I would say that from my small sample, a lot of people have figured out 
how to send aligned reports, either by using their regular signing engines 
or with an SPF record for the host that sends the reports.  On the other 
hand, for reasons we've discussed that are evident to anyone familiar with 
DMARC, there's little reason to worry about fake reports, and 
authentication doesn't help even if there were.

If we want to document existing practice, I guess we would say that 
reports should be authenticated and aligned if practical, but it's OK to 
send them if not.

R's,
John

PS: Does anyone have a contact at antispamcloud.com aka hosteurope.de ? 
They send a lot of impressively broken failure reports.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 17:42:25 -0800

On 2/1/2021 5:38 PM, John R Levine wrote:
> So I would say that from my small sample, a lot of people have figured 
> out how to send aligned reports,

and, to be thorough, some/alot have not.

> either by using their regular signing engines or with an SPF record 
> for the host that sends the reports.  On the other hand, for reasons 
> we've discussed that are evident to anyone familiar with DMARC, 
> there's little reason to worry about fake reports, and authentication 
> doesn't help even if there were.

exactly.

> reports should be authenticated and aligned if practical, but it's OK 
> to send them if not.
exactly.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 17:58:23 -0800

On 2/1/21 5:42 PM, Dave Crocker wrote:
>> So I would say that from my small sample, a lot of people have 
>> figured out how to send aligned reports,
>
This, on the other hand, should be measurable. Saying that we should 
ignore authentication requirements should require extraordinary proof 
that it is needed for practical as well as security reasons. The burden 
of proof is on the nay-sayers, especially since it is so trivial to 
implement these days.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 18:05:06 -0800

On 2/1/2021 5:58 PM, Michael Thomas wrote:
> that it is needed for practical as well as security reasons. The 
> burden of proof is on the nay-sayers, especially since it is so 
> trivial to implement these days. 

Or perhaps:

    1. Barrier to adoption, for something that supposedly needs a lot
    more adoption

    2. Doesn't seem to make much difference.

I'd class those as suggesting rather strongly that the burden is on 
those that want to impose the barrier, rather than those who don't.

The problem with arbitrarily claiming a requirement, without justify it 
carefully and in a balanced matter is that it is, well, arbitrary.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 18:13:08 -0800

On 2/1/21 6:05 PM, Dave Crocker wrote:
> The problem with arbitrarily claiming a requirement, without justify 
> it carefully and in a balanced matter is that it is, well, arbitrary.
>
>
Because we all know how well unauthenticated data worked out for email. 
I fail to see why anybody would be in favor of digesting unauthenticated 
data when the method of authenticating it is trivial and well known. 
It's an extraordinary claim that needs to be backed up. But you don't 
need to convince me; you need to convince the security AD's and cross 
area reviewers.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 18:24:22 -0800

On 2/1/2021 6:13 PM, Michael Thomas wrote:
> Because we all know how well unauthenticated data worked out for 
> email. I fail to see why anybody would be in favor of digesting 
> unauthenticated data when the method of authenticating it is trivial 
> and well known. It's an extraordinary claim that needs to be backed 
> up. But you don't need to convince me; you need to convince the 
> security AD's and cross area reviewers.

DMARC has been deployed for 6 or 7 years.  Where is this onerous abuse 
on reporting that you feel is inevitable?

I suspect you've assumed the incentives for sending problematic reports 
are the same as the incentives for abuse of generic mail, while they are 
likely quite different.

And no, it isn't trivial at all.  Setting this stuff up properly takes 
skill and effort, which means it's expensive.  And often is fragile.  
Hence the need to attend thoughtfully to pragmatics.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Douglas Foster <[email-masked]>
Date: Mon, 1 Feb 2021 21:31:48 -0500

Michael, let it go.

If someone stops you to say "your zipper is down", you will not ask them
for proof of identity, you will excuse yourself and investigate the
problem.   By my reckoning, DMARC reports are a lot like that.

Source Alpha says, "Server X is sending unauthenticated mail for Domain
Y."   Several possbilities exist:
- You already distrust information coming from Source Alpha, so you reject
or discard the information.
- You already have enough data to investigate, so you ignore this report.
- You decide to investigate this report, which produces one of three
outcomes:
     - Server X has a problem, and you fix it.
     - Server X is not your server, so you confirm that it is not your
problem.
     - Source Alpha is wrong, so you add a rule to reject or discard future
reports from that source.

I do not see any reason for a DMARC report to flow indirectly, so I would
be suspicious of any reports that appeared to come that way.   This means
all I really need is an SPF PASS.

But I do not need positive identification of the source.

On Mon, Feb 1, 2021 at 9:13 PM Michael Thomas <[email-masked]> wrote:

> ignore authentication requirements should require extraordinary proof that
> it is needed for practical as well as security reasons. The burden of proof
> is on the nay-sayers, especially since it is so trivial to implement these
> days.
>
> Or perhaps:
>
> 1. Barrier to adoption, for something that supposedly needs a lot more
> adoption
>
> I'd class those as suggesting rather strongly that the burden is on those
> that want to impose the barrier, rather than those who don't.
>
> Because we all know how well unauthenticated data worked out for email. I
> fail to see why anybody would be in favor of digesting unauthenticated data
> when the method of authenticating it is trivial and well known. It's an
> extraordinary claim that needs to be backed up. But you don't need to
> convince me; you need to convince the security AD's and cross area
> reviewers.
>
> Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 18:33:40 -0800

> on reporting that you feel is inevitable?

Email was around for 20 years until spam became a problem. We know how 
this plays out: bad guys do the least amount of work possible until they 
have to react. When it becomes a barrier as p=reject does, they take 
action to protect their turf. Plugging an obvious security hole with a 
well known and trivial set of authentication mechanisms to prevent 
forgery should be the default posture. Anybody who is against that needs 
to explain in depth why it should not be the case. Especially since it's 
part of DMARC now.

Mike, security related specs thumbing their nose at security is a very 
peculiar stance.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Feb 2021 18:37:36 -0800

On 2/1/21 6:31 PM, Douglas Foster wrote:
> Michael, let it go.
>
> If someone stops you to say "your zipper is down", you will not ask 
> them for proof of identity, you will excuse yourself and investigate 
> the problem.   By my reckoning, DMARC reports are a lot like that.
>
1. This is already part of DMARC, though it can use some work

2. If somebody says your zipper is down, they can clock you when you 
look down to check to steal your wallet. Do not underestimate what 
attackers can do with unauthenticated data.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Feb 2021 18:42:25 -0800

On 2/1/2021 6:33 PM, Michael Thomas wrote:
> Email was around for 20 years until spam became a problem. 

Perhaps you missed the difference in scale between all of the last 5-7 
years versus pretty much all of that 20 years?

In other words, just to keep this simple:  They not in the least 
comparable.  Also, cf, my previous reference to incentives.

> We know how this plays out: bad guys do the least amount of work 
> possible until they have to react. When it becomes a barrier as 
> p=reject does, they take action to protect their turf. Plugging an 
> obvious security hole with a well known and trivial set of 
> authentication mechanisms to prevent forgery should be the default 
> posture. Anybody who is against that needs to explain in depth why it 
> should not be the case. Especially since it's part of DMARC now.
>
Mechanical application of a high-level script, without attending to the 
details that make the script actually work in a specific case, tends to 
lead to counter-productive decisions.  cf my earlier reference to 
barriers to entry and lack of damaging effect.

And flamboyant, aggressively hostile language like 'thumbing their nose' 
is not merely wrong, it is another attempt at gaslighting.  cf my 
earlier reference to hostile work environment.

sigh.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Seth Blank <[email-masked]>
Date: Mon, 1 Feb 2021 18:44:26 -0800

All-- this thread is unproductive and becoming increasingly combative.

Per our discussion on list decorum and BCP 94 warnings (
https://mailarchive.ietf.org/arch/msg/dmarc/ub6xFEU15w0HAW82ZEnHr_mS180/):

    Finally, several members of this working group seem to be very
effective at
    antagonizing each other. If a thread is spiralling, and a BCP 94
warning is
    given and not heeded, all active participants in the thread after the
    warning has been issued will be suspended, even if it’s to tell others
to
    respect the warning.

This is an official BCP 94 warning. Everyone please disengage from this
thread.

Seth, as Chair

-- 

*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: Alessandro Vesely <[email-masked]>
Date: Tue, 2 Feb 2021 18:19:59 +0100

On Tue 02/Feb/2021 02:42:25 +0100 Dave Crocker wrote:
>> If we want to document existing practice, I guess we would say that reports 
>> should be authenticated and aligned if practical, but it's OK to send them if 
>> not.
> exactly.

I changed it again, for failure reports, like so:

3.3.  Transport

    Email streams carrying DMARC failure reports SHOULD conform to the
    DMARC mechanism, thereby resulting in an aligned "pass".  This
    requirement is a MUST in case the sending host has a DMARC record
    featuring a ruf= tag.  Indeed, special care must be taken of
    authentication in that case, as failure to authenticate failure
    reports may result in mail loops.

    Reporters SHOULD rate limit the number of failure reports sent to any
    recipient to avoid overloading recipient systems.  Again, in case the
    reports being sent are in turn at risk of being reported for DMARC
    authentication failure, reporters MUST make sure that possible mail
    loop are stopped.

Some comments upthread allude to the reporter's policy.  To be clear, the DMARC 
mechanism which results in an aligned pass is meant to say that the report is 
SPF or DKIM authenticated , the authenticated identifier is aligned with From:, 
and a DMARC record has been discovered.  The value of p= is irrelevant.

Indeed, from a security perspective, a faked failure report is not much 
different from an abusive message.  To wit, a bad actor could send one or the 
other, directly to the victim or, respectively, to a server that will report to 
the victim.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 2 Feb 2021 09:24:32 -0800

On 2/2/2021 9:19 AM, Alessandro Vesely wrote:
>>> reports should be authenticated and aligned if practical, but it's 
>>> OK to send them if not.
>> exactly.
>
>

"conform to" seems odd wording; it's not immediately obvious what it 
means here.

Perhaps:

  SHOULD provide DMARC-based authentication, to produce their own 
aligned "pass"

> requirement is a MUST in case the sending host has a DMARC record

'sending host' is ambiguous in this context.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 2 Feb 2021 18:39:43 +0100

On Tue 02/Feb/2021 18:24:32 +0100 Dave Crocker wrote:
> "conform to" seems odd wording; it's not immediately obvious what it means here.
> 
> Perhaps:
> 
>   SHOULD provide DMARC-based authentication, to produce their own aligned "pass"
> 
> 

Is this better:

3.3.  Transport

    Email streams carrying DMARC failure reports SHOULD provide DMARC-
    based authentication, so as to produce "dmarc=pass".  This
    requirement is a MUST in case the report is sent through a host
    having a DMARC record with a ruf= tag.  Indeed, special care must be
    taken of authentication in that case, as failure to authenticate
    failure reports may result in mail loops.

Best
Ale
--