Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
John R Levine skrev den 2023-06-20 02:25: On Mon, 19 Jun 2023, Patrick Ben Koetter wrote: I suggest that we do not only drop SPF, but also come up with better ways (simplification, tools, exchange formats) to implement DKIM in order to allow for a smooth transition. I'm scratching my head here. On my system I publish and rotate DKIM keys completely automatically. The only manual config is to edit the list of domains when I add or remove one from my mail server. It's not totally trivial but it's not that hard. I suppose we could encourage people to implement ed25519 signatures since the keys are small and more likely to fit in a single TXT record string for provisioning crudware that doesn't handle multiple strings, but beyond that, what do you have in mind? i see it as a problem, not as a solution, would we want all to be forced to accept new algo ?, will old be depricated ?, yes retorisk question i know, but be carefull, metacpan Mail::DKIM does not yet have it, but there is patches waiting so maybe it comes ? imho there would be more forward to see amavisd-new do ARC-Seal/ARC-Sign then to see it support one more algo in dkim, i know this is maybe just me ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
On Mon, 19 Jun 2023, Patrick Ben Koetter wrote: I suggest that we do not only drop SPF, but also come up with better ways (simplification, tools, exchange formats) to implement DKIM in order to allow for a smooth transition. I'm scratching my head here. On my system I publish and rotate DKIM keys completely automatically. The only manual config is to edit the list of domains when I add or remove one from my mail server. It's not totally trivial but it's not that hard. I suppose we could encourage people to implement ed25519 signatures since the keys are small and more likely to fit in a single TXT record string for provisioning crudware that doesn't handle multiple strings, but beyond that, what do you have in mind? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
* Alessandro Vesely : > On Thu 15/Jun/2023 23:25:44 +0200 Tero Kivinen wrote: > > > > I rerun the statistics and yes, there is 0.84% cases where dkim > > failed, but spf returned either pass, softfail or neutral. > > Many thanks. That figure seems to be more or less in agreement with what > others here have obtained on smaller samples. However small, it may confer > to SPF the role of a stabilizer in DMARC mail flows. The number of IP addresses in SPF-Records published by VLMPs foils the idea of "a controlled and limited number of host allowed to send on behalf of a senderdomain". Given the (internal routing) challenges you face when you try to publish a limited, dedicated IP range per tenant only, I do not see the current problem we have with SPF, when it comes to use SPF as identity anchor for email authentication, go away in the future. To me SPF destabilizes email authentication. It should not be used in future version of DMARC anymore. But why is it so many hang to SPF? My personal experience as a consultant is many domain owners prefer SPF over DKIM because SPF is easier to implement. They don't care about the one being the superior identity anchor to the other. They want to send. They want deliverability. And they want to get it done as soon as possible at the least investment. Business. Efficency. As long as I can think of generating and handling DKIM keys has been a pain. There's SHA1 and SHA256, then RSA and ED25519, then there's quite a variety of flags to publish (test mode, email usage only, ...) and even if you managed to get all of that right you are likey to fail when it comes to publish the DNS TXT record. It's overly long requires multiline quoting etc. pp. and I've seen experienced DNS operators fail repeatedly to get it right at first attempt. Many get publishing DKIM keys wrong, but that doesn't hurt them as long as SPF passes during DMARC authentication. They can send. They get deliverability. Why bother with DKIM problems? If we drop SPF in DMARCv2 SPF in all its dominance will suddenly be absent and DKIM with all its implementational problems will suddenly be fully exposed. And people will suddenly be forced to implement DKIM and suffer from all the pain I've described above. I do expect them to be not amused - to put it friendly. I suggest that we do not only drop SPF, but also come up with better ways (simplification, tools, exchange formats) to implement DKIM in order to allow for a smooth transition. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
On Sun 18/Jun/2023 23:06:59 +0200 Ken Simpson wrote: The hosting provider has to hook up everything for them and presumably, with enough encouragement, we could eventually get hosting companies to implement DKIM signing for their customers. That is not the case today. Domain-based authentication was conceived exactly because end users have a hard time trying to understand authentication mechanisms. Hosting providers who cannot do DKIM, on the other hand, are certainly not professional. Some transactional email providers provide a DKIM signing service with CNAME-based DKIM key hosting. This trick is used when the signing server is detached from DNS. They create a public key and publish it under their own domain, then ask the user to publish a CNAME pointing to it. The user could have published the public key directly. The need to resort to pointers stems from difficulties in publishing long RSA keys, which required to increase the maximum length of TXT data in some DNS web forms. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
