Re: [nmh-workers] mhshow: invalid BASE64 encoding in --

[David Levine]

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