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

[Dave Crocker]

On 2/1/2021 4:41 PM, Michael Thomas wrote:
we're supposed to balance purported security considerations with 
pragmatic, real-world operational limits.

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. 



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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 2/1/21 4:16 PM, Dave Crocker wrote:

On 2/1/2021 4:12 PM, Michael Thomas wrote:
So we're supposed to ignore security considerations because... some 
companies are a mess?



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


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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 2/1/2021 4:12 PM, Michael Thomas wrote:
So we're supposed to ignore security considerations because... some 
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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 2/1/21 4:05 PM, Dotzero wrote:



On Mon, Feb 1, 2021 at 6:49 PM Michael Thomas > wrote:




On 2/1/21 3:23 PM, Dave Crocker wrote:
> On 2/1/2021 3:21 PM, John Levine wrote:
>> 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.
>
> 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/
>
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.

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.



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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 2/1/21 3:21 PM, John Levine wrote:

In article <9aea1615-64a5-a310-b8c7-83ec0c316...@gmail.com> you write:

-=-=-=-=-=-

On 2/1/2021 10:08 AM, Alessandro Vesely wrote:

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.


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.

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Mon, Feb 1, 2021 at 6:49 PM Michael Thomas  wrote:

>
>
> On 2/1/21 3:23 PM, Dave Crocker wrote:
> > On 2/1/2021 3:21 PM, John Levine wrote:
> >> 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.
> >
> > 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/
> >
> 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.
>
> 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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 2/1/2021 3:49 PM, Michael Thomas wrote:


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. 


No it doesn't.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 2/1/21 3:23 PM, Dave Crocker wrote:

On 2/1/2021 3:21 PM, John Levine wrote:

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.


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/

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 2/1/2021 3:21 PM, John Levine wrote:

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.


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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

In article <9aea1615-64a5-a310-b8c7-83ec0c316...@gmail.com> you write:
>-=-=-=-=-=-
>
>On 2/1/2021 10:08 AM, Alessandro Vesely wrote:
>> 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. 
>
>
>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.

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

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

In article  you write:
>-=-=-=-=-=-
>
>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". 

>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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 2/1/21 10:52 AM, Dave Crocker wrote:

On 2/1/2021 10:25 AM, Michael Thomas wrote:



On 2/1/21 10:13 AM, Dave Crocker wrote:
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. 


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.

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 2/1/2021 10:25 AM, Michael Thomas wrote:



On 2/1/21 10:13 AM, Dave Crocker wrote:
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. 


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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 2/1/21 10:13 AM, Dave Crocker wrote:

On 2/1/2021 10:08 AM, Alessandro Vesely wrote:

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. 



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.


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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 2/1/2021 10:15 AM, Michael Thomas wrote:


On 2/1/21 9:25 AM, Dave Crocker wrote:

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."


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.



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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 2/1/21 10:08 AM, Alessandro Vesely wrote:

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.



+1

Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 2/1/21 9:25 AM, Dave Crocker wrote:

On 2/1/2021 9:12 AM, Michael Thomas wrote:

On 2/1/21 8:38 AM, Dave Crocker wrote:
Mostly this will discourage reporting. Legitimate reporting. 


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."


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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 2/1/2021 10:08 AM, Alessandro Vesely wrote:

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. 



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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

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
--






















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 2/1/2021 9:12 AM, Michael Thomas wrote:

On 2/1/21 8:38 AM, Dave Crocker wrote:
Mostly this will discourage reporting.  Legitimate reporting. 


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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 2/1/21 8:38 AM, Dave Crocker wrote:

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". 



Mostly this will discourage reporting.  Legitimate reporting.


Versus illegitimate ones you'd assumedly want to ignore.

Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Thu, Jan 28, 2021 at 1:42 PM John R Levine  wrote:

> > This to me is almost exactly the same thing as saying "Don't generate a
> > bounce about a bounce",
>
> Because these are not bounces.  They are not even a little bit like
> bounces.  Bounces are about invalid recipient addresses, but these have no
> relation to anything about the recipient address.
>

Yes, I realize the difference.  I was making an analogy.

They are fresh new messages sent from a system that presumably cares
> enough about DMARC to send reports about it, and presumably wants to send
> all of its mail with DMARC alignment.  If they are unaligned, that is
> because the sending system is broken, and if that systems publishes an
> ruf= tag, it is specifically asking to be inforned about exactly that
> breakage.
>

