From mime4j-dev-return-1788-apmail-james-mime4j-dev-archive=james.apache.org@james.apache.org Thu Dec 15 10:41:50 2011 Return-Path: X-Original-To: apmail-james-mime4j-dev-archive@minotaur.apache.org Delivered-To: apmail-james-mime4j-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7BFC5787F for ; Thu, 15 Dec 2011 10:41:50 +0000 (UTC) Received: (qmail 6694 invoked by uid 500); 15 Dec 2011 10:41:50 -0000 Delivered-To: apmail-james-mime4j-dev-archive@james.apache.org Received: (qmail 6676 invoked by uid 500); 15 Dec 2011 10:41:50 -0000 Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: mime4j-dev@james.apache.org Delivered-To: mailing list mime4j-dev@james.apache.org Received: (qmail 6668 invoked by uid 99); 15 Dec 2011 10:41:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Dec 2011 10:41:50 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lukas.vlcek@gmail.com designates 209.85.213.177 as permitted sender) Received: from [209.85.213.177] (HELO mail-yx0-f177.google.com) (209.85.213.177) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Dec 2011 10:41:43 +0000 Received: by yenl2 with SMTP id l2so1837890yen.22 for ; Thu, 15 Dec 2011 02:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=84bExb40i/4f/KHRbNtQ1VqV9WOW/BhceHotM9dlSyE=; b=aQT5UzcMhehXv1Dp7HsIplonxJxiysbrYfQdufcAFJwBEj+1SmbDLpIgxu4RtplBJM czErNQyxPlE0GSbqjg9z4OsevctcpFPd89Jsj6FCjcPxHXNgE0V5NmMnQIAFQ9fHP6Ha 4272wEVxKLSC/cJgQb+6bCBZ88lUFk7j0kv+Y= Received: by 10.236.180.227 with SMTP id j63mr4712377yhm.18.1323945682117; Thu, 15 Dec 2011 02:41:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.58.42 with HTTP; Thu, 15 Dec 2011 02:41:01 -0800 (PST) In-Reply-To: References: <1323436816.21905.28.camel@ubuntu> <1323697054.3776.4.camel@ubuntu> <1323698968.3776.10.camel@ubuntu> <1323701915.3776.27.camel@ubuntu> <1323703433.3776.28.camel@ubuntu> From: =?UTF-8?B?THVrw6HFoSBWbMSNZWs=?= Date: Thu, 15 Dec 2011 11:41:01 +0100 Message-ID: Subject: Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues To: mime4j-dev@james.apache.org Content-Type: multipart/alternative; boundary=20cf305e240d15a4cb04b41f2001 --20cf305e240d15a4cb04b41f2001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I tried it and it works. Thanks! However, still I am not sure if this fixed everything. See the following commit in my test repo on github (I added a new branch called "workaround") https://github.com/lukas-vlcek/mime4j-test/commit/385c66847bec4393ad67069fb= 367c174f87c5656 As you can see the call to message.getFrom().get(0).getName() returns expected data, but message.getHeader().getField("from").getBody() does not. At least that is how I understand its JavaDoc: http://james.apache.org/mime4j/apidocs/org/apache/james/mime4j/stream/Field= .html#getBody() "Gets the unparsed and possibly encoded (see RFC 2047) field body string." How should I understand the "encoded" in this context? Sorry for being too nitpicking, but Mime4J is quite important for me and migration from 0.6 to 0.7.x turned out to be more challenging then I had hoped for. Regards, Lukas On Mon, Dec 12, 2011 at 4:27 PM, Luk=C3=A1=C5=A1 Vl=C4=8Dek wrote: > Thanks, I will give it a try. > Cheers, > Lukas > > > On Mon, Dec 12, 2011 at 4:23 PM, Oleg Kalnichevski wrot= e: > >> On Mon, 2011-12-12 at 16:05 +0100, Luk=C3=A1=C5=A1 Vl=C4=8Dek wrote: >> > Hi, >> > >> > On Mon, Dec 12, 2011 at 3:58 PM, Oleg Kalnichevski >> wrote: >> > >> > > On Mon, 2011-12-12 at 15:24 +0100, Luk=C3=A1=C5=A1 Vl=C4=8Dek wrote: >> > > > Done, >> > > > >> > > > Please feel free to update the issues >> > > > https://issues.apache.org/jira/browse/MIME4J-210 as I did not want >> to >> > > > invent my own terminology for this bug. >> > > > BTW When can I expect 0.7.2 to be released? Fix of this issue is >> quite >> > > > important for me. >> > > > >> > > > Regards, >> > > > Lukas >> > > > >> > > >> > > In my personal opinion this issue is nowhere near being severe enoug= h >> to >> > > warrant an emergency release. One can fairly easily work the problem >> > > around by using the standard strict field parser or a custom field >> > > parser. >> > > >> > >> > Are there any example how to do that? Which API do I need to use? >> > >> >> --- >> InputStream instream =3D getInputStream("mbox/jbpm-users-01.mbox"); >> try { >> FieldParser mailboxListParser =3D >> MailboxListFieldImpl.PARSER; >> LenientFieldParser fieldParser =3D new LenientFieldParser(); >> fieldParser.setFieldParser(FieldName.FROM, mailboxListParser); >> fieldParser.setFieldParser(FieldName.RESENT_FROM, >> mailboxListParser); >> >> DefaultMessageBuilder messageBuilder =3D new DefaultMessageBuilder(); >> messageBuilder.setFieldParser(fieldParser); >> >> Message message =3D messageBuilder.parseMessage(instream); >> >> assertEquals("jiacc@gillion.com.cn", >> message.getFrom().get(0).getName()); >> >> } finally { >> instream.close(); >> } >> --- >> >> Oleg >> >> > >> > > >> > > I cannot say when 0.7.2 could be expected. It very much depends on t= he >> > > one who volunteers to be a release manager for it. >> > > >> > > Oleg >> > > >> > > > On Mon, Dec 12, 2011 at 3:09 PM, Oleg Kalnichevski < >> olegk@apache.org> >> > > wrote: >> > > > >> > > > > On Mon, 2011-12-12 at 14:44 +0100, Luk=C3=A1=C5=A1 Vl=C4=8Dek wr= ote: >> > > > > > Hi, >> > > > > > >> > > > > > is it ok if I point the JIRA issue to my github repo for >> references? >> > > Or >> > > > > do >> > > > > > you want me to implement use case directly in mime4j? (I can d= o >> > > that, it >> > > > > > will just take longer :-) >> > > > > > >> > > > > >> > > > > The problem is quite trivial to reproduce. So, makes no big >> difference >> > > > > to me. >> > > > > >> > > > > Oleg >> > > > > >> > > > > >> > > > > > Thanks, >> > > > > > Lukas >> > > > > > >> > > > > > On Mon, Dec 12, 2011 at 2:37 PM, Oleg Kalnichevski < >> olegk@apache.org >> > > > >> > > > > wrote: >> > > > > > >> > > > > > > On Mon, 2011-12-12 at 10:46 +0100, Luk=C3=A1=C5=A1 Vl=C4=8De= k wrote: >> > > > > > > > Hi Oleg, >> > > > > > > > >> > > > > > > > Thanks for reply. I would love to open JIRA tickets, but I >> am >> > > still >> > > > > not >> > > > > > > > sure that I use Mime4J API correctly. So I prepared a >> simple test >> > > > > case >> > > > > > > and >> > > > > > > > uploaded to GitHub. >> > > > > > > > It contains some tests to demonstrate mentioned issues: >> > > > > > > > >> > > > > > > > Specifically, the following two tests are about encoding o= f >> > > "From" >> > > > > field. >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > >> > > >> https://github.com/lukas-vlcek/mime4j-test/blob/master/src/test/java/org= /mime4j/test/BasicTest.java#L20 >> > > > > > > > and >> > > > > > > > >> > > > > > > >> > > > > >> > > >> https://github.com/lukas-vlcek/mime4j-test/blob/master/src/test/java/org= /mime4j/test/BasicTest.java#L28 >> > > > > > > > >> > > > > > > > Do you think you can take a look at this and tell me if I >> use >> > > Mime4J >> > > > > API >> > > > > > > > correctly, if so then I will be happy to go and open JIRA >> > > tickets. >> > > > > > > > >> > > > > > > > Best regards, >> > > > > > > > Lukas >> > > > > > > > >> > > > > > > >> > > > > > > I can confirm this issue is caused by a regression in mime4j >> 0.7.x. >> > > > > > > Basically the lenient address parser does not decode encoded >> > > display >> > > > > > > names at all. Please raise a JIRA for this regression. >> > > > > > > >> > > > > > > Oleg >> > > > > > > >> > > > > > > > On Fri, Dec 9, 2011 at 2:20 PM, Oleg Kalnichevski < >> > > olegk@apache.org> >> > > > > > > wrote: >> > > > > > > > >> > > > > > > > > On Wed, 2011-12-07 at 16:50 +0100, Luk=C3=A1=C5=A1 Vl=C4= =8Dek wrote: >> > > > > > > > > > Hi, >> > > > > > > > > > >> > > > > > > > > > First of all, thanks for this library! >> > > > > > > > > > >> > > > > > > > > > I am new to this list, but I have been using mime4j fo= r >> some >> > > > > time now >> > > > > > > > > (but >> > > > > > > > > > I would not call myself an expert on it though). >> > > > > > > > > > >> > > > > > > > > > I switched from 0.6 to 0.7.1 recently and my tests >> started to >> > > > > fail in >> > > > > > > > > some >> > > > > > > > > > cases: >> > > > > > > > > > >> > > > > > > > > > 1) Parsing address: >> > > > > > > > > > >> > > > > > > > > > I have this in the mail header: >> > > > > > > > > > From: "=3D?utf-8?B?amlhY2NAZ2lsbGlvbi5jb20uY24=3D?=3D"= < >> > > > > > > jiacc@gillion.com.cn> >> > > > > > > > > > >> > > > > > > > > > in 0.6 I was able to have it parsed into: " >> > > jiacc@gillion.com.cn< >> > > > > > > > > > jiacc@gillion.com.cn>" >> > > > > > > > > > I am unable to get the same result with 0.7.1 >> > > > > > > > > > >> > > > > > > > > > Another similar example is: >> > > > > > > > > > From: =3D?GBK?B?x67T7rrn?=3D >> > > > > > > > > > >> > > > > > > > > > in 0.6 it was giving me: "=E9=92=B1=E5=AE=87=E8=99=B9 = " >> > > > > > > > > > in 0.7.1 I can not get it. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > 2) CRLF instead of LF >> > > > > > > > > > >> > > > > > > > > > In body texts I am getting CRLF (\r\n) where I was >> getting LF >> > > > > (\n) >> > > > > > > with >> > > > > > > > > 0.6 >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > More generally, is there anything in particular I >> should pay >> > > > > > > attention to >> > > > > > > > > > when switching from 0.6 to 0.7.1 ? >> > > > > > > > > > >> > > > > > > > > > Regards, >> > > > > > > > > > Lukas >> > > > > > > > > >> > > > > > > > > Lukas >> > > > > > > > > >> > > > > > > > > If you are reasonably sure mime4j does not correctly par= se >> > > certain >> > > > > MIME >> > > > > > > > > messages please open raise a JIRA for each case >> separately and >> > > > > provide >> > > > > > > a >> > > > > > > > > sample message in binary format (as an attachment) and = a >> test >> > > case >> > > > > > > > > reproducing the issue. >> > > > > > > > > >> > > > > > > > > Oleg >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > >> > > > > >> > > > > >> > > >> > > >> > > >> >> >> > --20cf305e240d15a4cb04b41f2001--