[ https://issues.apache.org/jira/browse/MIME4J-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842915#comment-17842915 ]
Benoit Tellier commented on MIME4J-284: --------------------------------------- https://github.com/apache/james-mime4j/pull/105 proves that this is no longer the case in MIME4J 0.8.x ? > Headers are being unfolded incorrectly if they contain an equals sign > --------------------------------------------------------------------- > > Key: MIME4J-284 > URL: https://issues.apache.org/jira/browse/MIME4J-284 > Project: James Mime4j > Issue Type: Bug > Components: parser (core) > Affects Versions: 0.7.2 > Reporter: Joshua Turner > Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Given a set of headers like the following: > {noformat} > MIME-Version: 1.0 > References: > <CAMpLFpB=uu_mqgwf5rtowqcfkd9cmzkboj782872ydgfp1d...@mail.gmail.com> > <CAMpLFpCVygEwb+t=FmD6TqiDLrQHkREvh=_2=zinf8wh1-y...@mail.gmail.com> > In-Reply-To: > <CAMpLFpCVygEwb+t=FmD6TqiDLrQHkREvh=_2=zinf8wh1-y...@mail.gmail.com>{noformat} > The equals sign in the second reference is causing Mime4J to recognize the > second line as a new Field, with the first part of the 2nd message id as the > key, and the part after the equals sign as the value. I'm reasonably sure > that this is happening in > org.apache.james.mime4j.stream.RawFieldParser.parseParameter(), when calling > parseToken() – as the cursor loops over the input byte sequence, whitespace > at the beginning of the line is ignored in the consideration of whether the > given line represents a new K-V pair, or a folded continuation of the > preceding one. > See RFC2822 Sec 2.2.3. -- This message was sent by Atlassian Jira (v8.20.10#820010)