You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by Lukáš Vlček <lu...@gmail.com> on 2011/12/07 16:50:06 UTC
Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
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=?=" <ji...@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?= <yh...@163.com>
in 0.6 it was giving me: "钱宇虹 <yh...@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
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
Thanks,
this helped me.
Regards,
Lukas
On Sun, Dec 18, 2011 at 1:22 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sun, 2011-12-18 at 12:57 +0100, Stefano Bagnara wrote:
> > 2011/12/18 Lukáš Vlček <lu...@gmail.com>:
> > > Hi again,
> > >
> > > there is another difference between 0.6 and 0.7.1
> > >
> > > It happens when I need to parse message with weird charset 'x-gbk'.
> > >
> > > I added a new test case into my github repo for both 0.6 and 0.7.1
> versions.
> > > Basically the problem happens when I try to get Reader from the
> TextBody:
> > >
> > > Message message = getMessage(....);
> > > TextBody body = (TextBody) message.getBody();
> > > body.getReader(); // here the exception is fired
> > >
> > > It worked fine in 0.6 but it yields UnsupportedEncodingException in
> 0.7.1
> > > which is quite unfortunate because I do not see way how to extract body
> > > content from it in this case (as I need to get the Reader first).
> > >
> > > Here are examples:
> > > 0.6
> > >
> https://github.com/lukas-vlcek/mime4j-test/blob/backto06/src/test/java/org/mime4j/test/BasicTest.java#L134
> > > 0.7.1
> > >
> https://github.com/lukas-vlcek/mime4j-test/blob/workaround/src/test/java/org/mime4j/test/BasicTest.java#L134
> > >
> > > Any idea hot to deal with this situation?
> > >
> > > Note, I understand that 'x-gbk' is unknown charset for JVM but even in
> such
> > > case I was able to extract the body content by forcing 'gbk' charset
> > > instead into my utility classes in 0.6, however, with 0.7.1 I am
> unable to
> > > do it because the very basic body.getReader call fails... is there any
> > > workaround how to get the body Reader and not to get the exception?
> >
> > Please open a JIRA issue, attach your test case and the stack trace of
> > the exception you get.
> > I guess we can classify this as a bug because we want to give users a
> > way to deal with malformed stuff, so also unrecognized charsets.
> >
> > I don't know if we already have an existing workaround but the JIRA
> > issue will anyway help keeping track of the issue for future users.
> >
> > Stefano
>
>
> There's no need to raise a JIRA, because basically there is no issue.
> #getReader is merely a convenience method. One can always use
> #getInputStream() to get raw data stream and apply whatever charset
> encoding.
>
> Lukáš, what is wrong with that?
>
> ---
> Message message =
> ParserUtil.getMessage(getInputStream("mbox/jboss-as7-dev-01.mbox"));
>
> assertTrue(message.getBody() instanceof TextBody);
> TextBody body = (TextBody) message.getBody();
>
> String charset = message.getCharset();
> if (charset.equalsIgnoreCase("x-gbk")) {
> charset = "gbk";
> }
> Reader reader = new InputStreamReader(body.getInputStream(), charset);
> ---
>
>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2011-12-18 at 12:57 +0100, Stefano Bagnara wrote:
> 2011/12/18 Lukáš Vlček <lu...@gmail.com>:
> > Hi again,
> >
> > there is another difference between 0.6 and 0.7.1
> >
> > It happens when I need to parse message with weird charset 'x-gbk'.
> >
> > I added a new test case into my github repo for both 0.6 and 0.7.1 versions.
> > Basically the problem happens when I try to get Reader from the TextBody:
> >
> > Message message = getMessage(....);
> > TextBody body = (TextBody) message.getBody();
> > body.getReader(); // here the exception is fired
> >
> > It worked fine in 0.6 but it yields UnsupportedEncodingException in 0.7.1
> > which is quite unfortunate because I do not see way how to extract body
> > content from it in this case (as I need to get the Reader first).
> >
> > Here are examples:
> > 0.6
> > https://github.com/lukas-vlcek/mime4j-test/blob/backto06/src/test/java/org/mime4j/test/BasicTest.java#L134
> > 0.7.1
> > https://github.com/lukas-vlcek/mime4j-test/blob/workaround/src/test/java/org/mime4j/test/BasicTest.java#L134
> >
> > Any idea hot to deal with this situation?
> >
> > Note, I understand that 'x-gbk' is unknown charset for JVM but even in such
> > case I was able to extract the body content by forcing 'gbk' charset
> > instead into my utility classes in 0.6, however, with 0.7.1 I am unable to
> > do it because the very basic body.getReader call fails... is there any
> > workaround how to get the body Reader and not to get the exception?
>
> Please open a JIRA issue, attach your test case and the stack trace of
> the exception you get.
> I guess we can classify this as a bug because we want to give users a
> way to deal with malformed stuff, so also unrecognized charsets.
>
> I don't know if we already have an existing workaround but the JIRA
> issue will anyway help keeping track of the issue for future users.
>
> Stefano
There's no need to raise a JIRA, because basically there is no issue.
#getReader is merely a convenience method. One can always use
#getInputStream() to get raw data stream and apply whatever charset
encoding.
Lukáš, what is wrong with that?
---
Message message =
ParserUtil.getMessage(getInputStream("mbox/jboss-as7-dev-01.mbox"));
assertTrue(message.getBody() instanceof TextBody);
TextBody body = (TextBody) message.getBody();
String charset = message.getCharset();
if (charset.equalsIgnoreCase("x-gbk")) {
charset = "gbk";
}
Reader reader = new InputStreamReader(body.getInputStream(), charset);
---
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/18 Lukáš Vlček <lu...@gmail.com>:
> Hi again,
>
> there is another difference between 0.6 and 0.7.1
>
> It happens when I need to parse message with weird charset 'x-gbk'.
>
> I added a new test case into my github repo for both 0.6 and 0.7.1 versions.
> Basically the problem happens when I try to get Reader from the TextBody:
>
> Message message = getMessage(....);
> TextBody body = (TextBody) message.getBody();
> body.getReader(); // here the exception is fired
>
> It worked fine in 0.6 but it yields UnsupportedEncodingException in 0.7.1
> which is quite unfortunate because I do not see way how to extract body
> content from it in this case (as I need to get the Reader first).
>
> Here are examples:
> 0.6
> https://github.com/lukas-vlcek/mime4j-test/blob/backto06/src/test/java/org/mime4j/test/BasicTest.java#L134
> 0.7.1
> https://github.com/lukas-vlcek/mime4j-test/blob/workaround/src/test/java/org/mime4j/test/BasicTest.java#L134
>
> Any idea hot to deal with this situation?
>
> Note, I understand that 'x-gbk' is unknown charset for JVM but even in such
> case I was able to extract the body content by forcing 'gbk' charset
> instead into my utility classes in 0.6, however, with 0.7.1 I am unable to
> do it because the very basic body.getReader call fails... is there any
> workaround how to get the body Reader and not to get the exception?
Please open a JIRA issue, attach your test case and the stack trace of
the exception you get.
I guess we can classify this as a bug because we want to give users a
way to deal with malformed stuff, so also unrecognized charsets.
I don't know if we already have an existing workaround but the JIRA
issue will anyway help keeping track of the issue for future users.
Stefano
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
Hi again,
there is another difference between 0.6 and 0.7.1
It happens when I need to parse message with weird charset 'x-gbk'.
I added a new test case into my github repo for both 0.6 and 0.7.1 versions.
Basically the problem happens when I try to get Reader from the TextBody:
Message message = getMessage(....);
TextBody body = (TextBody) message.getBody();
body.getReader(); // here the exception is fired
It worked fine in 0.6 but it yields UnsupportedEncodingException in 0.7.1
which is quite unfortunate because I do not see way how to extract body
content from it in this case (as I need to get the Reader first).
Here are examples:
0.6
https://github.com/lukas-vlcek/mime4j-test/blob/backto06/src/test/java/org/mime4j/test/BasicTest.java#L134
0.7.1
https://github.com/lukas-vlcek/mime4j-test/blob/workaround/src/test/java/org/mime4j/test/BasicTest.java#L134
Any idea hot to deal with this situation?
Note, I understand that 'x-gbk' is unknown charset for JVM but even in such
case I was able to extract the body content by forcing 'gbk' charset
instead into my utility classes in 0.6, however, with 0.7.1 I am unable to
do it because the very basic body.getReader call fails... is there any
workaround how to get the body Reader and not to get the exception?
Regards,
Lukas
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
Yea, that is what I have to do now. Copy&paste implementation from trunk
into custom DateFieldParser.
On Sat, Dec 17, 2011 at 1:55 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2011-12-16 at 19:52 +0100, Stefano Bagnara wrote:
> > 2011/12/16 Lukáš Vlček <lu...@gmail.com>:
> > > Hi Stefano,
> > >
> > > is there any workaround?
> >
> > It is already fixed in trunk. So the workaround is using a recent
> snapshot!
> >
>
> Lukáš
>
> Alternatively you can always use a custom field parser as well
>
> Oleg
>
> > Stefano
> >
> > > Regards,
> > > Lukas
> > >
> > > On Fri, Dec 16, 2011 at 5:44 PM, Stefano Bagnara <ap...@bago.org>
> wrote:
> > >
> > >> I guess this is a bug in 0.7.1:
> > >> https://issues.apache.org/jira/browse/MIME4J-208
> > >>
> > >> Stefano
> > >>
> > >> 2011/12/16 Lukáš Vlček <lu...@gmail.com>:
> > >> > 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/resources/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/org/mime4j/test/BasicTest.java#L129
> > >> >
> > >> > Why I am getting this difference?
> > >> >
> > >> > Regards,
> > >> > Lukas
> > >> >
> > >> > On Fri, Dec 16, 2011 at 1:21 PM, Lukáš Vlček <lukas.vlcek@gmail.com
> >
> > >> 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
> guys.
> > >> >>
> > >> >> Regards,
> > >> >> Lukas
> > >> >>
> > >> >>
> > >> >> On Thu, Dec 15, 2011 at 3:32 PM, Stefano Bagnara <ap...@bago.org>
> > >> 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
> part
> > >> >>> other than in the line separator sequence.
> > >> >>>
> > >> >>> From RFC2046:
> > >> >>> ---
> > >> >>> 4.1.1. Representation of Line Breaks
> > >> >>>
> > >> >>> The canonical form of any MIME "text" subtype MUST always
> represent a
> > >> >>> line break as a CRLF sequence. Similarly, any occurrence of
> CRLF in
> > >> >>> MIME "text" MUST represent a line break. Use of CR and LF
> outside of
> > >> >>> 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áš Vlček <lu...@gmail.com>:
> > >> >>> > 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
> decoding
> > >> >>> > however, I was able to show that I am getting different content
> from
> > >> >>> > 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/org/mime4j/test/BasicTest.java#L110
> > >> >>> >
> > >> >>> > The first is using 0.7.2 and I am getting "\r\n" sequence where
> using
> > >> >>> 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áš Vlček <
> lukas.vlcek@gmail.com>
> > >> >>> 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áš Vlček wrote:
> > >> >>> >>> > 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/385c66847bec4393ad67069fb367c174f87c5656
> > >> >>> >>> >
> > >> >>> >>> > 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?
> > >> >>> >>> >
> > >> >>> >>>
> > >> >>> >>> Encoded actually means, well, encoded, as specified in RFC
> 2047.
> > >> >>> >>>
> > >> >>> >>> Oleg
> > >> >>> >>>
> > >> >>> >>>
> > >> >>> >>>
> > >> >>> >>
> > >> >>>
> > >> >>
> > >> >>
> > >>
>
>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2011-12-16 at 19:52 +0100, Stefano Bagnara wrote:
> 2011/12/16 Lukáš Vlček <lu...@gmail.com>:
> > Hi Stefano,
> >
> > is there any workaround?
>
> It is already fixed in trunk. So the workaround is using a recent snapshot!
>
Lukáš
Alternatively you can always use a custom field parser as well
Oleg
> Stefano
>
> > Regards,
> > Lukas
> >
> > On Fri, Dec 16, 2011 at 5:44 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> >> I guess this is a bug in 0.7.1:
> >> https://issues.apache.org/jira/browse/MIME4J-208
> >>
> >> Stefano
> >>
> >> 2011/12/16 Lukáš Vlček <lu...@gmail.com>:
> >> > 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/resources/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/org/mime4j/test/BasicTest.java#L129
> >> >
> >> > Why I am getting this difference?
> >> >
> >> > Regards,
> >> > Lukas
> >> >
> >> > On Fri, Dec 16, 2011 at 1:21 PM, Lukáš Vlček <lu...@gmail.com>
> >> 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 guys.
> >> >>
> >> >> Regards,
> >> >> Lukas
> >> >>
> >> >>
> >> >> On Thu, Dec 15, 2011 at 3:32 PM, Stefano Bagnara <ap...@bago.org>
> >> 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 part
> >> >>> other than in the line separator sequence.
> >> >>>
> >> >>> From RFC2046:
> >> >>> ---
> >> >>> 4.1.1. Representation of Line Breaks
> >> >>>
> >> >>> The canonical form of any MIME "text" subtype MUST always represent a
> >> >>> line break as a CRLF sequence. Similarly, any occurrence of CRLF in
> >> >>> MIME "text" MUST represent a line break. Use of CR and LF outside of
> >> >>> 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áš Vlček <lu...@gmail.com>:
> >> >>> > 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 decoding
> >> >>> > however, I was able to show that I am getting different content from
> >> >>> > 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/org/mime4j/test/BasicTest.java#L110
> >> >>> >
> >> >>> > The first is using 0.7.2 and I am getting "\r\n" sequence where using
> >> >>> 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áš Vlček <lu...@gmail.com>
> >> >>> 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áš Vlček wrote:
> >> >>> >>> > 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/385c66847bec4393ad67069fb367c174f87c5656
> >> >>> >>> >
> >> >>> >>> > 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?
> >> >>> >>> >
> >> >>> >>>
> >> >>> >>> Encoded actually means, well, encoded, as specified in RFC 2047.
> >> >>> >>>
> >> >>> >>> Oleg
> >> >>> >>>
> >> >>> >>>
> >> >>> >>>
> >> >>> >>
> >> >>>
> >> >>
> >> >>
> >>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/16 Lukáš Vlček <lu...@gmail.com>:
> 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 <ap...@bago.org> wrote:
>
>> I guess this is a bug in 0.7.1:
>> https://issues.apache.org/jira/browse/MIME4J-208
>>
>> Stefano
>>
>> 2011/12/16 Lukáš Vlček <lu...@gmail.com>:
>> > 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/resources/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/org/mime4j/test/BasicTest.java#L129
>> >
>> > Why I am getting this difference?
>> >
>> > Regards,
>> > Lukas
>> >
>> > On Fri, Dec 16, 2011 at 1:21 PM, Lukáš Vlček <lu...@gmail.com>
>> 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 guys.
>> >>
>> >> Regards,
>> >> Lukas
>> >>
>> >>
>> >> On Thu, Dec 15, 2011 at 3:32 PM, Stefano Bagnara <ap...@bago.org>
>> 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 part
>> >>> other than in the line separator sequence.
>> >>>
>> >>> From RFC2046:
>> >>> ---
>> >>> 4.1.1. Representation of Line Breaks
>> >>>
>> >>> The canonical form of any MIME "text" subtype MUST always represent a
>> >>> line break as a CRLF sequence. Similarly, any occurrence of CRLF in
>> >>> MIME "text" MUST represent a line break. Use of CR and LF outside of
>> >>> 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áš Vlček <lu...@gmail.com>:
>> >>> > 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 decoding
>> >>> > however, I was able to show that I am getting different content from
>> >>> > 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/org/mime4j/test/BasicTest.java#L110
>> >>> >
>> >>> > The first is using 0.7.2 and I am getting "\r\n" sequence where using
>> >>> 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áš Vlček <lu...@gmail.com>
>> >>> 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áš Vlček wrote:
>> >>> >>> > 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/385c66847bec4393ad67069fb367c174f87c5656
>> >>> >>> >
>> >>> >>> > 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?
>> >>> >>> >
>> >>> >>>
>> >>> >>> Encoded actually means, well, encoded, as specified in RFC 2047.
>> >>> >>>
>> >>> >>> Oleg
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>>
>> >>
>> >>
>>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
Hi Stefano,
is there any workaround?
Regards,
Lukas
On Fri, Dec 16, 2011 at 5:44 PM, Stefano Bagnara <ap...@bago.org> wrote:
> I guess this is a bug in 0.7.1:
> https://issues.apache.org/jira/browse/MIME4J-208
>
> Stefano
>
> 2011/12/16 Lukáš Vlček <lu...@gmail.com>:
> > 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/resources/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/org/mime4j/test/BasicTest.java#L129
> >
> > Why I am getting this difference?
> >
> > Regards,
> > Lukas
> >
> > On Fri, Dec 16, 2011 at 1:21 PM, Lukáš Vlček <lu...@gmail.com>
> 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 guys.
> >>
> >> Regards,
> >> Lukas
> >>
> >>
> >> On Thu, Dec 15, 2011 at 3:32 PM, Stefano Bagnara <ap...@bago.org>
> 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 part
> >>> other than in the line separator sequence.
> >>>
> >>> From RFC2046:
> >>> ---
> >>> 4.1.1. Representation of Line Breaks
> >>>
> >>> The canonical form of any MIME "text" subtype MUST always represent a
> >>> line break as a CRLF sequence. Similarly, any occurrence of CRLF in
> >>> MIME "text" MUST represent a line break. Use of CR and LF outside of
> >>> 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áš Vlček <lu...@gmail.com>:
> >>> > 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 decoding
> >>> > however, I was able to show that I am getting different content from
> >>> > 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/org/mime4j/test/BasicTest.java#L110
> >>> >
> >>> > The first is using 0.7.2 and I am getting "\r\n" sequence where using
> >>> 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áš Vlček <lu...@gmail.com>
> >>> 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áš Vlček wrote:
> >>> >>> > 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/385c66847bec4393ad67069fb367c174f87c5656
> >>> >>> >
> >>> >>> > 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?
> >>> >>> >
> >>> >>>
> >>> >>> Encoded actually means, well, encoded, as specified in RFC 2047.
> >>> >>>
> >>> >>> Oleg
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>
> >>>
> >>
> >>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Stefano Bagnara <ap...@bago.org>.
I guess this is a bug in 0.7.1:
https://issues.apache.org/jira/browse/MIME4J-208
Stefano
2011/12/16 Lukáš Vlček <lu...@gmail.com>:
> 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/resources/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/org/mime4j/test/BasicTest.java#L129
>
> Why I am getting this difference?
>
> Regards,
> Lukas
>
> On Fri, Dec 16, 2011 at 1:21 PM, Lukáš Vlček <lu...@gmail.com> 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 guys.
>>
>> Regards,
>> Lukas
>>
>>
>> On Thu, Dec 15, 2011 at 3:32 PM, Stefano Bagnara <ap...@bago.org> 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 part
>>> other than in the line separator sequence.
>>>
>>> From RFC2046:
>>> ---
>>> 4.1.1. Representation of Line Breaks
>>>
>>> The canonical form of any MIME "text" subtype MUST always represent a
>>> line break as a CRLF sequence. Similarly, any occurrence of CRLF in
>>> MIME "text" MUST represent a line break. Use of CR and LF outside of
>>> 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áš Vlček <lu...@gmail.com>:
>>> > 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 decoding
>>> > however, I was able to show that I am getting different content from
>>> > 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/org/mime4j/test/BasicTest.java#L110
>>> >
>>> > The first is using 0.7.2 and I am getting "\r\n" sequence where using
>>> 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áš Vlček <lu...@gmail.com>
>>> 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áš Vlček wrote:
>>> >>> > 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/385c66847bec4393ad67069fb367c174f87c5656
>>> >>> >
>>> >>> > 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?
>>> >>> >
>>> >>>
>>> >>> Encoded actually means, well, encoded, as specified in RFC 2047.
>>> >>>
>>> >>> Oleg
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>>
>>
>>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
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/resources/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/org/mime4j/test/BasicTest.java#L129
Why I am getting this difference?
Regards,
Lukas
On Fri, Dec 16, 2011 at 1:21 PM, Lukáš Vlček <lu...@gmail.com> 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 guys.
>
> Regards,
> Lukas
>
>
> On Thu, Dec 15, 2011 at 3:32 PM, Stefano Bagnara <ap...@bago.org> 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 part
>> other than in the line separator sequence.
>>
>> From RFC2046:
>> ---
>> 4.1.1. Representation of Line Breaks
>>
>> The canonical form of any MIME "text" subtype MUST always represent a
>> line break as a CRLF sequence. Similarly, any occurrence of CRLF in
>> MIME "text" MUST represent a line break. Use of CR and LF outside of
>> 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áš Vlček <lu...@gmail.com>:
>> > 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 decoding
>> > however, I was able to show that I am getting different content from
>> > 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/org/mime4j/test/BasicTest.java#L110
>> >
>> > The first is using 0.7.2 and I am getting "\r\n" sequence where using
>> 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áš Vlček <lu...@gmail.com>
>> 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áš Vlček wrote:
>> >>> > 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/385c66847bec4393ad67069fb367c174f87c5656
>> >>> >
>> >>> > 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?
>> >>> >
>> >>>
>> >>> Encoded actually means, well, encoded, as specified in RFC 2047.
>> >>>
>> >>> Oleg
>> >>>
>> >>>
>> >>>
>> >>
>>
>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
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 guys.
Regards,
Lukas
On Thu, Dec 15, 2011 at 3:32 PM, Stefano Bagnara <ap...@bago.org> 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 part
> other than in the line separator sequence.
>
> From RFC2046:
> ---
> 4.1.1. Representation of Line Breaks
>
> The canonical form of any MIME "text" subtype MUST always represent a
> line break as a CRLF sequence. Similarly, any occurrence of CRLF in
> MIME "text" MUST represent a line break. Use of CR and LF outside of
> 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áš Vlček <lu...@gmail.com>:
> > 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 decoding
> > however, I was able to show that I am getting different content from
> > 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/org/mime4j/test/BasicTest.java#L110
> >
> > The first is using 0.7.2 and I am getting "\r\n" sequence where using
> 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áš Vlček <lu...@gmail.com>
> 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áš Vlček wrote:
> >>> > 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/385c66847bec4393ad67069fb367c174f87c5656
> >>> >
> >>> > 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?
> >>> >
> >>>
> >>> Encoded actually means, well, encoded, as specified in RFC 2047.
> >>>
> >>> Oleg
> >>>
> >>>
> >>>
> >>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Stefano Bagnara <ap...@bago.org>.
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 part
other than in the line separator sequence.
>From RFC2046:
---
4.1.1. Representation of Line Breaks
The canonical form of any MIME "text" subtype MUST always represent a
line break as a CRLF sequence. Similarly, any occurrence of CRLF in
MIME "text" MUST represent a line break. Use of CR and LF outside of
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áš Vlček <lu...@gmail.com>:
> 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 decoding
> however, I was able to show that I am getting different content from
> 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/org/mime4j/test/BasicTest.java#L110
>
> The first is using 0.7.2 and I am getting "\r\n" sequence where using 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áš Vlček <lu...@gmail.com> 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 <ol...@apache.org>wrote:
>>
>>> On Thu, 2011-12-15 at 11:41 +0100, Lukáš Vlček wrote:
>>> > 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/385c66847bec4393ad67069fb367c174f87c5656
>>> >
>>> > 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?
>>> >
>>>
>>> Encoded actually means, well, encoded, as specified in RFC 2047.
>>>
>>> Oleg
>>>
>>>
>>>
>>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
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 decoding
however, I was able to show that I am getting different content from
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/org/mime4j/test/BasicTest.java#L110
The first is using 0.7.2 and I am getting "\r\n" sequence where using 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áš Vlček <lu...@gmail.com> 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 <ol...@apache.org>wrote:
>
>> On Thu, 2011-12-15 at 11:41 +0100, Lukáš Vlček wrote:
>> > 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/385c66847bec4393ad67069fb367c174f87c5656
>> >
>> > 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?
>> >
>>
>> Encoded actually means, well, encoded, as specified in RFC 2047.
>>
>> Oleg
>>
>>
>>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
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 <ol...@apache.org> wrote:
> On Thu, 2011-12-15 at 11:41 +0100, Lukáš Vlček wrote:
> > 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/385c66847bec4393ad67069fb367c174f87c5656
> >
> > 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?
> >
>
> Encoded actually means, well, encoded, as specified in RFC 2047.
>
> Oleg
>
>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2011-12-15 at 11:41 +0100, Lukáš Vlček wrote:
> 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/385c66847bec4393ad67069fb367c174f87c5656
>
> 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?
>
Encoded actually means, well, encoded, as specified in RFC 2047.
Oleg
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
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/385c66847bec4393ad67069fb367c174f87c5656
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áš Vlček <lu...@gmail.com> wrote:
> Thanks, I will give it a try.
> Cheers,
> Lukas
>
>
> On Mon, Dec 12, 2011 at 4:23 PM, Oleg Kalnichevski <ol...@apache.org>wrote:
>
>> On Mon, 2011-12-12 at 16:05 +0100, Lukáš Vlček wrote:
>> > Hi,
>> >
>> > On Mon, Dec 12, 2011 at 3:58 PM, Oleg Kalnichevski <ol...@apache.org>
>> wrote:
>> >
>> > > On Mon, 2011-12-12 at 15:24 +0100, Lukáš Vlček 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 enough
>> 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 = getInputStream("mbox/jbpm-users-01.mbox");
>> try {
>> FieldParser<MailboxListField> mailboxListParser =
>> MailboxListFieldImpl.PARSER;
>> LenientFieldParser fieldParser = new LenientFieldParser();
>> fieldParser.setFieldParser(FieldName.FROM, mailboxListParser);
>> fieldParser.setFieldParser(FieldName.RESENT_FROM,
>> mailboxListParser);
>>
>> DefaultMessageBuilder messageBuilder = new DefaultMessageBuilder();
>> messageBuilder.setFieldParser(fieldParser);
>>
>> Message message = 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 the
>> > > 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áš 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?= <yh...@163.com>
>> > > > > > > > > >
>> > > > > > > > > > in 0.6 it was giving me: "钱宇虹 <yh...@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
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > >
>> > >
>> > >
>>
>>
>>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
Thanks, I will give it a try.
Cheers,
Lukas
On Mon, Dec 12, 2011 at 4:23 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Mon, 2011-12-12 at 16:05 +0100, Lukáš Vlček wrote:
> > Hi,
> >
> > On Mon, Dec 12, 2011 at 3:58 PM, Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > > On Mon, 2011-12-12 at 15:24 +0100, Lukáš Vlček 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 enough
> 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 = getInputStream("mbox/jbpm-users-01.mbox");
> try {
> FieldParser<MailboxListField> mailboxListParser =
> MailboxListFieldImpl.PARSER;
> LenientFieldParser fieldParser = new LenientFieldParser();
> fieldParser.setFieldParser(FieldName.FROM, mailboxListParser);
> fieldParser.setFieldParser(FieldName.RESENT_FROM,
> mailboxListParser);
>
> DefaultMessageBuilder messageBuilder = new DefaultMessageBuilder();
> messageBuilder.setFieldParser(fieldParser);
>
> Message message = 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 the
> > > 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áš 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?= <yh...@163.com>
> > > > > > > > > >
> > > > > > > > > > in 0.6 it was giving me: "钱宇虹 <yh...@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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2011-12-12 at 16:05 +0100, Lukáš Vlček wrote:
> Hi,
>
> On Mon, Dec 12, 2011 at 3:58 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Mon, 2011-12-12 at 15:24 +0100, Lukáš Vlček 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 enough 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 = getInputStream("mbox/jbpm-users-01.mbox");
try {
FieldParser<MailboxListField> mailboxListParser =
MailboxListFieldImpl.PARSER;
LenientFieldParser fieldParser = new LenientFieldParser();
fieldParser.setFieldParser(FieldName.FROM, mailboxListParser);
fieldParser.setFieldParser(FieldName.RESENT_FROM,
mailboxListParser);
DefaultMessageBuilder messageBuilder = new DefaultMessageBuilder();
messageBuilder.setFieldParser(fieldParser);
Message message = 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 the
> > one who volunteers to be a release manager for it.
> >
> > Oleg
> >
> > > On Mon, Dec 12, 2011 at 3:09 PM, Oleg Kalnichevski <ol...@apache.org>
> > wrote:
> > >
> > > > 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?= <yh...@163.com>
> > > > > > > > >
> > > > > > > > > in 0.6 it was giving me: "钱宇虹 <yh...@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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> >
> >
> >
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
Hi,
On Mon, Dec 12, 2011 at 3:58 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Mon, 2011-12-12 at 15:24 +0100, Lukáš Vlček 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 enough 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?
>
> I cannot say when 0.7.2 could be expected. It very much depends on the
> one who volunteers to be a release manager for it.
>
> Oleg
>
> > On Mon, Dec 12, 2011 at 3:09 PM, Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > > 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?= <yh...@163.com>
> > > > > > > >
> > > > > > > > in 0.6 it was giving me: "钱宇虹 <yh...@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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2011-12-12 at 15:24 +0100, Lukáš Vlček 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 enough 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.
I cannot say when 0.7.2 could be expected. It very much depends on the
one who volunteers to be a release manager for it.
Oleg
> On Mon, Dec 12, 2011 at 3:09 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > 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 <ol...@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 <ol...@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?= <yh...@163.com>
> > > > > > >
> > > > > > > in 0.6 it was giving me: "钱宇虹 <yh...@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
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> >
> >
> >
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
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
On Mon, Dec 12, 2011 at 3:09 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> 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 <ol...@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 <ol...@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?= <yh...@163.com>
> > > > > >
> > > > > > in 0.6 it was giving me: "钱宇虹 <yh...@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
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@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 <ol...@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?= <yh...@163.com>
> > > > >
> > > > > in 0.6 it was giving me: "钱宇虹 <yh...@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
> > > >
> > > >
> > > >
> >
> >
> >
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
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 :-)
Thanks,
Lukas
On Mon, Dec 12, 2011 at 2:37 PM, Oleg Kalnichevski <ol...@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 <ol...@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?= <yh...@163.com>
> > > >
> > > > in 0.6 it was giving me: "钱宇虹 <yh...@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
> > >
> > >
> > >
>
>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@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=?=" <ji...@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?= <yh...@163.com>
> > >
> > > in 0.6 it was giving me: "钱宇虹 <yh...@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
> >
> >
> >
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Lukáš Vlček <lu...@gmail.com>.
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
On Fri, Dec 9, 2011 at 2:20 PM, Oleg Kalnichevski <ol...@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=?=" <ji...@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?= <yh...@163.com>
> >
> > in 0.6 it was giving me: "钱宇虹 <yh...@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
>
>
>
Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Posted by Oleg Kalnichevski <ol...@apache.org>.
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=?=" <ji...@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?= <yh...@163.com>
>
> in 0.6 it was giving me: "钱宇虹 <yh...@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