Michael Thomas wrote in <af5f8fd7-32d8-4e16-b806-10510da14...@mtcc.com>: |On 3/16/25 5:34 PM, Richard Clayton wrote: |> In message <f7a46a8e-6e19-458f-a34c-93d70ed7d...@mtcc.com>, Michael |> Thomas <m...@mtcc.com> writes ... |>> PPS: I'm don't understand why this requires the rt= to be limited |>> to just one address. |> |> simplicity ... at the point at which an email is being signed it is not |> possible to know how many recipients the receiving MTA will accept after |> each MAIL FROM | |Why is that "simple"? If an MTA wants to sign, why should it care how |many rcpt-to's it sends? It intend each of the recipients, after all. I |don't get what the supposed security property is of limiting it to a |single rcpt-to. Is there one?
That would be interesting. |We should not be making breaking or constricting changes to the mail |architecture unless there is an overwhelming need. "simple" ain't |"overwhelming". It is of course not simple. Maybe simple minded, but especially that not, given the involved personalities. But i am thankful that someone with such an IETF reputation speaks at least for enlightenment, if not for opposition except for reasons of technical necessity! *Thank you*, dear Michael Thomas. Now. I see DKIMACDC does not yet address the topic of emails which get splitted in transit due to recipient limits being reached, resulting in a number of independent transaction with receiver subsets. Thank you, yes, that is not addressed yet. *However*. This does not justify mutilation of the entire SMTP protocol. It only notes a deficit of the current ACDC draft. 'Seems to me the cache addressing man-in-the-middle replay is becoming a necessity, and unless all per-receiver-domain- subsignature covered RFC 5321 envelope recipients have been been seen, we still collect on-the-fly data. Well i mean, that is easily solved (not to say, say, isn't that easily solved) in a very natural fashion, because you need to have the recipient list of the subsignature as well as the real SMTP recipient list around, in order to compare them. We learned you need a persistent cache. The cache needs entries for all members not yet addressed, if (and only if) at the end of message processing not all members of the subsignature have actually been seen. Kind of a "reverse SMTP queue". I mean, HEY! If that DKIM2 can mutilate SMTP and cause this I/O bound protocol to become a single-recipient-only disaster (no one asked on the -smtp@ list yet), then ACDC can still choose not do, but have a possibility to at least temporarily have more data in the t= to x= delta cache, a case that in practice will not be used often. (Especially when Google throws out that darn= monstrosity.) One more point *against* DKIM2, and one more point pro ACDC. We *know* what to expect, and we can count off what is seen. *Less* cache, *less* I/O, more performance. VERP+BDAT. Maybe Hancock's RockIt now.. So despite the bizarre ignorance of my person from the very start of my vocal appearance in this working group .. i do not know .. 3-5 years ago, only to mention that if the wg really takes this technologically second-class DKIM2 approach i want to see me acknowledged exactly via "inspired by, but not in spirit of bla bla bla" (where "bla bla bla" is acceptable as such). This sugarbaby personality WG is real fun; luckily i also take part a very, very little bit in some opengroup WG, and that standard does neither need any uppercase characters, nor such a fancy attitude. Hasta la victoria siempre. --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) _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
