james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [jira] Commented: (MIME4J-118) MIME stream parser handles non-ASCII fields incorrectly
Date Wed, 25 Feb 2009 08:59:54 GMT
Robert Burrell Donkin ha scritto:
> [...]
> IIRC in a multipart document, the mime headers must be encoded in
> ASCII. so, the first level headers can all be access through byte
> offsets. a part may contain a transfer encoded document. there are a
> couple of distinct cases which are interesting: when the document is
> an embedded message or an embedded multipart document. when this is
> encoded in Base64 then a bytewise offset is not available in the
> original stream but is from the decoded stream. so, the bytewise
> offset in the decoding stream can be used. this is a rare use case and
> though the approach would be slow in this case, it would be a rare
> one.

FYI
http://issues.apache.org/jira/browse/MIME4J-114?focusedCommentId=12671463#action_12671463
-----
the content-transfer-encoding for a multipart message SHOULD always be
7bit, 8bit or binary to avoid nested encoding/decoding operations.

Javamail from 1.4 ignores a content-transfer-encoding quoted-printable
or base64 for a multipart message by default while previous javamail
versions parsed correctly nested encoding. Javamail 1.4 provides a flag
to enable the nested encodings (for backward compatibility):
mail.mime.ignoremultipartencoding
-----

Stefano

Mime
View raw message