[jira] [Updated] (EMAIL-212) MIME closing boundary delimiter incorrectly accepted when followed by extra characters

["Makarand Hinge (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/EMAIL-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Makarand Hinge updated EMAIL-212:
---------------------------------
    Attachment: Screenshot from 2026-03-05 23-47-23.png

> 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: sender@example.com
> To: recipient@example.com
> 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)