> On Apr 23, 2023, at 4:17 PM, Dotzero <dotz...@gmail.com> wrote: > > On Sun, Apr 23, 2023 at 1:20 PM Hector Santos > <hsantos=40isdg....@dmarc.ietf.org <mailto:40isdg....@dmarc.ietf.org>> wrote: >> >> With each year, that "temporary hack" becomes the new normal and it >> will be harder to clean up. It is not the right way and I don't its >> too late to reverse. However, it has been 17 years and DMARCbis is >> not finished without some clean up in this area. > > It HAS NOT been 17 years for either DMARC (first published in 2011 and first > submitted to IETF as informational in 2015) or DMARCbis. Let's at least use > publicly available data points for time frames rather than time frames pulled > out of thin air.
Wow. I’ll apologize for the confusion. Allow me to paraphrase it: “However, it has been 17 years since the evolution of SSP, DSAP, ADSP, ATPS and now DMARCbis and unfortunately it is not finished without some clean up in this area.” A little better, I hope. I see all of the as a DKIM Policy Model and DMARC just happens to be current rendition of the concept. I have worked with all of them and before that, we did a real security analysis and requirements work. Not sure if you participated in this early DKIM wg work. >> >> I can understand why DMARCbis's editor does not want to document >> rewrite, but imto, can't be ignored anymore. The details of a >> rewrite can be quickly outlined. To help the RFC process, maybe >> DMARCbis could refer to the Functional Specifications of SSP (RFC5016) >> Section 5.3, Item 10 which basically reinforces the idea that local >> policy ALWAYS prevails and it is quite possible there will be >> undesirable tearing down of secured submissions. One possible >> mitigation is to replaced it with a secured rewriter with a p=reject >> policy. > > SSP is long gone and failed. Referencing something which failed to gain > support many years ago is also not a path to go down. I referenced the Functional Specification for SSP (RFC5016), not the SSP itself which was still only in draft form. https://datatracker.ietf.org/doc/html/draft-allman-dkim-ssp-02 The development and point of RFC4866 and RFC5016 was to help Eric and Jim create SSP and thats when Levine’s ADSP stepped in. From a software engineering standpoint, the documents provided the security analysis and requirements to make a "SSP” protocol. It does not change the original analysis or requirements. Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) https://datatracker.ietf.org/doc/html/rfc4686 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol https://datatracker.ietf.org/doc/html/rfc5016 Please review these, especially Section 5.3 of RFC5016. I was sort of helping DMARCbis. It can refer that provision to maybe justify the rewrite. After all, it was a game changer in all this when it was added. — HLS
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
