28.03.2012 19:42, Konstantin Kolinko: > 2012/3/28 Markus Schönhaber <tomcat-...@list-post.mks-mail.de>: >> 28.03.2012 18:31, Filip Hanik (mailing lists): >> >>> Is it my email client, or are some of these emails empty? >> >> It's probably your client. That's the body of the mail you responded to: [...]
> Viewing the source of the message, it is encoded in base64. > > What is a bit strange it is that the base64 chars come in two blocks > of different width, and there is "=" at the end of the last line of > first block. I doubt that the equals sign is allowed in the middle of > data. You're right, I didn't notice this. Seems like the list software simply glues the base64-encoded footer to the existing message. I took a (just superficial) look at RFC 4648 and didn't see that this is explicitly forbidden but from this http://tools.ietf.org/html/rfc4648#section-3.1 | 3.1. Line Feeds in Encoded Data | | MIME [4] is often used as a reference for base 64 encoding. However, | MIME does not define "base 64" per se, but rather a "base 64 Content- | Transfer-Encoding" for use within MIME. As such, MIME enforces a | limit on line length of base 64-encoded data to 76 characters. MIME | inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating | that it is "virtually identical"; however, PEM uses a line length of | 64 characters. The MIME and PEM limits are both due to limits within | SMTP. | | Implementations MUST NOT add line feeds to base-encoded data unless | the specification referring to this document explicitly directs base | encoders to add line feeds after a specific number of characters. it might - IMO - be deduced that the particular input we have here, is not a valid base64-encoded string (the line-length of 72 chars in the footer block seems suspicious too). BTW: If one feeds the complete body of the mail to python's base64.b64decode the footer will be missing while thunderbird decodes that as well. Bottom line: Regardless whether or not it really is violating the spec to glue two base64-encoded strings together and expect the result to be a new, valid, base64-encoded string - in practice, at least, it seems to be a bad idea. -- Regards mks --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
