[
https://issues.apache.org/jira/browse/EMAIL-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18063302#comment-18063302
]
Makarand Hinge edited comment on EMAIL-212 at 3/5/26 6:20 PM:
--------------------------------------------------------------
Hi [~ggregory],
I ran 2.0.0-M2-SNAPSHOT locally - MimeBoundaryTest.testMultipartClosingBoundary
is failing as expected. The parser treats -{-}Part{-}- More incorrectly as a
closing boundary. We will update the parser to follow RFC 2046 §5.1.1 so the
test passes and aligns with peer implementations. !Screenshot from 2026-03-05
23-47-23.png!
was (Author: indy):
Hi [~ggregory],
I ran 2.0.0-M2-SNAPSHOT locally - MimeBoundaryTest.testMultipartClosingBoundary
is failing as expected. The parser treats --Part-- !Screenshot from 2026-03-05
23-47-23.png! More incorrectly as a closing boundary. We will update the parser
to follow RFC 2046 §5.1.1 so the test passes and aligns with peer
implementations.
> MIME closing boundary delimiter incorrectly accepted when followed by extra
> characters
> --------------------------------------------------------------------------------------
>
> Key: EMAIL-212
> URL: https://issues.apache.org/jira/browse/EMAIL-212
> Project: Commons Email
> Issue Type: Bug
> Environment: org.apache.commons / commons-email 1.6.0
> Debian GNU/Linux 12
> Reporter: Wei-Cheng Wu
> Priority: Major
> Fix For: 1.6.0
>
> Attachments: Screenshot from 2026-03-05 23-47-23.png
>
>
> I found a discrepancy in how this implementation handles multipart closing
> boundary delimiter lines.
> Specifically, apache-common-email will stop at the line {{-Part-More}} for
> the following payload:
> {code:java}
> MIME-Version: 1.0
> From: [email protected]
> To: [email protected]
> Subject: Multiple text attachments
> Content-Type: multipart/mixed; boundary="Part"
>
> --Part
> Content-Type: text/plain; name="data.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment; filename="data.txt"
>
> abc
>
> --Part--More
> --Part--
> {code}
> However, according to RFC 2046 §5.1.1, a boundary delimiter line is defined
> as:
> ??a line consisting entirely of two hyphen characters ("--"), followed by the
> boundary parameter value from the Content-Type header, optionally followed by
> whitespace, and {*}terminated by CRLF{*}.??
> Tested on a few peer implementations and found that they all obtained the
> body content correctly as {{{}abc\n\n--Part--More{}}}.
>
> Incorrect transformation may result in broken message displays, mismatched
> signatures, or unexpected control characters being introduced into downstream
> systems. Aligning behavior with RFC 2046 and peer implementations would
> improve interoperability across systems. We hope this report helps clarify
> the discrepancy.
> Thank you!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
