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 09:49:06 GMT
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.

Can you file a JIRA with your patch and description of the issue?

Thank you,
Stefano

> Bye!
> 
> Valentina
> 
> Example 1
> ==========
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> boundary=----_Abderaware_NextPart_4258668384642082
> Date: Fri 23 May 2005 12:49:21 +0200
> This is a multi-part message in MIME format.
> ------_Abderaware_NextPart_4258668384642082
> Content-Type: type/subtype;
> name="filename.txt"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename="filename.txt"
> 
> Example 2
> ==========
> MIME-Version: 1.0 Content-Type: multipart/mixed;
> boundary=----_Abderaware_NextPart_4258668384642082
> Date: gio 22 gen 2009 00:13:49 +0200 This is a multi-part message in
> MIME format.
> ------_Abderaware_NextPart_4258668384642082
> Content-Type: type/subtype; name="RefRad_90801819.txt"
> Content-Transfer-Encoding: base64 Content-Disposition: attachment;
> filename="RefRad_90801819.txt"
> 
> Example 3
> ==========
> MIME-Version: 1.0
> Content-type: multipart/mixed;
> boundary=----_Abderaware_NextPart_2323466342530810
> Date: Thu 22 Jan 2009 08:17:22 +01
> 
> This is a multi-part message in MIME format.
> 
> ------_Abderaware_NextPart_2323466342530810
> Content-type: application/cda; charset: us-ascii;
> Content-Disposition:  form-data; name="document.txt";
> filename="document.txt"
> Content-Transfer-Encoding:  base64
> 
> 


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


Mime
View raw message