-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <CAL0qLwZ0yO=mh=byt6gc-_yfo2_uskqnmdkextreglyfbwl...@mail.gma
il.com>, Murray S. Kucherawy <superu...@gmail.com> writes

>    An Internet message (email) may, from creation to final delivery, 
>    pass through multiple intermediaries, some of which simply handle 
>    and route the message, others affecting an interim delivery and 

I expect you mean effecting (but rewording would be better)

>    re-injection into the ecosystem.  There are complexities with this 
>    handling model, such as evaluation, filtering, intentional 
>    mutation, and even malicious activities.

[...]

in your list of problems you have ignored the issue that ESPs have in
handling errors (they send messages on behalf of a client but reports
about delivery failures may pass them by and go back to the client).
They currently mangle various indicators of who generated a message to
address this, but that damages the notion you call authentication.

Whether you put better error handling in this section or the next I am
agnostic about, but I think it would be useful to mention it.

>    No optimal or preferred remedy to any of the above is provided by 
>    any contemporary technology.
>
>    Objectives
>
>    The working group will observe the success of current technologies, 
>    primarily DKIM, reusing its techniques where applicable, to develop 
>    a new technology suite that seeks to address these concerns.  Early 
>    experience from the deployment of ARC [RFC 8617] will also be 
>    considered.  

I note that experience is mainly negative (viz it has not proved to be
an effective fix) but yes, we should consider that.

>    To allow for widespread adoption, proposed solutions are expected 
>    to be robust in terms of interoperability and scalability.

The original expression of this notion (viz that the new proposal has to
be efficient at planetary scale) upset people. This text seems
sufficient to capture the concerns.

[...]

>    Proposed Milestones
>
>    [dates to be negotiated; focus on the sequence for now]
>
>    WG Formation: Jan 2025
>    Overview document: Feb 2025
>    Mechanism document draft(s): Mar 2025
>    Experiments and drafts: Apr 2025 - Nov 2025
>    Implementation guide: Nov 2025
>    Publish documents as a group: Dec 2025

I note that the overview document will require regular revision
throughout -- not so much as to the nature of the problems being
addressed, but how the (evolving in the light of experience) protocol
addresses them.  Also, it may be a matter of judgment what goes into the
overview and what goes into the implementation guide.

Of course all the documents may change as we go along but this one (with
it's early milestone) seems more likely to change than the others and
perhaps the text here should call that out.

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBZ4joAmHfC/FfW545EQJlXQCZAXR/Wt5bJFxKxjCH9NO9m7JZWVIAnigM
+kAdnEm1glDY9UbmnILD3nHv
=KQgm
-----END PGP SIGNATURE-----

_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

Reply via email to