OK, let's hop into your example.  I care enough about DMARC to send reports
about it, and I want to send all of my mail aligned.  I send a test message
that ends up unaligned somehow, perhaps through a broken relay I don't own,
and I would ideally like to get one message back that tells me that.  If I
happen to send my test to a place that unintentionally sends an unaligned
report back to me, perhaps because of the same relay, I'm going to get
flooded, even though my local setup is verifiably correct.  And, probably,
so are they.

You're saying the only real answer here is that the two end operators in
this example need to fix their evidently-crappy setups, or change their DNS
records to remove the "ruf" value until they can get the guy in the middle
to fix whatever's broken?

Maybe I'm the dim one, but I can't see why it's manifestly absurd to think
we might somehow augment either the report or the message containing it by
adding just enough metadata someplace to signal one end or the other, or
both, to avert the flood.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John R Levine]

C) Stipulate somehow that generated reports should not contain data about
received reports.  (If you do that, then you likely obviate the need to
generate a new report back to that operator in the first place.)


I can't even tell what might be a failure report without deep parsing and 
heuristics.  And, of course, I am not inclined to add extra code to 
program around other people's bugs.




This to me is almost exactly the same thing as saying "Don't generate a
bounce about a bounce",


Because these are not bounces.  They are not even a little bit like 
bounces.  Bounces are about invalid recipient addresses, but these have no 
relation to anything about the recipient address.


They are fresh new messages sent from a system that presumably cares 
enough about DMARC to send reports about it, and presumably wants to send 
all of its mail with DMARC alignment.  If they are unaligned, that is 
because the sending system is broken, and if that systems publishes an 
ruf= tag, it is specifically asking to be inforned about exactly that 
breakage.


Maybe I'm dim, but I am having no success understanding the apparent 
interpretion of ruf as "tell me about the unaligned messages I'm sending, 
except for some that should be really easy for me to fix."


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Jan 27, 2021 at 7:08 PM John R Levine  wrote:

> Which of these should we do:
>
> A) Everyone in the world who produces failure reports adds special cases
> to look for incoming failure reports, and heuristics to try and recognize
> failure reports in the wrong format, and when it finds one of them, it
> makes a note not to send a failure report about it.
>
> B) Someone slaps me upside the head and I fix my SPF record so my reports
> are sent correctly.
>

I'm suggesting:

C) Stipulate somehow that generated reports should not contain data about
received reports.  (If you do that, then you likely obviate the need to
generate a new report back to that operator in the first place.)

This to me is almost exactly the same thing as saying "Don't generate a
bounce about a bounce", which has been part of SMTP for decades (it's a
SHOULD NOT in 2821).  I don't understand why you're saying it's appropriate
in one but a non-issue in the other.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Thu 28/Jan/2021 04:17:06 +0100 Steven M Jones wrote:

On 1/27/21 12:47, Murray S. Kucherawy wrote:

On Wed, Jan 27, 2021 at 12:37 PM John Levine wrote:


I still don't understand why failure reports about messages that happen
to be failure reports are in any way special. >>
Loop detection in RFC 5321 is a normative MUST because of the obvious 
operational problems it creates.  Maybe I'm being thick, but right now I

don't see how this is different, apart from the fact that each message is
distinct; you're still causing a problem by turning this on without a care
in the world about whether two verifiers start spamming each other. >

There's coverage in 7489 Section 7.2 that a domain owner can inadvertently
DDoS themselves via failure reports. And that still surprised many
implementers, even though it seemed obvious to them in retrospect. >
This case is even less obvious, and we still have questions coming in about
it from new implementers. >
I don't think it's a security consideration because it doesn't scale up
the way "ruf" can, so it deserves a brief mention here. But I would
rephrase Ale's last sentence:


3.3.  Transport

    Email streams carrying DMARC failure reports MUST conform to the
    DMARC mechanism, thereby resulting in an aligned "pass".  Special
    care must be taken for authentication, as failure to authenticate
    failure reports may result in mail loops.  These loops can be mitigated
    by sending reports from a domain or subdomain that doesn't request
    reports, or by performing rate limiting for report receiving mailboxes.



I rephrased it further:

