Please re-read the message that started this. It started by asking for
strategies for dealing with poorly formatted messages where an
intermediate mail reflector added in a signature at the end such as
base64 stuff
--
this message went through the wringer
The text after the -- looks like base64, but when decoded as base64
causes strange control characters to become part of the message.
Yes, the RFC requires skipping non-base64 characters. There's never been
a question about that.
My email pointed out two things:
1) If there's an '=' character, you can *always* stop base64-decoding
the body part right there. This is by definition of base64.
2) As a heuristic algorithm, instead of blithely skipping over
non-base64 & non-whitespace characters, you *could* also stop
base64-decoding at that point. My example was the "--" in the example
message. However, doing so may cause other issues, your mileage may
vary, and it's not a perfect solution.
3) If we were to update base64 (and I'm not suggesting that we should),
it would be worthwhile adding an explicit end of sequence character that
is *always present*. Right now we have the "=" sometimes present, but it
isn't always there.
Tony Hansen
tony(_at_)att(_dot_)com
Florian Weimer wrote:
* Tony Hansen:
If there's a padding "=" at the end of the base64, you can stop
processing right at that point. You *could* also stop processing when
you run into a non-whitespace character that isn't in the base64
alphabet, such as the "-" or ":" in your example. It's not perfect.
Actually, the RFC *requires* skipping non-base64 characters.