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

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
	[email protected]

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.