[Top] [All Lists]

Re: C-T-E: base64 and the real world.. what should an MUA do?

2008-05-08 13:39:58

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

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.

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