Dave Crocker wrote in <[email protected]>: |On 6/18/2025 2:15 PM, Bron Gondwana wrote: |> But also, did a lot of thinking about how to support multiple RCPT-TO |> in a single SMTP transaction. .. |Simple question: Why?
Sorry, i have to overwhelmingły oppose. He gave the reason himself by giving the number of GMail subscribers to this list only. May anyone on this list counterspeak, mailing-lists were one of the first use cases, they are used now, and they may came back in a greater fashion in the future. Lots of software development (still) happens via mailing-lists, for example, just take the Linux kernel, which drives de facto all supercomputers on earth, smart phones, car computers etc etc. In conjunction with the giant mailbox providers, and alias concepts like for example kernel.org, or freebsd.org, openbsd.org etc etc, but also companies and their departments, there is a massive scaling effect. And with a massive scaling effect you get lots of I/O reduction, and also CPU usage reduction. |There was extensive discussion about multiple recipients here, on the |working group mailing list, where decisions are made for the working |group's woirk. | |I am pretty sure my reading of that discussions is accurate, which |simplifies to: the number of cases that currently use multiple |recipients is vanishingly small, and so such support is not essential. I for one reiterate that it is in my opinion *completely inappropriate* for a, well, simple SMTP signature cryptography helper to mutilate its base protocol. The idea alone is completely beyond my understanding, in fact. And i -- on my way out, luckily -- never understood why this was even considered! |*Adding mechanisms that are intended to support vanishingly small |portions of cases -- and especially where that support only provides |efficiency rather than necessary functionality -- is pretty much always |a terrible idea for a global standard.* | |It adds complexity to everyone's code, needs testing and ongoing |support, and gets excercised infrequently enough to make it likely that |it won't actually work when it is needed. That is, it is expensive and |fragile. | |And then there is the small matter of working group rough consensus that |runs contrary to the pretty-clear rough consensus that I thought I saw |before, /against/ support for multiple addressees in a DKIM signature. And, lastly, this is (or was) just a complete deficit of the other approach that you call DKIM2. It is just bad! It is/was a design fault. With ACDC it is easy and minimal to get there: MAIL FROM: <[email protected]> RCPT TO: <[email protected]> RCPT TO: <[email protected]> DKIM-AC: sn=1; s=K1; [email protected]; d=f.g; t=d; t=e; b=... ^ DKIM-Signature sequence,.. ^ ..selector ^ sig I say goodbye to you already here, Mr. Dave Crocker, unless a correspondence would unfold. It was an honour! Greetings, and Ciao!, from Germany, --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
