Valdis wrote:
My reading of RFC2045 says a conforming base64 decoder is allowed to toss
out
the blanks and the '!' char and decode the rest.
Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data.
Note the "in base64-encoded data". The characters in the footer are after the
end of the base64-encoded data, per the use of "end" here:
Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a body.
There's this other related gem a few paragraphs earlier:
The encoded output stream must be represented in lines of no more
than 76 characters each. All line breaks or other characters not
found in Table 1 must be ignored by decoding software. In base64
data,
The non-base64 characters in the message body are after the end of the
base64-encoded data. They're not "in base64 data".
My interpretation RFC 2045 is that the message is invalid because the C-T-E
doesn't specify the entire transformation the body was subjected to:
This single Content-Transfer-Encoding token actually provides two
pieces of information. It specifies what sort of encoding
transformation the body was subjected to and hence what decoding
operation must be used to restore it to its original form, and it
specifies what the domain of the result is.
If we do want to handle this input, I don't think that we should make the
base64 decoder more lenient. Instead, I think that mhfixmsg should transform
it such that the rest of nmh could handle it.
# Oh, and what happens if a conforming implementation takes that
# 'you are receiving this message' whoopsie and decodes it?
If it detects an error while decoding it, then it should display a message and
stop. That's what happens now.
# This. Which is probably *not* what you meant by 'see all of the content'.
I think that it is what I meant. But I also suspect that I'm missing your
point.
David
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers