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] understanding section 7.2

On 1/27/21 12:40 PM, Brotman, Alex wrote: Murray, That is on my to-do (though not ticketed). I’m not quite sure how elaborate the example should be, but at least enough to demonstrate a basic report. I opened a ticket on this yesterday. I think it's 102. Mike -- Alex Brotman Sr.

Re: [dmarc-ietf] understanding section 7.2

Murray, That is on my to-do (though not ticketed). I’m not quite sure how elaborate the example should be, but at least enough to demonstrate a basic report. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc On Behalf Of Murray S. Kucherawy Sent: Wednesday,

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] understanding section 7.2

On 1/27/21 12:14 PM, Murray S. Kucherawy wrote: The schema's already pretty large, and probably has to be, but maybe a trivial example report would be reasonable to craft and include? Yeah, that might do too. I think it's important that it be in section 7.2 though because you should be able

Re: [dmarc-ietf] understanding section 7.2

The schema's already pretty large, and probably has to be, but maybe a trivial example report would be reasonable to craft and include? On Tue, Jan 26, 2021 at 11:05 AM Michael Thomas wrote: > > So I'm an outsider who has not tried to digest what's going on in the > reports until recently so my

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] Ticket #1 - SPF alignment

On Wed, Jan 27, 2021 at 9:26 AM Alessandro Vesely wrote: > AFAIUI, there's no reason why SPF would work with a logic substantially > different than DKIM's. DKIM can provide n identifiers, if one of them is > aligned and "pass", then DMARC is "pass". SPF can provide 2 identifiers > but > one of

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Wednesday, January 27, 2021 12:25:59 PM EST Alessandro Vesely wrote: > On Wed 27/Jan/2021 15:00:29 +0100 Scott Kitterman wrote: > > On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote: > >> On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote: > >>> On Tuesday, January 26,

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] Ticket #1 - SPF alignment

On Wed 27/Jan/2021 15:00:29 +0100 Scott Kitterman wrote: On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote: On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote: On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote: On Tue 26/Jan/2021 14:14:45 +0100

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] Ticket #1 - SPF alignment

On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote: > On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote: > > On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote: > >> On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote: > >>> On Tuesday, January 26,

Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

On Wed 27/Jan/2021 12:31:51 +0100 Douglas Foster wrote: Is this already a settled issue? There doesn't seem to be a consensus, yet. I repeat what I already proposed: * max number of DKIM signatures: 1024 (say) * min number of DKIM signatures: 0 * can report unverified signatures (none) *

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] Which DKIM(s) should be reported? (Ticket #38)

Is this already a settled issue? The specification already calls for a complete A-R data set, so all signatures are supposed to be included if they are evaluated. Are the largest reporting sources already providing a complete list of DKIM signatures? However, there are significant technical

Re: [dmarc-ietf] nit in section 7.2

On Tue 26/Jan/2021 19:58:36 +0100 Michael Thomas wrote: "The report SHOULD include the following data:" Normative SHOULD here since very strange because what follows is informational, and why would it be SHOULD in the first place? It seems to me it ought to be: "The report includes the

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote: On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote: On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote: On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote: I doubt that SPF filters report