Hello, Thanks to John for reading the draft proposal.
> Marking content in an MUA is a WKBI*. There is no reason to believe > that users would understand content marking or would make reasonable > decisions based on it. Hmm. The idea was founded on the common reliance of yellow/green bars to indicate website safety. I was not aware that it was considered WKBI; is there a place where I can learn what others have (so conclusively) said on the matter? This takes away one of two reasons to learn through rolling checksums about what is original and what has changed; automated content judgement can still benefit from seeing "that same ol' change" be made. > As a general rule, anything that puts security > policy in the hands of end users doesn't work. Think of all the > browser bad SSL cert warnings you've clicked through. I like the control, but I agree that this is not for everyone. > Also, there are more ways to change content that anyone can describe. > Some of the harder to describe are recoding between 7 and 8 bit and > base64, reducing the size and resolution of images (common on phones) > and reordering MIME parts. This is the sort of thing I was pitching for with this draft. Not everything is so trivial that I would say they need no DKIM or ARC re-signing. * 7/8 bit and base64: I think this can be covered by mapping most body parts to their binary form; and by canonicalising text/* specially by mapping it to Unicode in a UTF-8 representation. This misses out on mapping between ß and ss, but I am willing to accept that language-specifics are changes to content that require DKIM re-signing. * changes to size and resolution constitute change to the content and would require DKIM re-signing. I'd suspect this kind of transformation to be done near the recipient, so explicit trust in the transforming party may be setup explicitly? * reordering of MIME parts in a multipart/* would be recognised by this mechanism, because they are independently signed and listed as sub-parts. MUAs (or MTA spam filters) may judge that they like this, or not. > Finally, it is pretty clear from the ARC work that big mail systems > are more interested in telling recipient systems the identities of the > parties that handled a message than how it changed or whether any of > those parties thought the changes were a good idea. The ARC draft states clearly that it is difficult to pin down the culprit if the content does not validate. This problem does not exist in my proposal. It is clear that ARC addresses large mail providers, but it almost seems like only those are on its mind: parsing ARC is complex, especially because it involves taking charge over message in reputation intermediate systems. When such intermediates check (for spam, say) less accurately than the end systems on which they land, these intermediates will be discredited and effectively pushed off the Internet. I also should add that the cryptographic design of ARC isn't clear to me. I pointed out to the ARC authors that there is a lot of *how* but little or no *why* to underpin what feels to me like a rather complex set of computations, given its intentions. After reading the ARC draft, my crypto-savvy head lacks the usual clear understanding of what is needed to do ARC well, and that worries me. > For another rejected approach see my DKIM conditional signatures, which > let senders authorize intermediaries to modify and resign messages. > > https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ > This proposal is technically different, but maybe you are thinking of the comments on it? Please note that the proposed DKIM-Signed-Content is a helpful extra field, not a mandated extension. Thanks, -Rick _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
