Richard Zowalla created GERONIMO-6907:
-----------------------------------------
Summary: MIME handling deviates from the Jakarta Mail 2.1 spec
Key: GERONIMO-6907
URL: https://issues.apache.org/jira/browse/GERONIMO-6907
Project: Geronimo
Issue Type: Task
Security Level: public (Regular issues)
Affects Versions: Mail_2.1_1.0.2
Reporter: Richard Zowalla
Assignee: Richard Zowalla
Fix For: Mail_2.1_1.0.3
The Jakarta Mail TCK 2.1.1 exposes a cluster of client-side defects in the
jakarta.mail.internet classes, covering 17 of the TCK's tests. All are
independent of any mail server. In detail:
* Filename handling: MimeMessage.getFileName() reads the parameter-stripped
disposition value so the filename parameter is never found; MimeMessage uses
session-scoped lookups for mail.mime.encodefilename/decodefilename where
MimeBodyPart honors System properties; setFileName() force-writes a defaulted
text/plain Content-Type, clobbering explicitly set types; non-ASCII filenames
are written raw instead of RFC 2231-encoded.
* Parsing/formatting: MailDateFormat.parse() leaves the current time's
milliseconds in the result, breaking date equality; ContentType.match(String)
NPEs on null; getContentLanguage() returns the raw comma-joined header instead
of a split list; RFC 2047 encoded-words with lowercase encoding letters are
rejected; the strict RFC 2231 decoder accepts invalid %-hex sequences;
MimeUtility.fold()/unfold() deviates from the reference behavior in 13 of 48
TCK folddata cases.
* Structure/rendering: MimeMultipart(DataSource) never initializes the content
type, so writeTo() NPEs for store-backed multiparts; multipart preamble line
endings are rewritten to CRLF; InternetAddress.toUnicodeString() has an index
bug that renders \{"a","b"} as "a, a"; address parsing rejects all bytes >=
0x80, preventing UTF-8 addresses (mail.mime.allowutf8).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
