jkbzh
commented
1 year ago Are you sure about this? It may be you're looking at a badly-formed message.
Check RFC2045. For MIME base-64 encoding, lines must be at most 76 characters long. It's up to the mail client to do that split.
I'd advice holding off this work and looking at the RFC and evaluating the UA that created the message you're talking about.
In particular this section:
(Soft Line Breaks) The Quoted-Printable encoding REQUIRES that encoded lines be no more than 76 characters long. If longer lines are to be encoded with the Quoted-Printable encoding, "soft" line breaks must be used. An equal sign as the last character on a encoded line indicates such a non-significant ("soft") line break in the encoded text.
As well as this note in base64.c
- CHANGES by Daniel Stenberg. May 11, 1998: - Encoded strings that ended with more than one = caused the decode * function to generate 3 extra zero bytes at the end of the output. /
And finally try this base64 decoder to know your base64 is valid:
What I would be interested is in having a sample mail that has this issue so I can check out the issue you're describing.
vandys
base64 gives 3 octets for 4 characters of input. There is no requirement that mail input needs to be in units of four, and in fact I have inputs where there are two residual in one line, and the final two on the next. hypermail invokes base64Decode per line, and this results in a corrupted decode.
I'm going to look at a struct to hold the decode state, so the decoder can be called with this as an argument and thus have stateful continuity from line to line.