3.3.  Transport

   Email streams carrying DMARC failure reports MUST conform to the
   DMARC mechanism, thereby resulting in an aligned "pass".  Special
   care must be taken of authentication, as failure to authenticate
   failure reports may result in mail loops.  These loops can be
   mitigated by sending reports from a domain or subdomain that doesn't
   request reports, or by performing rate limiting especially for
   failures related to messages received at addresses published in a
   ruf= tag.


Best
Ale
--





















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Douglas Foster]

Loops require two parties.  Any one party can protect both parties by
choosing to not perpetuate the loop.

Saying that "the other guy" should be smarter seems wishful thinking.  Of
course some other people will act stupidly.  Fixing that problem is not in
my scope.   Having their mistakes interfere with my system's normal
operation is not an option that I am willing to permit.

DF

On Wed, Jan 27, 2021, 10:20 PM Steven M Jones  wrote:

> On 1/27/21 19:08, John R Levine wrote:
> > On Wed, 27 Jan 2021, Murray S. Kucherawy wrote:
> >>> I still don't understand why failure reports about messages that
> >>> happen to be failure reports are in any way special.
> >>
> >> Loop detection in RFC 5321 is a normative MUST because of the obvious
> >> operational problems it creates.  Maybe I'm being thick, but right now I
> >> don't see how this is different, apart from the fact that each
> >> message is
> >> distinct; ...
> >
> > Here's perhaps another way to look at it.
> >
> > ...
> >
> > B) Someone slaps me upside the head and I fix my SPF record so my
> > reports are sent correctly.
> >
> > This does not strike me as a hard problem.
>
>
> It's not a hard problem. I see the last sentence in Section 3.3 as
> reserving the right to deliver that slap...
>
> --S.
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Steven M Jones]

On 1/27/21 19:08, John R Levine wrote:
> On Wed, 27 Jan 2021, Murray S. Kucherawy wrote:
>>> I still don't understand why failure reports about messages that
>>> happen to be failure reports are in any way special.
>>
>> Loop detection in RFC 5321 is a normative MUST because of the obvious
>> operational problems it creates.  Maybe I'm being thick, but right now I
>> don't see how this is different, apart from the fact that each
>> message is
>> distinct; ...
>
> Here's perhaps another way to look at it.
>
> ...
>
> B) Someone slaps me upside the head and I fix my SPF record so my
> reports are sent correctly.
>
> This does not strike me as a hard problem.


It's not a hard problem. I see the last sentence in Section 3.3 as
reserving the right to deliver that slap...

--S.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Steven M Jones]

On 1/27/21 12:47, Murray S. Kucherawy wrote:
> On Wed, Jan 27, 2021 at 12:37 PM John Levine  > wrote:
>
> I still don't understand why failure reports about messages that
> happen to be failure reports are in any way special.
>
>
> Loop detection in RFC 5321 is a normative MUST because of the obvious
> operational problems it creates.  Maybe I'm being thick, but right now
> I don't see how this is different, apart from the fact that each
> message is distinct; you're still causing a problem by turning this on
> without a care in the world about whether two verifiers start spamming
> each other.


There's coverage in 7489 Section 7.2 that a domain owner can
inadvertently DDoS themselves via failure reports. And that still
surprised many implementers, even though it seemed obvious to them in
retrospect.

This case is even less obvious, and we still have questions coming in
about it from new implementers.

I don't think it's a security consideration because it doesn't scale up
the way "ruf" can, so it deserves a brief mention here. But I would
rephrase Ale's last sentence:


3.3.  Transport

   Email streams carrying DMARC failure reports MUST conform to the
   DMARC mechanism, thereby resulting in an aligned "pass".  Special
   care must be taken for authentication, as failure to authenticate
   failure reports may result in mail loops.  These loops can be mitigated
   by sending reports from a domain or subdomain that doesn't request
   reports, or by performing rate limiting for report receiving mailboxes.


--S.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John R Levine]

On Wed, 27 Jan 2021, Murray S. Kucherawy wrote:
I still don't understand why failure reports about messages that happen 
to be failure reports are in any way special.


Loop detection in RFC 5321 is a normative MUST because of the obvious
operational problems it creates.  Maybe I'm being thick, but right now I
don't see how this is different, apart from the fact that each message is
distinct; ...


Here's perhaps another way to look at it.

