Re: [dmarc-ietf] Third party signatures

2023-05-16 Thread Douglas Foster
Hector, my life is short, and this group already takes up more of it than my wife wants. If you are a subject matter expert on all of those RFCs, we need you to summarize the relevant pieces for those of us who are not. But you imply that if I read all of those RFCs, I would see that your

Re: [dmarc-ietf] Third party signatures

2023-05-16 Thread Alessandro Vesely
On Tue 16/May/2023 04:32:21 +0200 Hector Santos wrote: I find it technically unfeasible and non-logical to support a high overhead, complex ARC concept that has no promise of any solution for a DKIM Policy model we have been seeking since 2005. The concept evolved from the need to export

Re: [dmarc-ietf] Third party signatures

2023-05-15 Thread Hector Santos
Wei, Have you studied the past R and functional specifications, architectural surrounding SPF and DKIM leading up to DMARC? RFC5598 Internet Mail Architecture RFC5322 Internet Message Format RFC5321 Simple Mail Transfer Protocol RFC4405 SUBMITTER SMTP Service Extension

Re: [dmarc-ietf] Third party signatures

2023-05-15 Thread Wei Chuang
That's a good point around ARC as that's what it was meant to do. And that got me thinking that it might be helpful to systematically compare the different proposed approaches and their pros and cons. The next approach would be to consider the general approach of the reversible transform idea

Re: [dmarc-ietf] Third party signatures

2023-05-06 Thread John R Levine
It is not a commitment at this time. That said, we are interested in solving this problem and welcome collaboratively figuring out the right way to do this. It seems to me that ARC provides the useful parts of third party signatures and, while rather complicated, has the benefit of actually

Re: [dmarc-ietf] Third party signatures

2023-05-05 Thread Wei Chuang
On Tue, May 2, 2023 at 10:21 AM Murray S. Kucherawy wrote: > On Tue, May 2, 2023 at 10:06 AM John Levine wrote: > >> No large provider has ever expressed any interest in either so I cannot >> see any reason to spend more time on either one. >> > > I believe Wei has expressed interest in the

Re: [dmarc-ietf] Third party signatures

2023-05-03 Thread Alessandro Vesely
On Tue 02/May/2023 19:21:13 +0200 Murray S. Kucherawy wrote: On Tue, May 2, 2023 at 10:06 AM John Levine wrote: No large provider has ever expressed any interest in either so I cannot see any reason to spend more time on either one. I believe Wei has expressed interest in the transforms

Re: [dmarc-ietf] Third party signatures

2023-05-02 Thread Murray S. Kucherawy
On Tue, May 2, 2023 at 10:06 AM John Levine wrote: > No large provider has ever expressed any interest in either so I cannot > see any reason to spend more time on either one. > I believe Wei has expressed interest in the transforms stuff, but I don't recall whether that was a commitment to

Re: [dmarc-ietf] Third party signatures

2023-05-02 Thread John Levine
It appears that Murray S. Kucherawy said: >And I think the conditional signatures ideas suffer from the same two >issues I identified above. It's not quite as bad because with conditional signatures you can decide for each message if any third party signatures are OK. That mostly solves the

Re: [dmarc-ietf] Third party signatures

2023-05-02 Thread Wei Chuang
On Mon, May 1, 2023 at 8:23 PM Murray S. Kucherawy wrote: > Some thoughts about the third party signature discussion that happened > over the last couple of weeks while I was away: > > I wrote ATPS as an experiment in 2012. At the time we were still > finishing DKIM (RFC 6376 was only five

[dmarc-ietf] Third party signatures

2023-05-01 Thread Murray S. Kucherawy
Some thoughts about the third party signature discussion that happened over the last couple of weeks while I was away: I wrote ATPS as an experiment in 2012. At the time we were still finishing DKIM (RFC 6376 was only five months earlier), and still talking about whether a third party signing