Matus UHLAR - fantomas via Postfix-users wrote in <zung2roerz2hy...@fantomas.sk>: |>Jens Hoffrichter via Postfix-users wrote in |> <CAFPt6W_xnY48aX5ocqGuwuSVvvOj2dksRoFc=2mv1X=g9lz...@mail.gmail.com>: |>|On Mon, Oct 30, 2023 at 8:12 PM Steffen Nurpmeso via Postfix-users |>|<postfix-users@postfix.org> wrote: |> ... |>|> Btw i would wonder: why do -- as email operators -- still use DKIM |>|> at all, since there is ARC and it also offers signatures and |>|> verification? The OpenSSL (-users) ML uses it, and it only. |> ... |>|Because Google / Gmail / Google Workspace will put out DKIM |>|requirements for every email from bulk senders from Feb 1st - not ARC |>|requirements. From what I understand, DMARC alignment only happens on |>|SPF and DKIM alignment, not on ARC alignment - and because of that, |>|DKIM is relevant for us. | |On 01.11.23 03:15, Steffen Nurpmeso via Postfix-users wrote: |>I did not know that. I had the impression Google pushes ARC. But |>i never find anything in their help (and stopped pressing buttons |>for "was this page helpful"), nor have i ever heard such.
I make it a bit shorter, as i am coming from a different view. |ARC is third-party signature basically saying that |"DMARC was okay when we receive this e-mail". | |You must configure trust to the concrete ARC signers, as you cannot simply |trust mail from random domain saying "this mail from gmail.com was \ |okay when |we received it", as creating ARC signatures with fake original content is |easy. | |with DKIM, everyone signs their own mail, so this 3rd-party trust issue \ |does |not appear. - DKIM was introduced without any support for mailing-lists, effectively breaking all mailing-list of the world. Unless they strip DKIM. Even that not. In the end you have to rewrite fields to totally hide the real author. Mailing-lists are the absolute foundation of email and "forums" for the "community" since at least the earliest 80s. |>I myself have deepest respect for the engineering of SPF (the RFC |>that is), but do not understand it regarding email flow, you have |>to run postsrsd to make this work if you have redirecting aliases, | |When you forward mail from gmail.com to us, keeping original envelope \ |sender |e.g. postmas...@gmail.com, we only see mail claiming be from gmail, but |originating your server, which means the sender may be forged. | |SPF is here to block this e-mail, and SRS is one of techniques to rewrite |envelope sender to your domain, while keeping enough of intormation \ |for you |to later see that the mail indeed was forwardd through your server, if the |forward fails. - SPF breaks all hosts which have users that effectively want their email to be forwarded to a different address. This is basically any campus, and much, much more. Your are forced to install software which complicates the email stack, that creates temporary "users" for a "configurable" amount of time in order to handle emails. The database can grow a bit. |You of course can set your sender to anything in your domain, but with |setting sender to the original recipient, which may seem reasonable |(setting sender to the user who wishes to forward their e-mail to gmail) |you risk creating forwarding loop to |- each mail to that user gets forwarded to non-existent address, bounce is |generated which is again forwarded to non-existent address... |(and some servers or software don't create bounces with empty from). | |>and in the end i myself do not care at all how the mail is hopping |>if only it is delivered to the right place. Especially so if the |>email is DKIM signed and/or S/MIME aka PGP signed/encrypted. |>And DMARC i truly hate. :) | |>Well i keep on hoping that DKIM is fixed to work also for MLs |>without robot trouble (user interfaces are the other thing), it |>would be all i need. | |DKIM cryptographically signs the e-mail body and headers, so everyone can |verify if it really came from the domain in header From:. | |Mailing lists that modify signed heaers or body of mail by e.g. adding \ |list |signature to Subject: or body, invalidate this signature. | |One of solutions is to forward the original signed message intact as |attachment, other is to change From: and DKIM-sign the new message \ |with domain in |mailing list From:, so the new DKIM signature is correct. This is you operator view to work around this pale of mess that was thrown onto you from the IETF (or its driving forces). Btw the attachment thing does not work out was ensure to me on a different list with very famous people on it (and at least one idiot), it seems that many mailers are not capable to deal with that properly, then. |DMARC on domain simply configures, that all mail from that domain passes |DKIM ot SPF check from that domain, and what to do with mail that does not |pass either. |(once more: DKIM applies on header From:, SPF on envelope from:). Regarding SPF i can imagine that it really makes sense for some use cases. (However, in my opinion, it is a real master piece on the one side -- yes it is! --, but otherwise _overengineering_.) But it puts a tremendous burden. Onto any forwarder. Things break otherwise, and likely the forwarder does not even recognize those bounce mails. :) I personally see this differently. For me DKIM it is. The domain has a secret key. If that is lost, someone may fake your identity. With SPF, that could at least be detected. But i mean, hey: you have to loose your private domain key. DKIM should be fixed so that mailing-lists and other operators *at least gain the possibility to integrate themselves*. That is "easy". Provide a standardized message header that can be used as backup storage. Ie, DKIM-Backup:. With that a mailing-list software can take all fields it modifies, and place them as (maybe compressed, base64-encoded, whitespace-neutral) entries in this field, then include it in their own DKIM signature. Then, the DKIM of the new message verifies ok for the mailing-list, and the DKIM of the original message can be verified, too, because they can be restored. Of course user-mail-agents have to be enabled to show all those layers, just like for S/MIME and PGP. Ie there is a verifiable layer in a verifieable layer etc..., and a user should be able to say "it is ok, if it all verifies just show me the message as-is from this host/user chain", or so. But that is a user-interface problem, not "a server one". You know: they did not even care to *offer the possibility to do something* for over a decade. With all the pain and noise that could be heard on so many lists i am subscribed to. A problem is the body. If it is modified. But as some services hammer a copy of the body into the headers anyway. You know: that all is moot. Who am i? If Google would start doing this, maybe. But a Google employee has created an ARC extension, i think it will do something like this automatically, fully automatic, whether needed or not (some months passed since i read the draft), so then, that. So then ARC can sign an email, can verify an email, can take care that there is a cryptographically verifiable path from the sender, over all hops, modifying or not, to the receiver. Fully automatic. Why do i need DKIM or anything else thereafter? Again: the possibility exists to extend DKIM backward compatibly to offer this in a friendly way, where needed. For what do i need ARC then? I mean -- *i* would not re-send out a mail after this new DKIM was present but did not pass the test. Sending out the message again *is* the "seal" that i verified an email that has DKIM ok. And for what do i need SPF? If all hops can verify my DKIM key, as they can, if used, my S/MIME or PGP key? Where is the difference? I do not care where it went as long as it arrived. Lesser configuration, lesser hassle. Same security properties (the "new DKIM" DNS entry existence' announces that re-creatable DKIM must be present). If i would have a voice, i would try this scheme out. --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 -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
