On Fri, 29 Jun 2018 07:10:58 -0400, David Levine said:
It occurs to me that mhfixmsg doesn't update a Content-MD5 header if it changes the content. It should, though I don't have cycles to fix it now.
By my reading of RFC 1864, you usually shouldn't need to. And if you do need to, you're going to need a bigger can for those worms you just let out of the existing can. To generate the value of the Content-MD5 field, the MD5 algorithm is computed on the canonical form of the MIME entity's object. In particular, this means that the sender applies the MD5 algorithm on the data immediately after conversion to canonical form, before applying any content-transfer-encoding, and that the receiver also applies the MD5 algorithm on the canonical form, after undoing any content-transfer-encoding. For textual data, this means the MD5 algorithm must be computed on data in which the canonical form for newlines applies, that is, in which each newline is represented by a CR-LF pair. The canonical encoding model of MIME is described in Appendix G of [1]. The upshot is that unless you've done a conversion that mangles the canonical form of the object, the MD5 shouldn't be changing. (And the RFC states that if you're not using QP or Base64 as a CTE, you get what you deserve if a gateway screws around with your trailing whitespace). If the Content-MD5 field is present, a recipient user agent may choose to use it to verify that the contents of a MIME entity have not been modified during transport. Message relays and gateways are expressly forbidden to alter their processing based on the presence of the Content-MD5 field. However, a message gateway is allowed to remove the Content-MD5 field if the corresponding MIME entity is translated into a different content-type. So it's probably OK to drop it on the floor if mhfixmsg is acting like a gateway and translating into different content-type. And that gets us to Tom Duff's First Law of Systems Programming: Never test for an error condition you don't know how to handle. If we decide we should be changing the MD5 due to an mhfixmsg translation, shouldn't we be verifying that the *current* one is valid before generating a misleading new value (and possibly papering over an actual data change in transit)? And if we find a bum value, what do we do?
pgp1yPNBMjMCB.pgp
Description: PGP signature
-- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers