Hi, > Also, among what you're talking about, I think the 7/8/base64 stuff > would be covered by his MIME canonicalization.
Since most MIME content is binary, it would be helpfulto canonicalise individual body parts to their binary/pristine form. My current thinking is that even message/* is binary, and I can think of reasons why message/rfc822 should not be mangled in transit, but I'm not sure if this is realistic. Where MIME content is text/*, I had to learn more about i18n. Unicode was made to solve these riddles, by offering a place to all the characters in the world [but not their renderings]. For characters with more than one code, Unicode has the notion of canonical equivalence. And where characters may be decomposed into sequences, it has a more lenient equivalence notion of compatibility. The former should be no issue for DKIM, the latter may be. Defining equivalence through compatibility works for human texts but may be dangerous for accurate content like program fragments and URIs, except that the common limitation of these uses to ASCII solves these dangers. The stringprep profiles, including SASLprep which looks very email-suitable, would be able to handle all this. Software support already exists, of course. Finally, the nested nature of MIME content allows the recognition of failures. All that needs to be done is add a DKIM-Signature to the body parts, and have a mechanism for describing their compositions in a change-detectable manner (and sign for that mechanism too). > Although I've seen web proxies or clients which resize photos, I don't > think I've ever seen an MTA do it... which doesn't mean they couldn't, > but I'm not sure it's a use case we have to try and handle. Anything of this kind would know that delivery is to a particular class of MUA, so it would be near the recipient, where trust has a different organisation. -Rick _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
