Dave
On Wed, Nov 27, 2024 at 7:15 PM Dave Crocker <d...@dcrocker.net> wrote: > On 11/21/2024 1:21 AM, Bron Gondwana wrote: > > I have made a second pass at it. Text below, or see the raw copy at: > > https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA > > > Summary: > > - As provided, this is an extremely broad and extremely vague > statement of work. It continues to sound far more appropriate for the IRTF > than the IETF, especially absent a concete draft specification to take as > input. (It's not as if the IETF hasn't accepted charters like this. But > it /is/ as if such working groups have typically not fared well. Stated > more baldly, "let's charter a group and then figure out what we are going > to do" has a bad history in the IETF.) > - The draft seems to include a target of 'trust relationships' which > is an open research topic that DKIM only indirectly relates to, except for > trusting a signature. > - IETF Internet Mail handling really only covers a single > posting/delivery sequence. It touches on more elaborate sequences, but > only piecemeal. And draft charter does not really note or deal with this > difference in scope. So the proffered 'holistic' effort is a very > considerable increase in scope from something labeled DKIMbis or DKIM2. > > > I agree that overly broad charters are mostly doomed. As Richard pointed out their motivation draft, and perhaps it should be mentioned in the charter. I'll leave that to Murray. DKIM2 Draft Charter <https://notes.ietf.org/#Background>Background > > Emails often flow indirectly through multiple systems, undergoing > redirection, expansion into multiple copies via aliases and mailing lists, > as well as rewriting and filtering before eventually arriving at a mailbox > or being processed by a receiving software agent. > > The opening sentence sets a stage that matches many end-user experience > views of email, but misses the basic technical distinction that is the > essence of the enhancement being sought. *As described in that sentence, > email is delivered more than once, before it is 'finally' delivered.* > So instead, perhaps: > > It is common for an email to go through multiple posting/delivery > sequences, before eventually arriving at a 'final' mailbox or being > processed by a 'final' receiving software agent. Examples of such > 'indirect' flow include redirection through an alis, expansion into > multiple copies via an alias or a mailing list, as well as rewriting and > filtering before eventually arriving at a mailbox or being processed by a > receiving software agent. > > I left 'rewriting' in but actually don't know what it refers to, nor why > 'filtering' is relevant to DKIM signature survival. > > (By the way, I thought that posting from an ESP was also classed as an > indirect flow. Is this not correct?) > I can see the distinction on the "final destination" of a message. Are you wanting to say every time an email is processed - redirected, expanded via an alias, etc that the message is 'delivered' ? then we'll want to be very explicit how "delivered" is defined - temporarily delivered before final/permanent delivered > > It will be necessary for any new design to work in parallel with the > existing mechanisms, and have a clear upgrade path. > > If it is parallel, it is independent. So I don't know what it means 'to > work' in parallel. And I don't know what it means to not work in parallel. > > > To achieve its goals, this work requires a wide scope. The design may > supersede, modify, or replace many parts of the current email > infrastructure and associated reporting mechanisms - while retaining the > ability to support existing use-cases. > Oh. In parallel with existing /email/. You want to replace the current > Internet Mail infrastructure. Gosh... > > Forgive me, but, again, this is something for the IRTF, not the IETF. > > > I don't believe anyone here will claim that DKIM2 will replace the current email delivering mechanisms. They will complement them, hoping to show a better way forward. But email, like other technologies, have a very long tail. > > - Mechanism document draft(s) adopted: Mar 2025 > > Only two more months for a stable specification effort? Really? > > > > - Experiments and updated drafts: Apr 2025 - Nov 2025 > - Implementation guide adopted: Nov 2025 > - Group of documents sent to IESG: Dec 2025 > > Richard already mentioned most working groups have given up putting delivering dates, and I agree with this. What the WG will deliver seems logical. tim
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
