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