The whole purpose in creating base64 was to be able to get arbitrary
8-bit data through existing mail gateways without being munged. The
proposed checksum is a check to make sure that this actually happened.
"Normal" mail gateways aren't supposed to change base64 body parts at
all, and neither should they recompute the checksum.
There's no such thing as a "normal" gateway ;-) Indeed, the line between an
ordinary MTA and a gateway is often blurred. My software is a good example --
most of the time it is just an MTA, but in some cases it acts as a gateway
(when connecting to non-RFC822 mail systems, especially).
I prefer to define away the problem. An MTA is by definition something that
has no business messing around inside of a message. A gateway is something
that may have to.
On the other hand, the new message format opens up the possibility
for all sorts of format-conversion gateways, that take a body part
of type "foo" and translate it into a body part of type "bar", on
the assumption that the recipient can read the latter but not the
former. (Danger!) In this case, the gateway should verify the
checksum on the incoming body part and compute a checksum on the converted
body part.
You betcha! Actual format conversions may not be involved, however. For
example, if I'm gatewaying an image over to the MHS world (as in Novell
MHS) many image formats are probably fine, but the encoding definitely needs to
change. It would be nice if changing the encoding would not change the
checksum, but in some cases it may, and indeed in this case there's no way
to verify the checksum from within MHS, so the gateway has to do it and then
if the checksum failed either note it in the message, send a warning back
to the originator, bounce the message, or some combination of the last three.
There seems to be general consensus that checksums on base-64
encoded body parts are a "good thing". I'm curious as to why
checksums on other transport encodings are not?
I would like to see checksums available on anything that *can*
be used to transmit binary data - be it base64, quoted-printable,
or binary.
I certainly don't want to mandate a checksum on 7bit or 8bit, but I think
not allowing the possibility of one is a mistake.
I hate to see quoted-printable made useless for binary data by not having a
checksum, since it would be a win for certain kinds of data. On the other
hand, it seems unreasonable to require the checksum for quoted-printable,
since it might also be used for ordinary text.
My feeling is that the checksum should be optional in all cases -- you may
or may nor put one on messages you create. However, on reception a compliant
entity MUST verify the checksum if it is present. What the receiving entity
then does if the checksum does not match is open to question and I don't
think you can standarize it.
Ned