On 20/May/11 15:33, John Levine wrote: >>> of what paths are likely to downcode a message and what paths aren't, >>> so I would prefer not to purport to offer advice about it. >> >>Actually, I kinda prefer to leave it in. It seems to me "assume a >>downgrade will happen unless you're certain it won't, and plan >>accordingly" is good advice without having to know the details of a >>transport path. And the paragraph gives discussion of the how and why. > > So long as it's clear that the advice is illustrative rather than > definitive, I'm not extremely opposed. > > What I want to avoid is the impression that we think we've anticipated > all possible message mutations, so if there's one we didn't mention, > that means we need to add another hack to DKIM to work around it.
For example, MTAs that autoconvert from quoted-printable to 8bit, a rather common circumstance. Wietse reminded us that MTAs with native MIME rewriting capabilities can run filters (including DKIM filtering) either before or after MIME conversion. The former is good for signing while the latter is good for verifying, but what about subsequent dot-forwards? We can hope MTAs will stop autoconverting. Until then, it is useless to say /when/ to invoke a DKIM filter, let alone whether to use MUST, SHOULD, or MAY. Up/down grading depends on conversion, so I concur with John's original statement: I would prefer not to purport to offer advice about it --which is not the same as not mentioning the problem. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
