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

Reply via email to