[
https://issues.apache.org/jira/browse/GERONIMO-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Zowalla closed GERONIMO-6909.
-------------------------------------
Resolution: Fixed
Fixed on main in commit 7b37292, shipping in Mail_2.1_1.1.1.
The single-value policy now covers only the fields the specifications restrict
to one occurrence - RFC 5322 section 3.6 (Date, From, Sender, Reply-To, To, Cc,
Bcc, Message-ID, In-Reply-To, References, Subject) and the RFC 2045 entity
headers plus Content-Disposition from RFC 2183 - and matches
case-insensitively, which also settles the equals versus equalsIgnoreCase
inconsistency noted in the description. Received and Return-Path need no
special case any more, being absent from that set.
Two X- headers or two Comments headers can now be added, while a second Subject
or Content-Type is still rejected.
This is a behaviour change on the outbound side: addHeader calls that
previously threw IllegalStateException for a repeated non-singleton header now
succeed. That is the point of the issue, but it is worth knowing for anyone who
was relying on the old strictness as a guard.
Covered by new tests in InternetHeadersTest. Jakarta Mail 2.1 TCK: 321/321.
> InternetHeaders.addHeader rejects legally repeatable headers - narrow the
> single-value policy to the RFC 5322/2045 singleton fields
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-6909
> URL: https://issues.apache.org/jira/browse/GERONIMO-6909
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
> Reporter: Richard Zowalla
> Priority: Major
>
> Split out from GERONIMO\-6908, which fixes the inbound half of the same check.
> GERONIMO\-6870 introduced a single\-value policy in {{InternetHeaders}} so
> that we do not emit messages with duplicated headers, because some servers \-
> Gmail among them \- reject those. The intent is right, but the rule is
> implemented as "every header except {{Received}} and {{Return\-Path}} may
> appear at most once", which is far broader than what the RFCs actually
> constrain.
> As a result {{addHeader}} throws {{IllegalStateException}} for cases that are
> perfectly legal:
> {code:java}
> InternetHeaders headers = new InternetHeaders\(\);
> headers.addHeader\("X\-Trace\-Id", "abc"\);
> headers.addHeader\("X\-Trace\-Id", "def"\); // IllegalStateException
> {code}
> The same applies to {{Comments}} and {{Keywords}} \(RFC 5322 section 3.6.5,
> "unlimited"\), the {{Resent\-_}} set \(section 3.6.6, one block per
> resending\), {{List\-_}} \(RFC 2369\), and every application\-defined {{X\-}}
> header. Callers that build a message programmatically have no way to express
> those, and {{MimeMessage.addHeader}} / {{MimeBodyPart.addHeader}} inherit the
> restriction.
> h2. Proposed fix
> Apply the policy only to headers the specifications really do restrict to one
> occurrence:
> * RFC 5322 section 3.6: {{Date}}, {{From}}, {{Sender}}, {{Reply\-To}},
> {{To}}, {{Cc}}, {{Bcc}}, {{Message\-ID}}, {{In\-Reply\-To}}, {{References}},
> {{Subject}}
> * RFC 2045: {{MIME\-Version}}, {{Content\-Type}},
> {{Content\-Transfer\-Encoding}}, {{Content\-ID}}, {{Content\-Description}},
> and RFC 2183 {{Content\-Disposition}}
> Everything else is appended, which is what
> {{InternetHeaders.getHeader\(String\)}} returning a {{String\[\]}} implies
> and what Angus does. The matching must be case\-insensitive; today the
> {{Received}} / {{Return\-Path}} exemption uses {{equals}} while the duplicate
> scan uses {{equalsIgnoreCase}}, so {{received:}} in lower case is treated
> inconsistently.
> {{Received}} and {{Return\-Path}} stay exempt and are simply covered by not
> being in the singleton set.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
