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. > Can you file a JIRA with your patch and description of the issue? +1 - robert --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