Imagine that I am a semi-competent mail server operator.  I hear that 
DMARC is great stuff and I set up DMARC software on my server including 
sending and processing reports.


Unfortunately, my l33t coding skillz aren't quite up to it, and my failure 
reports are all unaligned.  Also, I'm not very good at reading specs and 
my reports aren't in the right format either.  (Not making this up, I have 
lots of failure reports that are not multipart/report.)


Oh, no!  People are sending me failure reports about my failure reports! 
Make it stop!


Which of these should we do:

A) Everyone in the world who produces failure reports adds special cases 
to look for incoming failure reports, and heuristics to try and recognize 
failure reports in the wrong format, and when it finds one of them, it 
makes a note not to send a failure report about it.


B) Someone slaps me upside the head and I fix my SPF record so my reports 
are sent correctly.


This does not strike me as a hard problem.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Jan 27, 2021 at 12:37 PM John Levine  wrote:

> I still don't understand why failure reports about messages that
> happen to be failure reports are in any way special.
>

Loop detection in RFC 5321 is a normative MUST because of the obvious
operational problems it creates.  Maybe I'm being thick, but right now I
don't see how this is different, apart from the fact that each message is
distinct; you're still causing a problem by turning this on without a care
in the world about whether two verifiers start spamming each other.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>
>On Wed, Jan 27, 2021 at 10:38 AM John R Levine  wrote:
>
>> Stop there.  If you don't want failure reports, don't send unaligned
>> messages.
>
>I could be sold on the idea that there's not a problem for us to fix in the
>protocol here, but what about the notion that it's something that might
>warrant a sentence or two of informative text (i.e., that this is a problem
>that can occur and possibly cause operational pressure)?

I still don't understand why failure reports about messages that
happen to be failure reports are in any way special.

The report is after all a brand new message which I would hope is sent
the way tou send any other message, and should be aligned if the rest
of your mail is.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Jan 27, 2021 at 10:38 AM John R Levine  wrote:

> Stop there.  If you don't want failure reports, don't send unaligned
> messages.
>

I could be sold on the idea that there's not a problem for us to fix in the
protocol here, but what about the notion that it's something that might
warrant a sentence or two of informative text (i.e., that this is a problem
that can occur and possibly cause operational pressure)?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John R Levine]

On Wed, 27 Jan 2021, Alessandro Vesely wrote:
If the authentication is screwed up, sending a failure report is exactly 
the right thing to do.  That's what they're for.


  Email streams carrying DMARC feedback data MUST conform to the DMARC
  mechanism, thereby resulting in an aligned "pass" (see Section 3.1).



Even if the screwed up message was a failure report itself?


Of course.  The failure repoort is a new e-mail message.  If it's not 
aligned, your code needs to be fixed.



3.3.  Transport

  Email streams carrying DMARC failure reports MUST conform to the
  DMARC mechanism, thereby resulting in an aligned "pass".  Special
  care must be taken for authentication, as failure to authenticate
  failure reports may result in mail loops.


Stop there.  If you don't want failure reports, don't send unaligned 
messages.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Wed 27/Jan/2021 17:17:38 +0100 John R Levine wrote:


While [loops are] a minor problem for aggregate reports, it can be a real problem 
for naive failure reports generators.  Juri reported he had to target a 
specific address, attributing the loop to a remote misconfiguration. However, 
if it is possible to screw up authentications, the probability to meet a loop 
is just its square, times the number of generators.


If the authentication is screwed up, sending a failure report is exactly the 
right thing to do.  That's what they're for.



Even if the screwed up message was a failure report itself?


I think we should close this.  DMARC is working the way it is supposed to, and 
people don't want to get reports about their reports, there are obvious ways to 
prevent them, like not sending unaligned reports,



Oh, there is a sentence in the current spec:

   Email streams carrying DMARC feedback data MUST conform to the DMARC
   mechanism, thereby resulting in an aligned "pass" (see Section 3.1).

As it stands, it's valid for both aggregate and failure reports.  However, it 
happened to land on the aggregate-reporting I-D only.




or sending reports from a domain that doesn't get reports back.


That was one of the hints I proposed.  Your wording is better.  Added this:

