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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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"

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

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

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

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

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

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

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

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

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

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