ietf-822
[Top] [All Lists]

checksums on open issues list

1991-11-08 13:53:50
Checksums can be specified for ANY encoding. The argument has been made that
"text is often modified or corrupted and thus should not have checksums applied
to it". Isn't the detection of such problems the whole point of having
checksums?

It depends on who is reading the mail.  The problem is that text is often
modified in *harmless* ways (harmless for ordinary mail, that is) by mail
gateways that are not under the sender or receiver's control.  In this
situation, effort spent on detection of such problems is wasted and
notification of the user is useless noise.  The checksum detects such
non-problems just as well as it detects real problems.  This is not a
trivial issue because...

... The validation of checksums, if one is
specified that uses the standard checksum algorithm, is mandatory. The action
to be taken if a checksum does not match is left up to the implementation, but
ignoring the checksum failure is not allowed.

What is the proper action for a checksum failure on plain text?  It is, in
most circumstances, *to ignore it*.  The fundamental difficulty is that
one wants to warn the user about problems but not about non-problems, to
use the distinction made above.  Non-problems are far more common than
problems, and there is no simple way to tell the difference.

The surest way to convince users that checksum failures should always be
ignored is to warn them endlessly about failures on messages that can be
confirmed, by other channels, to be semantically intact.

If validation of checksums and action on mismatches are both mandatory,
then I would urge that xxxx contain at least a footnote stating something
on the order of:  "Provision of checksums as a default on plain text is
discouraged, because gateways often make harmless alterations to such text,
and the result is meaningless warnings that desensitize users to meaningful
ones.  Users should be given the option of enabling checksums on plain
text, presumably after verifying that the particular mail paths used do
not suffer from this problem."

Saying "but we ought to fix those gateways" does not help the situation.
It's not going to happen any time soon.

                                         Henry Spencer at U of Toronto Zoology
                                          
henry(_at_)zoo(_dot_)toronto(_dot_)edu   utzoo!henry

<Prev in Thread] Current Thread [Next in Thread>