Hello Kirill. Kirill A. Korinsky wrote in <2fdd33f2325e6...@mx2.catap.net>: |On Sat, 11 May 2024 00:21:18 +0100, |Steffen Nurpmeso <stef...@sdaoden.eu> wrote: |> Kirill A. Korinsky wrote in |> <5285e80cbc0d1...@mx2.catap.net>: | |BTW this is quite wired address which seems like Message-Id
That is what it is. |>|I imply that using ed25519 usually leads to malformed signature, and some |>|big hosting providers treat double signature as bad signature if some of |>|them are not RSA-SHA256. A notable example is icloud.com, which delivers \ |>|\ |>|all |>|emails with double signatures to the junk folder. At least that's \ |>|what they |>|did the last time I checked in December'23. |> |> Then these are not standard compliant. The DKIM standard 6376 |> *explicitly* supports multiple signatures. | |Yes, RFC may imply that but OpenDKMI was released quite a while ago and the |last stable release seems that doesn't handle well this case. OpenDKIM cannot. I looked at its code in about January and there is no notion of it. zdkimfilter as of courier bases upon it, and supports it. (Very preprocessor sprinkled crypto code in between several libraries that uses, though, and the OpenSSL 3.0 thing even fiddles with openssl parameters which i have *not* understood from my short glance..) |>|So I suggest to put in README and config exmaple that using anything \ |>|other |>|than RSA-SHA256 may lead to delivery email to thte junk. Unfortunately, \ |>|this |>|includes duble signatures as well. |> |> On the IETF DKIM list there are people which told me they use such |> a configuration since 2019 without any issues, and i myself use it |> for two months, too, and did not have problems; that cloud thing |> i never saw, though. | |Here I've sent to some tool which is used to check email configuration a |test email with 2 singatures [1] and with 1 [2], the same behaviour \ |I saw in |icloud.com. | |I've tracked that issue last Decemner and it had status that second |signature or non RSA-SHA256 leads to not valid signature and delivery email |into junk folder. Probably. | |Footnotes: |[1] https://mxtoolbox.com/deliverability/8d9efa25-f421-4582-a0fb-652f01\ |46dfce | |[2] https://mxtoolbox.com/deliverability/42b985b2-c8a1-44b2-a9ed-4bf86a\ |604e54 It does not matter that the Ed25519 code is not understood, the RFC 6376 is a very, very thought through standard and has all that foreseen indeed. From a short look at the first it seems your real problem why this fails is that *all* signatures are rejected, and the RSA is because it uses SHA-1, however, SHA-1 was explicitly forbidden by RFC 8301 as of January 2018: Due to the recognized weakness of the SHA-1 hash algorithm (see [RFC6194]) and the wide availability of the SHA-256 hash algorithm (it has been a required part of DKIM [RFC6376] since it was originally standardized in 2007), the SHA-1 hash algorithm MUST NOT be used. This is being done now to allow the operational community time to fully shift to SHA-256 in advance of any SHA-1-related crisis. I could very much imagine that if you change to RSA-SHA256 then your problem will vanish. --End of <2fdd33f2325e6...@mx2.catap.net> Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
