Murray On Wed, Dec 11, 2024 at 4:59 PM Murray S. Kucherawy <superu...@gmail.com> wrote:
> I've uploaded the charter text at the top of this thread to the tracker > (not the one from 11/27 yet). I wanted to do another round trip on some of > Dave's points. > > I am not concerned with milestones yet. The text is far more important. > > On Wed, Nov 27, 2024 at 4:15 PM Dave Crocker <d...@dcrocker.net> wrote: > >> 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.) >> >> > Bron (or anyone involved), do we have any initial documents to propose > formally in the charter? > We have none listed but draft-gondwana-dkim2-motivation should probably be listed. There are a few others but I will not judge those >> - >> >> 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. >> >> > Would like to hear other opinions of this. > >> 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 presume "filtering" includes any sort of stripping of material an > intermediary or edge MTA might consider to be worth stripping for whatever > reason (e.g., malformed header fields) but I agree that an example might be > helpful to clarify. > > I imagine "rewriting" is there for any of a number of reasons. Very early > on in my email career I used to see things like m...@example.com used > externally but it was rewritten (unnecessarily, it turns out) to > m...@host.example.com prior to delivery when the main ingress server > figured out which host was mine. There are probably more apt modern > examples. > > >> 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. > > > I imagine the intent is not to disrupt the deployed DKIM base while DKIM2 > (or whatever) is being developed or deployed. > I believe this is the correct interpretation. I wonder if there are going to be any claims on backward compatibility into the future ? I think that should be spelled out somehow. tim
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org