Jaroslaw Rafa via Postfix-users wrote in <[email protected]>: |Dnia 2.10.2025 o godz. 16:58:57 Steffen Nurpmeso via Postfix-users pisze: |> I can only concur. And in the future DKIM cryptography could mean |> more as it does today even, when message content can be verified |> over all transformations along the message path, back to the |> original sender: then the value of that key is absolut. | |If you want to verify message back to the original sender, S/MIME is \
Yes, i am all for S/MIME (and please give me good DNS records, SMIMEA cannot be it), or OpenPGP (definetely not, OPENPGPKEY). But .. that has nothing to do with DKIM. |the way |to go (or PGP/MIME, but you then have to somehow obtain the sender's public |key in a trusted way - keyservers etc.). DKIM will never verify that the |person who sent the message is really the person who he/she claims \ |to be, as |DKIM keys are tied to a domain, not to a particular user. It also won't |verify that the message hasn't been changed on the sending server after |being already submitted by the sender, but before being DKIM signed. Ok first, i am not interested in intellectual games or "making points" for the purpose of showing around "that full book" or something. You may be happy if i tell you that Dr. John Klensin said something similar in spirit quite some months ago. Other than that i am not continuously reiterating others are a thread, while at the same time it is noone but me, almost all the time. So DKIM does *exactly* what it is for, it allows cryptographical verification that a message was sent by a certain domain. There is the i= tag available to include whatever identity the sending domain claims necessary. Without advertising, but i know it from communication with my mother plus, that for example web.de uses it for that purpose, even though it (i never tried nor consciously saw otherwise) possibly does not matter since From: is always the same value.(?) So. That is that? Just use it, and it delivers. |By the way, I already receive e-mails eg. from my bank or from my phone |provider that are S/MIME signed, email client verifies them automatically |when they are displayed and displays the prominent message above the email |content that the signature is correct (or incorrect, if it happens \ |to be the |case - it happened a few times when they didn't renew the certificate on |time). That seems to be already widely implemented and work pretty \ |well. Why |reinvent the wheel and use DKIM for anything else that it is meant \ |for, ie. |to verify the authenticity of the domain the message claims to be from (and |this only)? You miss the point, maybe consciously so. These technics are available for over the quarter of a decade, and it really, really disappointed me when with the new German passport ~25 years ago did not automatically ship with PGP and S/MIME certificates issued by some "German State CA". Passport here, passport there, really. Alongside some small notification for hm "education". But so they did not, no notification at all, not even some notice letter during COVID, you know, and man was i happy when Göring-Eckardt said that on the Sunday Evening Talk in TV under public law, once they took government then, yet, no letter to this very day. So it is. In short: noone uses it. Only a fraction. Heck, yes, i have deals with Paypal, not even that "bank". Would be easy via some interchange via Web interface for example, then encrypted communication all through. And then CA pools are evil. Secure DNS somehow is not easily available, not to me, at least; i guess to many, if not most "normal" people with simple accounts. Do the all-american giants offer this for their billions of accounts? For paid ones? Via web interface? But this is all DKIM off-topic. |In short: if you want the capabilities provided by E2E authentication, use |E2E authentication. Not MitM-2-MitM authentication :) (as both sending and |receiving servers can be considered MitM from the security point of view). Well like i said but you did not quote I'd only wish the IETF would revert their many faults, and *really* go DKIM, and give it the value it deserves. And you miss the point. The point is that "the internet" WANTS to apply policy! The point is that DKIM uses the best possible approach of security i know, public key cryptography. Just like the TLS the data is moved over, where that practically CA-pool-based P-K-C is considered the best. Yet DKIM's P-K-C is not worth a thing. Instead we have a plethora of standards, sometimes even totally brain damaged -- like ARC for example: it cryptographically signs completely unverifiable data! I mean, imagine *that*! Actually i wrote a message where i gave again (i talked too much the last years) most of the reasons: https://mailarchive.ietf.org/arch/msg/ietf-dkim/cEUtXTH5kJtL8gs2k7I9NSsOVcA/# Needs to be scrolled down a bit before stuff comes. So if servers set i= you (or they themselves, without looking into logs) can have a real UID, if mailing-lists mitigate due to message adjustments they perform, which i both agree with a hundred percent, for as long as that DMARC shit exists at least, then on the DKIM level it can still be cryptographically verified, up to the original: and, and this is especially important to me, *user interfaces* can adapt, and can for example both the "X via Y" syntax in the From:, but also the Author:, and also the *restored* From: (and the Sender: that DMARC destructed), the *original* one, as it was sent out. One can then say, with mutt or the shitty MUA i maintain, for example, Y is a mailing-list (here mlist/mlsubscribe LIST), and then the *user interface* can adapt. In fact i personally would do this all different, and the BSI is just talking rubbish as for fools [2] with all the things it writes. For example "DKIM – Oh, die E-Mail kommt wirklich von meiner Chefin", "Oh, that email really comes from my female boss", HAHA!, what pseudo woke shit, my vaginale and clitoris piercings prance!! (All german there.) But that aside. [2] https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Onlinekommunikation/E-Mail-Sicherheit/technischer-Hintergrund-E-Mail-Sicherheit/technischer-Hintergrund-E-Mail-Sicherheit_node.html So then DMARC is gone, SPF can vanish or is simply "-all", ARC is nothing but a shame and ever was, DKIM is cryptographically verifiable all through, and, with DNSSEC, *hard*: just like a TLS connection does not even establish when crypto fails, so it is with email. Of course my as published (the better one) and their as published standard draft(s) do not handle intermediate hops which simply discard headers or one to several MIME parts due to local policies, like removing images etc or what, i think those should not be passed further on, and then this includes the DKIM backup data. But so it is. --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) _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