3.3.  Transport

   Email streams carrying DMARC failure reports MUST conform to the
   DMARC mechanism, thereby resulting in an aligned "pass".  Special
   care must be taken for authentication, as failure to authenticate
   failure reports may result in mail loops.  Besides rate limiting,
   such loops can also be avoided by sending reports from a domain that
   doesn't get reports back.

Is that all right?


Best
Ale
--











___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John R Levine]

disparate cases of it that we may be missing something bigger, and if so,
doing something defensive in the specification would be prudent.  There's
smoke here, and there may be fire.

Will report back.


Examining my report folder, I note I'm sending one-liner aggregate reports to 
domains I never wrote to.  The pattern is their sending me feedback for one 
or more mailing list posts, followed by my one-liner acknowledging their 
report later on the same day or on the next day, depending on their sending 
time.


That's not a "loop", it's the way that DMARC reports work.

While this is a minor problem for aggregate reports, it can be a real problem 
for naive failure reports generators.  Juri reported he had to target a 
specific address, attributing the loop to a remote misconfiguration. 
However, if it is possible to screw up authentications, the probability to 
meet a loop is just its square, times the number of generators.


If the authentication is screwed up, sending a failure report is exactly 
the right thing to do.  That's what they're for.


I think we should close this.  DMARC is working the way it is supposed to, 
and people don't want to get reports about their reports, there are 
obvious ways to prevent them, like not sending unaligned reports, or 
sending reports from a domain that doesn't get reports back.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Sat 16/Jan/2021 22:30:56 +0100 Murray S. Kucherawy wrote:

On Fri, Jan 15, 2021 at 7:40 PM John Levine  wrote:


I still don't understand why anyone thinks there is a problem to be
fixed. If you don't want reports, don't ask for them. If you think the
mail you send shouldn't be provoking DMARC failure reports, adjust
whatever is sending the mail the mail is aligned, or get rid of the
ruf= that asks for the reports. What am I missing here?


You might be right, so I'll go back and ask this use case what the
specifics are.

What I'm concerned about is that since this has come up before N times
(for, admittedly, some currently small value of N), we've seen enough
disparate cases of it that we may be missing something bigger, and if so,
doing something defensive in the specification would be prudent.  There's
smoke here, and there may be fire.

Will report back.



Examining my report folder, I note I'm sending one-liner aggregate reports to 
domains I never wrote to.  The pattern is their sending me feedback for one or 
more mailing list posts, followed by my one-liner acknowledging their report 
later on the same day or on the next day, depending on their sending time.


It is not a loop, because I send from noloop.tana.it, which has no rua=.  I'm 
not alone using this trick.  Two naive report generators would continue to send 
one-liners indefinitely.


While this is a minor problem for aggregate reports, it can be a real problem 
for naive failure reports generators.  Juri reported he had to target a 
specific address, attributing the loop to a remote misconfiguration.  However, 
if it is possible to screw up authentications, the probability to meet a loop 
is just its square, times the number of generators.


The only prevention in the spec is to apply rate limiting.

I'd add a couple of loop-specific provisions:

* send reports from a subdomain having a DMARC record without ruf=,

* configure the verifier to not generate failures of messages destined to one's 
own ruf= address.


I shouldn't hurt, should it?

Best
Ale
--













___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

In article  you write:
>> My guess is that if we can track it down it is likely to be "my software 
>> is buggy so I want everyone else to work around it."
>
>The cases that I had to deal with were misconfigurations on the other
>side. I had to put these senders on some kind of ignore list to not send
>out failure reports for their failing messages. That stopped the loop.

I believe you, but did the fail loop cause a significant load on your
system, or were they just ugly?

As I've said before, if they're sending unaligned mail and have an
ruf= to ask for reports, I'd think it fair to assume they'd want the
reports.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Juri Haberland]

On 16/01/2021 23:20, John R Levine wrote:
>> What I'm concerned about is that since this has come up before N times
>> (for, admittedly, some currently small value of N), we've seen enough
>> disparate cases of it that we may be missing something bigger, and if so,
>> doing something defensive in the specification would be prudent.  There's
>> smoke here, and there may be fire.
> 
> OK, thanks.
> 
> My guess is that if we can track it down it is likely to be "my software 
> is buggy so I want everyone else to work around it."

The cases that I had to deal with were misconfigurations on the other
side. I had to put these senders on some kind of ignore list to not send
out failure reports for their failing messages. That stopped the loop.

Regards,
  Juri

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc