Alessandro Vesely wrote in <319a066f-5719-4569-8e5e-3d46cef5b...@tana.it>: |On Thu 07/Nov/2024 01:26:46 +0100 Bron Gondwana wrote: |> I think now is an ideal time to re-start this work at the IETF. \ |> The design is |> still evolving and there's plenty of space for an IETF working group \ |> to improve |> it further, yet it's also had enough design work put in by people with |> operational experience that we have implementers who think they can \ |> make it |> work at scale. | |The design is very cute, as it aims to fixing all the difficulties that |domain-based email authentication currently shows. I'm looking forward to |reading new discussions on this list. | |However, I'm a bit puzzled by the features that look difficult to implem\ |ent |inside a "classic" filter module. It seems that the MTA has to handle \ |some |situations natively (multiple recipients, bounces). This implies the \ |time to |market won't be short. So, while we work on DKIM2, we shouldn't stop
Fwiw i will post two drafts as envisioned in March 2023 and then on 2024-05-30 with the message https://mailarchive.ietf.org/arch/msg/ietf-dkim/DuinnZFuaFaKughaXSxkYwtRjMw and fixup https://mailarchive.ietf.org/arch/msg/ietf-dkim/KvlqUCMEf5wnkuK6TiXws61RBeQ Funnily i said Because in the end noone would like to duplicate all the headers (that have changed) plus the body etc, even comprimized, on each station anew, to be able to track it all the way down to the originator. but i really like this possibility to have email "cryptographically verifiable up to the sender", of course. The DKIM-Store: draft can very well be used with a future DKIM2 since milter-based and any other non-integrated software solutions need to pass state from "ingress to egress" in order to be able to create a diff, say, and the infrastructure should (imho) be be capable to filter such lengthy data which accidentally escapes due to, for example, software bugs. The other draft will be "DKIM, now horny" and will include the flags "V" as well as "S" to report verification success and thus replace the overly chatty and then useless Authentication-Results:, as well as "M" to signal message modification. It will require hard SMTP bounces upon verification failure (if so announced by sender DNS that replaces DMARC), so that the normal SMTP protocol kicks in to handle such problems. There are no XML reports: SMTP nows about the RFCs 3461, 3464 and therefore "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)" as well as "An Extensible Message Format for Delivery Status Notifications", so it seems absolutely superfluous to add a complete report bypass mechanism on a domain basis, as the user gets standardized notifications upon request (and that request my come from the SMTP administrator even). It will also include the subsignatures for replay resistance. In the "M" case it will not be able to restore the original email content. But, except for the subsignatures, it should be *very easy* to implement it in software *fast*. |considering easier alternatives that can make ARC more usable for trusted |forwarding and mailing lists, perhaps on a different list. You cannot warp trust around the corner. --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) | |And in Fall, feel "The Dropbear Bard"s ball(s). | |The banded bear |without a care, |Banged on himself fore'er and e'er | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
