Also, if they define a binary SMTP, they should put checksums
in at that level and it won't be NECESSARY at our level, because data
integrity will be assumed.
Well...
With the understanding this is one of the reasons the "ietf-smtp
group" (at least those who are doing the writing) isn't contemplating
binary, think about this for a moment.
For better or worse, an RFC822 message contains contains both headers
(inner envelope) and message body. It is hard for an MTA to tell the
boundary, and it shouldn't do so. But, whatever we think of various
line wrapping activities, RFC822 explicitly permits it in headers, and
there are a lot of MTAs out there that take advantage of that, so say
nothing of the impact of stuffing in trace fields.
So, as I see it, there are two ways to handle binary transport.
(1) Checksum or some other integrity check that applies to the message
body (after the ASCII-ish headers) only. If one does that, all of the
problems with doing this in RFC-XXXX reappear, whether one put that
checksum in the headers or in the transport envelope.
(2) Transport negotiation of a completely different body model in
which, e.g., the rules for separation of headers and body are different
from those of 822, and trace fields are handled in a different way.
But, by bypassing 822, this model bypasses RFC-XXXX entirely.
Conclusion: Let's not spend a lot of energy on RFC-XXXX "binary". The
vaguest of placeholders is plenty.
--john