On Friday, September 29, 2017 07:53:50 AM Rick van Rein wrote: > > 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.
Making DKIM signing MIME aware was specifically rejected during DKIM development due to implementation complexity. It didn't magically get easier in the mean time. For the implementation I help maintain, dkimpy, large portions of the existing code would have to be thrown out and re-written (integrating ARC into the code base was relatively minor compared to this). If you've made it MIME aware, I think you've changed it enough it's no longer DKIM and you should call it something else (and I'm pretty sure I'd never implement it). Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
