On 10/8/2021 12:12 PM, John Levine wrote:
It appears that Dave Crocker<[email protected]> said:
The purpose of the Author field is to retain some information that
presumably won't get modified. ...
The problem for me is that this is just another entry in the list of
things that are supposed to help peek back and see what the original
message said. Other things that immediately come to mind:
- wrap messages, like a single message digest
- DKIM unmunging hints like Ale has proposed
All of these share the characteristic that to be useful, they require
MUAs to do things they do not do now, so I don't see much reason to
put a lot of effort into any of them unless we see interest from
Language like 'wrap messages' typically means making the content
inaccessible except to a recipient that supports the wrapping
mechanism. Saying 'message digest' typically means a hash, which is in
addition to clear content. So I'm not sure what you mean. Assuming you
just mean a hash, I don't see its relevance here.
Changing DKIM is an infrastructure change, since it involves components
in the handling stream, rather than just the MUA.
The Author field is a pure, incremental value-add. It only requires MUA
support, and it imposes no burden to a recipient MUA that does not
support it.
These are very, very different barriers to adoption.
So while, of course, Author requires new code, the nature and amount is
quite different from any requiring infrastructure change, and especially
different from anything hiding content unless the recipient supports it.
d/
--
Dave Crocker
[email protected]
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email protected]
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc