Re: Regression in MimeStreamParser: part body stream ends with CR

[Madis Loitmaa]

Hello,
Looks like the attached unit test got lost in transit, it's present in
my sent folder. I'll try to inline it at the end of the email this
time.

Best regards,
Madis Loitmaa

// file src/test/java/org/apache/james/mime4j/parser/PartLengthTest.java
package org.apache.james.mime4j.parser;

import org.apache.commons.io.IOUtils;
import org.apache.james.mime4j.MimeException;
import org.apache.james.mime4j.stream.BodyDescriptor;
import org.junit.Assert;
import org.junit.Test;

import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.nio.charset.StandardCharsets;

public class PartLengthTest {
    @Test
    public void testExtractPartWithDifferentLengths() throws Exception {
        StringBuilder partBuilder = new StringBuilder();
        for (int i = 1; i <= 5000; i++) {
            partBuilder.append(i % 80 == 0 ? "\n" : "A");
            String part = partBuilder.toString();
            String mimeMessage = createMimeMultipart(part);

            String extracted = extractPart(mimeMessage);

            if (!part.equals(extracted)) {
                System.out.println("Extracted part comparison failed
for part length " + i);
            }
            Assert.assertEquals(part, extracted);
        }
    }

    private String createMimeMultipart(String part) {
        return "Content-type: multipart/mixed; boundary=QvEgqhjEnYxz\r\n"
                + "\r\n"
                + "--QvEgqhjEnYxz\r\n"
                + "Content-Type: text/plain\r\n"
                + "\r\n"
                + part
                + "\r\n"
                + "--QvEgqhjEnYxz--\r\n";
    }

    private String extractPart(String mimeMessage) throws
MimeException, IOException {
        String[] resultWrapper = new String[1];

        MimeStreamParser parser = new MimeStreamParser();
        parser.setContentHandler(new AbstractContentHandler() {
            @Override
            public void body(BodyDescriptor bd, InputStream is) throws
MimeException, IOException {
                resultWrapper[0] = new String(IOUtils.toString(is,
StandardCharsets.UTF_8).getBytes());
            }
        });
        parser.parse(new ByteArrayInputStream(mimeMessage.getBytes()));
        return resultWrapper[0];
    }
}
//end-of-file


Kontakt Rene Cordier (<rcord...@apache.org>) kirjutas kuupäeval T, 17.
september 2024 kell 05:55:
>
> Hello Madis,
>
> First of all thank you for your report. If there is indeed a regression
> we should take a look and fix it.
>
> However, I don't see any file attached to your email? Maybe you forgot.
> Could you please try to resend your unit test attached to your mail
> response please? That would help the community to check, understand and
> take proper actions for a fix.
>
> Thank you and best regards,
>
> Rene.
>
> On 9/11/24 1:32 PM, Madis Loitmaa wrote:
> > Hello Mime4j Developers,
> >
> > I am reporting a regression in the MimeStreamParser when extracting
> > parts of a multipart message.
> >
> > Specifically, when processing messages with certain body lengths, the
> > CR character (from the CRLF sequence preceding the boundary marker) is
> > incorrectly included as the last character of the part body.
> >
> > Environment:
> > This issue was identified after upgrading Mime4j in our project from
> > version 0.8.7 to 0.8.11. It appears to affect all versions starting
> > from 0.8.8.
> >
> > Reproduction:
> > - I have attached a unit test to this email, which demonstrates the
> > problem. The test fails for a part body length of 4051 bytes on the
> > current master branch (commit
> > 85995590ad6700cc8bf7a3b8462ce87843dab5bd), but passes when tested with
> > version 0.8.7 (commit ed5a50c8071080b4eaedd6ab13baf25843d691a3).
> >
> > - The bug appears when CRLF is used as the line separator. The issue
> > does not occur when LF is used.
> >
> > Attachments:
> > A unit test demonstrating the issue.
> > src/test/java/org/apache/james/mime4j/parser/PartLengthTest.java
> >
> > Please let me know if you need any further information or clarification.
> >
> > Best regards,
> > Madis Loitmaa