[Top] [All Lists]

Re: Trivial checksums for BASE-64

1991-11-14 12:11:02
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.
  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.

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