On Fri, Jan 23, 2009 at 11:00 AM, Stefano Bagnara <apa...@bago.org> wrote: > Robert Burrell Donkin ha scritto: >> On Fri, Jan 23, 2009 at 9:49 AM, Stefano Bagnara <apa...@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.
agreed the easy case is when a parse exception occurs (for example when mail has unescaped unicode in headers) for other cases, some intelligence would be required and so would need to be an optional step > 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. let's take one of the examples given > 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" this would be MIME typed as multipart but the parser would not discover any parts. this could spotted by an optional post processing rule. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
