james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [mime4j] [PATCH] - Proposed patch to decode base64 messages with malformed Content-Transfer-Encoding headers
Date Fri, 23 Jan 2009 11:00:58 GMT
Robert Burrell Donkin ha scritto:
> On Fri, Jan 23, 2009 at 9:49 AM, Stefano Bagnara <apache@bago.org> wrote:
>> Valentina Medici ha scritto:
>>> Hi Stefano and hi all!
>>> Stefano Bagnara wrote:
>>>> things wrong and there is nothing to do to fix it. But IMHO, before
>>>> implementing any "workaround" to compensate for other developers errors
>>>> we have to understand what application is creating similar messages
>>>> and why.
>>> I must admit that I personally like your're optimistic point of view for
>>> a better world, anyway in real (production) world it's not always
>>> possible to do as you suggest.
>>>> I'm still interested in understanding the source of that kind of message.
>>>> Maybe the full headers can say something about what code produced it and
>>>> what IP produced it. Can you post them?
>>> Our application is a web application that receives xml messages
>>> containing a MIME base64 encoded element. There are several external
>>> producers (and so several problems in decoding ;)). As already stated we
>>> must be able to accept (that is, to decode) as many messages as possible.
>>> Having said this, I don't think our headers can be of any use to you,
>>> anyway some example follows.
>> Instead they are usefull! This show that the "problematic" application
>> is "Abderaware" (it is used in the multipart boundary).
>> http://www.google.com/search?q=Abderaware
>> Abderaware produced in past a .NET component for dealing with MIME.
>> Unfortunately http://www.abderaware.com/ doesn't exists anymore (no
>> wonder ;-) ) and now it is a parked domain. From few more searches it
>> seems that the component was around in 2002.
>> It seems the library was named Mail.NET and one of its components is
>> MIME.net. I made a few searches but I can't find up-to-date info or a
>> new home/name for the library.
>> I also find interesting the "Content-Type: type/subtype" stuff.. It
>> really smell.
>> This issue is in the same group as:
>> https://issues.apache.org/jira/browse/MIME4J-58
>> We should find a way to add similar workarounds to mime4j "optionally"
>> because most of them degrades performace.
> +1
> one design option would be to have an extension parser that handles
> many more malformed messages than the fast one. users would be able to
> start parsing optimistically assuming a conformant message with the
> quick parser. if this parse fails then the message could be re-parsed
> with a more tolerant parser.

The problem may be understanding that the parsing has failed.

E.g: if you miss a content-transfer-encoding header mime4j probably
parse it anyway without errors, but the result won't be decoded as you
would expect it it understand the malformation.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message