On Fri, Dec 12, 2008 at 12:40 PM, Markus Wiederkehr <[email protected]> wrote: > On Fri, Dec 12, 2008 at 10:21 AM, Stefano Bagnara <[email protected]> wrote: >> Markus Wiederkehr ha scritto: >>> I have written a new Base64OutputStream for Mime4j. According to my >>> tests it is about twice as fast as the current one (when fed with 1024 >>> byte blocks). >> >> Good! >> >>> It also resolves a tiny issue: the current implementation still >>> appends _two_ CRLFs at the end of the encoded data if the input data >>> size is a multiple of 57 bytes. >> >> The number of ending CRLF in quoted-printable and base64 encoded parts >> always puzzled me. I never found a clear explanation in the RFC about >> what CRLF have to be added and what not. :-( > > As far as I understand the RFC it should not matter, at least not in > the base64 case. RFC 2045 states that "Any characters outside of the > base64 alphabet are to be ignored in base64-encoded data." > > So whether a base64 encoded block is terminated with one or ten CRLFs > should not matter at all because the decoder is supposed to ignore > CRLF entirely. > > Unfortunately I have a use case where things are different: applying > an explicit S/MIME signature. Certain e-mail clients from a certain > company are a bit picky when verifying such signatures. They expect > exactly one empty line between a base64 block and the following > message boundary. Otherwise the signature is considered to be broken > even if it is not (which can be confirmed by using a decent MUA).
IIRC S/MIME requires canonicalisation which is a PITA. bug-free canonicalisation is trick so interop is difficult. are you using the james implementation or are you rolling your own? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
