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

Reply via email to