On just two points:
On 24 Jan 2025, at 7:51, Dave Crocker wrote:
On 1/14/2025 6:40 PM, Murray S. Kucherawy wrote:
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
re-injection into the ecosystem. There are complexities with this
handling model, such as evaluation, filtering, intentional mutation,
and even malicious activities.
A basic problem, throughout this entire discussion, has been the
effort to treat simple relaying through MTAs, and a
multiple-posting/delivering forwarding sequence such as with mailing
lists, as the same thing.
The paragraph in the charter does not use the words "relay" or "MTA" at
all and, as far as I understand, it is not intending to describe or
refer to them. It is talking about "intermediaries", which I take to be
pretty close, if not identical, to the RFC 5598 term "mediator"; the
only difference seems to be that the above wants to capture bad actors
who engage in similar functions. Part of the problem here is that the
term "mediator" has not gained currency in the technical community as
far as I can tell; I'm not entirely sure why. Either way, using
"mediator" here, while it might alleviate Dave's concern, would probably
not help many others avoid the same misunderstanding. Would it suffice
to define by example, whichever term is used? Something like, "...pass
through multiple intermediaries (such as mailing lists, filters,
re-senders, etc.)..."? But I'm fine with leaving it alone; I don't think
it causes any real confusion, particularly in an introductory paragraph.
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. In particular, this technology will:
Rather:
The working group will pursue incremental enhancements to DKIM
and/or DKIM use, where possible. It will pursue parallel or
replacement mechanisms only where incremental change is not
feasible.
I agree with Richard here: The reformulation opens the door to a great
deal of nonsense. I fundamentally disagree with making such a change.
On the other points, I believe others have replied sufficiently,
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
