Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Murray S. Kucherawy
On Fri, Jun 9, 2023 at 8:49 AM Alessandro Vesely wrote: > On Fri 09/Jun/2023 16:07:07 +0200 Murray S. Kucherawy wrote: > > And signing software shouldn't be mutating messages ever (other than > adding > > signatures, of course). > > Section 5.3, Normalize the Message to Prevent Transport

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Barry Leiba
1. It is out of the scope of our charter to make any changes to SPF, and that would include making it obsolete or Historic. 2. It is within the scope of our charter to make changes to DMARC, and that would include removing SPF evaluation from it. During the process of making changes to DMARC we

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Hector Santos
Barry, Whoa! Take it easy. We are on the DMARC2 thread per topic - a proposal. Not anything for the current DMARCbis. Is the chair suggesting the current charter for DMARCbis should change to remove SPF? Was the charter changed for this? To be clear, DMARC2 is not DMARCbis right now, are

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Barry Leiba
Hector, did you not understand this?: >> We will *not* consider what should happen to >> SPF outside of DMARC, and any discussion of that is *out of scope* for >> this working group under its current charter. Please stop discussing it. Barry On Fri, Jun 9, 2023 at 8:23 PM Hector Santos wrote:

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Hector Santos
> On Jun 9, 2023, at 4:41 AM, Barry Leiba > wrote: > > Repeating this one point as chair, to make it absolutely clear: > > The proposal we're discussing is removing SPF authentication from > DMARC evaluation *only*. We will *not* consider what should happen to >

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Barry Leiba
Thanks for the follow-up, Scott. > It's not a case of I've seen a few failures, it's consistent (all I can say > for certain is that it was as I no longer have access to this data). It was > consistent across time and providers. At scale, DKIM would always have a > fraction of a percent failure

Re: [dmarc-ietf] version bump to DMARC2

2023-06-09 Thread Barry Leiba
Keep in mind that we have looked at this extensively, and what we've found is this: 1. Almost all [1] of the DMARC senders out there will see the same results when recipients look them up using the tree walk as they have using the PSL. In other words, the change will be different an *extremely*

Re: [dmarc-ietf] version bump to DMARC2

2023-06-09 Thread Emil Gustafsson
Not sure if I am that someone mentioned. In case I am - I'd like to clarify what I meant; Without a version change for the tree-walk, I think we (Google) would need to support both approaches (the old one plus the tree-walk) and based on what we see - make a best guess which version we should

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Alessandro Vesely
On Fri 09/Jun/2023 16:07:07 +0200 Murray S. Kucherawy wrote: And signing software shouldn't be mutating messages ever (other than adding signatures, of course). Section 5.3, Normalize the Message to Prevent Transport Conversions, gives different advice. UTF-8, though, seems to be subject to

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Alessandro Vesely
On Fri 09/Jun/2023 11:14:29 +0200 Barry Leiba wrote: One case I saw multiple times where DKIM fails while SPF verifies is when the message contains a line starting with "from " which some agent changes to ">from ". Some signing software eliminates such lines before signing, but that's not in

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Scott Kitterman
On Friday, June 9, 2023 4:33:54 AM EDT Barry Leiba wrote: > I think, Scott, that you and I have a fundamental disagreement that's > not resolvable, and I won't just repeat what I've already said. But a > couple of the things you said are ones I can't make sense of, so I'll > > talk about those:

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Murray S. Kucherawy
On Fri, Jun 9, 2023 at 2:14 AM Barry Leiba wrote: > > One case I saw multiple times where DKIM fails while SPF verifies is > when the > > message contains a line starting with "from " which some agent changes to > > ">from ". Some signing software eliminates such lines before signing, > but > >

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Barry Leiba
> One case I saw multiple times where DKIM fails while SPF verifies is when the > message contains a line starting with "from " which some agent changes to > ">from ". Some signing software eliminates such lines before signing, but > that's not in the spec, so one cannot say a signer is defective

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Alessandro Vesely
On Thu 08/Jun/2023 16:44:14 +0200 Barry Leiba wrote: See, I don't look at it as "harmed".  Rather, I think they're using "we use SPF" as a *reason* not to use DKIM, and I think that *causes* harm. Does that mean SPF is easier to enter than DKIM? Maybe. It can be an advantage, though.

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Barry Leiba
Repeating this one point as chair, to make it absolutely clear: The proposal we're discussing is removing SPF authentication from DMARC evaluation *only*. We will *not* consider what should happen to SPF outside of DMARC, and any discussion of that is *out of scope* for this working group under

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-09 Thread Barry Leiba
I think, Scott, that you and I have a fundamental disagreement that's not resolvable, and I won't just repeat what I've already said. But a couple of the things you said are ones I can't make sense of, so I'll talk about those: > Software engineering isn't a perfect science. In general, a more