I use Free Pascal for programming a small utility for two quite busy Mac OS X mail server (Postfix|CRM114|ANOMY|Cyrus) which prepares and preselects incoming mails (filtering or leraning) for the statistical mail filter CRM114.

Today, I managed to use the fcl base64 classes for decoding respective parts of the piped through e-mails. However, it took me some time to get it to work, and I have still some doubts if the base64 decoding class is stable enough for unattended operation on a busy mail server.

Possibly somebody has more experience with the fcl base64 classes than I have, and hopefully can destroy my doubts.

Base64 encoded parts of e-mails usually include line breaks (LF at Mac OS X Server) every 76 characters. When I write these LF into the TMemoryStream which is passed to TBase64DecodingStream, then the decoder freezes during the read beyond the first line break. If I pass through CRLF or only CR instead of LF then it freezes also - it seems that the decoder is caught into an endless loop. The obvious workaround is not to write the line breaks into the TMemoryStream.

Actually, I check whether the input char belongs to the base64 character set before it is written to the TMemoryStream - also CR/LF is filtered out by this way.

   if ch in ['A'..'Z', 'a'..'z', '0'..'9', '+', '/', '='] then
      base64Stream.WriteByte(Char(ch));

My question here is, whether this catches every malformed base64 code, so that the decoder does not freeze.

Another problem was, that TBase64DecodingStream.EOF() does not indicate properly the end of the decoded stream. Instead, I was forced to use the "try read() except on EStreamError" sequence for the eof indication.

My question here is, whether this works in any case. Again, I am a little bit afraid, that the decoder might be caught into an endless loop.

Many thanks for any helpful comments.

Best regards

Rolf

Sort of the same problem struck me yesterday, too, but with streams which are perfectly valid containing only base64-chars.

// somehow the current implementation of base64 decoding stream is
// broken,  it sometimes raise StreamReadError instead of decoding
// the  values  correctly  (if  you feed $000102...7A7B7C into it,
// it  stops  just  before decoding $7C, or try feeding a constant
// stream  of  $7D  into  it,  it  will  stop after the first byte
// decoded)

Because I need this for XML-RPC server/client stuff, and thus I need the HTTP-capabilities of it anyway, I (temporarily?) switched to Synapse's SynaCode unit. AFAICS it doesn't have any problems with invalid base64 chars, it simply ignores them. Lukas, correct me if I'm wrong.

Currently I can't neither file a bug report nor check the current svn if it's fixed already, because I don't have access to any of *.freepascal.org. :-( Someone's blocking me and I haven't figured out why and who yet.

HTH,

Vinzent.