Wei-Cheng Wu created EMAIL-212:
----------------------------------
Summary: 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
Fix For: 1.6.0
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)
