Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <1323698968.3776.10.camel@ubuntu>
Subject: Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
From: Oleg Kalnichevski <olegk@apache.org>
To: mime4j-dev@james.apache.org
Date: Mon, 12 Dec 2011 15:09:28 +0100
In-Reply-To: 
 <CAO9cvUaOVYvL9bfE7Y_GLsmfrL4=zJ=uc_KQGHiUfBCJXp10Hw@mail.gmail.com>
References: 
	<CAO9cvUYdJjXRUtco1L6fMCCyrYByxx6MZu=+UhFeCbdV+g4Bxg@mail.gmail.com>
	 <1323436816.21905.28.camel@ubuntu>
	 <CAO9cvUbtNLgHO-1KN7jjfMs2dEXTEN1KqNiFjcgzGOJx1KwmoA@mail.gmail.com>
	 <1323697054.3776.4.camel@ubuntu>
	 <CAO9cvUaOVYvL9bfE7Y_GLsmfrL4=zJ=uc_KQGHiUfBCJXp10Hw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0

On Mon, 2011-12-12 at 14:44 +0100, Lukáš Vlček wrote:
> 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 do 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áš Vlček 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 of "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áš Vlček wrote:
> > > > > Hi,
> > > > >
> > > > > First of all, thanks for this library!
> > > > >
> > > > > I am new to this list, but I have been using mime4j for 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: "=?utf-8?B?amlhY2NAZ2lsbGlvbi5jb20uY24=?=" <
> > 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: =?GBK?B?x67T7rrn?= <yhqian99@163.com>
> > > > >
> > > > > in 0.6 it was giving me: "钱宇虹 <yhqian99@163.com>"
> > > > > 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 parse 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
> > > >
> > > >
> > > >
> >
> >
> >