From mime4j-dev-return-1801-apmail-james-mime4j-dev-archive=james.apache.org@james.apache.org Fri Dec 16 18:53:18 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 91294956F for ; Fri, 16 Dec 2011 18:53:18 +0000 (UTC) Received: (qmail 57536 invoked by uid 500); 16 Dec 2011 18:53:18 -0000 Delivered-To: apmail-james-mime4j-dev-archive@james.apache.org Received: (qmail 57475 invoked by uid 500); 16 Dec 2011 18:53:18 -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 57467 invoked by uid 99); 16 Dec 2011 18:53:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Dec 2011 18:53:18 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of apache@bago.org designates 74.125.82.47 as permitted sender) Received: from [74.125.82.47] (HELO mail-ww0-f47.google.com) (74.125.82.47) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Dec 2011 18:53:08 +0000 Received: by wgbdr10 with SMTP id dr10so6039198wgb.28 for ; Fri, 16 Dec 2011 10:52:48 -0800 (PST) Received: by 10.227.206.66 with SMTP id ft2mr6532695wbb.8.1324061568391; Fri, 16 Dec 2011 10:52:48 -0800 (PST) Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) by mx.google.com with ESMTPS id fw16sm15575933wbb.13.2011.12.16.10.52.48 (version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 10:52:48 -0800 (PST) Received: by wgbdr10 with SMTP id dr10so6039175wgb.28 for ; Fri, 16 Dec 2011 10:52:47 -0800 (PST) Received: by 10.227.208.134 with SMTP id gc6mr6468915wbb.3.1324061567363; Fri, 16 Dec 2011 10:52:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.2.131 with HTTP; Fri, 16 Dec 2011 10:52:26 -0800 (PST) X-Originating-IP: [88.149.210.19] 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> <1323951362.12084.8.camel@ubuntu> From: Stefano Bagnara Date: Fri, 16 Dec 2011 19:52:26 +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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 2011/12/16 Luk=C3=A1=C5=A1 Vl=C4=8Dek : > Hi Stefano, > > is there any workaround? It is already fixed in trunk. So the workaround is using a recent snapshot! Stefano > Regards, > Lukas > > On Fri, Dec 16, 2011 at 5:44 PM, Stefano Bagnara wrote: > >> I guess this is a bug in 0.7.1: >> https://issues.apache.org/jira/browse/MIME4J-208 >> >> Stefano >> >> 2011/12/16 Luk=C3=A1=C5=A1 Vl=C4=8Dek : >> > Hey again, >> > >> > I think I found another difference between 0.6 and 0.7.1 >> > >> > It is about parsing the "Date: Mon, 26 Mar 2007 12:11:10 +0800" header >> field >> > >> > Given the following mbox file source: >> > >> https://github.com/lukas-vlcek/mime4j-test/blob/workaround/src/test/reso= urces/mbox/hibernate-announce-01.mbox >> > >> > I am getting different results. >> > >> > 0.7.1 >> > it is translated into "2007/03/25 16:11:10" (UTC based) >> > >> https://github.com/lukas-vlcek/mime4j-test/blob/workaround/src/test/java= /org/mime4j/test/BasicTest.java#L132 >> > >> > 0.6 >> > it is translated into "2007/03/26 04:11:10" (UTC based) >> > >> https://github.com/lukas-vlcek/mime4j-test/blob/backto06/src/test/java/o= rg/mime4j/test/BasicTest.java#L129 >> > >> > Why I am getting this difference? >> > >> > Regards, >> > Lukas >> > >> > On Fri, Dec 16, 2011 at 1:21 PM, Luk=C3=A1=C5=A1 Vl=C4=8Dek >> wrote: >> > >> >> Hi Stefano, >> >> >> >> I was not aware of the RCF line breaks specification. Thanks! >> >> >> >> I will let you know if I encounter any other issues. Thanks a lot guy= s. >> >> >> >> Regards, >> >> Lukas >> >> >> >> >> >> On Thu, Dec 15, 2011 at 3:32 PM, Stefano Bagnara >> wrote: >> >> >> >>> I guess mime4j 0.6 output was not mime compliant. >> >>> MIME requires newlines in text parts to use CRLF (\r\n) as line >> >>> separators and also says that CR and LF are not allowed in a text pa= rt >> >>> other than in the line separator sequence. >> >>> >> >>> From RFC2046: >> >>> --- >> >>> 4.1.1. =C2=A0Representation of Line Breaks >> >>> >> >>> =C2=A0 The canonical form of any MIME "text" subtype MUST always rep= resent a >> >>> =C2=A0 line break as a CRLF sequence. =C2=A0Similarly, any occurrenc= e of CRLF in >> >>> =C2=A0 MIME "text" MUST represent a line break. =C2=A0Use of CR and = LF outside of >> >>> =C2=A0 line break sequences is also forbidden. >> >>> --- >> >>> >> >>> Most email clients accept LF (\n) line separators, but CRLF is the >> right >> >>> one. >> >>> >> >>> So in 0.7 in fixed this bug. >> >>> >> >>> 0.6 vs 0.7 differences aside, are you experiencing issues with the >> >>> CRLF used by mime4j 0.7 ? >> >>> >> >>> Stefano >> >>> >> >>> 2011/12/15 Luk=C3=A1=C5=A1 Vl=C4=8Dek : >> >>> > Hey again, >> >>> > >> >>> > I did downgraded my code to 0.6 version to see what differences I >> will >> >>> get. >> >>> > >> >>> > Unfortunatelly, I was not able to prove that the below >> >>> > mentioned message.getHeader().getField("from").getBody() did decod= ing >> >>> > however, I was able to show that I am getting different content fr= om >> >>> > TextBody. >> >>> > >> >>> > There are two branches in my github repo now: >> >>> > - workaboud (using mime4j 0.7.2) >> >>> > - backto06 (using mime4j 0.6) >> >>> > >> >>> > I would like to point out the following parts of my test: >> >>> > >> >>> >> https://github.com/lukas-vlcek/mime4j-test/blob/workaround/src/test/java= /org/mime4j/test/BasicTest.java#L112 >> >>> > vs. >> >>> > >> >>> >> https://github.com/lukas-vlcek/mime4j-test/blob/backto06/src/test/java/o= rg/mime4j/test/BasicTest.java#L110 >> >>> > >> >>> > The first is using 0.7.2 and I am getting "\r\n" sequence where us= ing >> >>> 0.6 I >> >>> > am getting only "\n". >> >>> > >> >>> > I am not saying there is a bug in Mime4J but I would like to >> understand >> >>> > what has changed and why I am getting different results using >> different >> >>> > mime4j version. As you can see I did not change anything important= in >> >>> any >> >>> > of util classes between "workaround" and "backto06" branches: >> >>> > >> >>> >> https://github.com/lukas-vlcek/mime4j-test/compare/workaround...backto06 >> >>> > >> >>> > The only important change (except different version of mime4j) is = in >> >>> > ParseUtil class where I had to drop MessageBuilder logic: >> >>> > >> >>> >> https://github.com/lukas-vlcek/mime4j-test/compare/workaround...backto06= #diff-2 >> >>> > >> >>> > Any idea why I am getting "\r\n" chars instead of "\n"? >> >>> > >> >>> > Regards, >> >>> > Lukas >> >>> > >> >>> > On Thu, Dec 15, 2011 at 1:19 PM, Luk=C3=A1=C5=A1 Vl=C4=8Dek >> >>> wrote: >> >>> > >> >>> >> OK, got it. >> >>> >> (Although in 0.6 it was returning decoded content) >> >>> >> >> >>> >> Regards, >> >>> >> Lukas >> >>> >> >> >>> >> >> >>> >> On Thu, Dec 15, 2011 at 1:16 PM, Oleg Kalnichevski < >> olegk@apache.org >> >>> >wrote: >> >>> >> >> >>> >>> On Thu, 2011-12-15 at 11:41 +0100, Luk=C3=A1=C5=A1 Vl=C4=8Dek wr= ote: >> >>> >>> > 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/385c66847bec4393ad6706= 9fb367c174f87c5656 >> >>> >>> > >> >>> >>> > As you can see the call to =C2=A0message.getFrom().get(0).getN= ame() >> >>> returns >> >>> >>> > expected data, but message.getHeader().getField("from").getBod= y() >> >>> does >> >>> >>> not. >> >>> >>> > At least that is how I understand its JavaDoc: >> >>> >>> > >> >>> >>> >> >>> >> http://james.apache.org/mime4j/apidocs/org/apache/james/mime4j/stream/Fi= eld.html#getBody() >> >>> >>> > >> >>> >>> > "Gets the unparsed and possibly encoded (see RFC 2047) field b= ody >> >>> >>> string." >> >>> >>> > >> >>> >>> > How should I understand the "encoded" in this context? >> >>> >>> > >> >>> >>> >> >>> >>> Encoded actually means, well, encoded, as specified in RFC 2047. >> >>> >>> >> >>> >>> Oleg >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >> >> >>> >> >> >> >> >>