Hi,
the malformed MIME messages aren't created by a mainstream application.
Unfotunately we need to be extremely tolerant and try to decode as many
messages as possibile, despite their adherence to the standard. If I may
put my two cents in, I still think that if you want to be tolerant, you
should decode a message if you have enough information to do it correctly.
Anyway, Stefano suggestion is quite valuable, we will consider it.
Thanks,
Valentina
Stefano Bagnara wrote:
Valentina Medici ha scritto:
Hi all!
I have a MIME base64 decoded message in which the header
Content-Transfer-Encoding is almost correct except for the fact that the
new line after the header is missing. In the current implementation of
mime4j (0.5) that file couldn't be decoded.
In the proposed patch, if the Content-Transfer-Encoding is not
recognized, it will be guessed if possible.
So, if the header is like the one I receive,i.e.:
Content-Transfer-Encoding: base64 Content-Disposition: attachment;
How much of this messages are you receiving ?
What kind of application creates this falformed message? If it is a
mainstream application then it probably worth including a workaround in
mime4j, but it if is an in-house application then we probably cannot
include it in the main library.
In this last case maybe you should fix this with a custom
inputstreamfilter that simply intercept that sequence adding the CRLF in
the appropriate place.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
--
Valentina Medici
CUP 2000 S.p.A.
Via del Borgo di S. Pietro, 90/c - 40126 Bologna
tel. +39 051 4208411 - Fax +39 051 4208511
e-mail: valentina.med...@cup2000.it
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
