mime: allow duplicate media parameters with equal values

[iredmail]

[This is a duplicate proposal of #28618, but it's closed due to Timed out in state WaitingForInfo. and doesn't accept further discussion.]

Some mail user agent (MUA) (incorrectly) generates mail header with duplicate parameter names, this is the one i received recently (duplicate boundary):

Content-Type: multipart/alternative; boundary="----RTIR0GV26TDW15Q5CVX979LBL6XN18"; boundary="----RTIR0GV26TDW15Q5CVX979LBL6XN18"

Golang standard library mime.ParseMediaType() does not allow duplicate media parameters so it is impossible to parse such a header (it returns error mime: duplicate parameter name).

I suggest making the mime.ParseMediaType() function more tolerant to such errors, for example, just use the first value and ignore the rest. At least it should not stop the execution if duplicate parameters have the same value.

---

See also:

• proposal: mime: handling duplicate media parameters #28618, @xeruf reported similar mail header: Content-Type: text/html; charset=utf-8; charset=UTF-8
• mime: bypassing multi-boundary check via Parameter Value Continuations #47602, @Xym01 reported similar http header: Content-Type: multipart/form-data;boundary="boundary";boundary="another-boundary"

[rsc]

@iredmail what MUA specifically is generating this kind of message?

/cc @neild

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[iredmail]

@iredmail what MUA specifically is generating this kind of message?

Unfortunately the email doesn't contain a header like X-Mailer: to identify the MUA program, so i don't know. :(

• The email was sent on 24 Feb 2020, since we use mime package to parse email message for archiving purpose, it's normal that we need to parse a lot old emails which might be non-RFC-compliant.
• Email message is easy to forge, and many MUAs (especially email marketing and spamming tools) don't generate standard emails, it's also normal that we receive non-RFC-compliant messages.

[rsc]

It sounds like the proposal is to continue to reject duplicate boundary= parameters but have a special case that if the duplicates all say the same boundary value, then it's OK. There's at least one buggy program generating these, and the intent is at least pretty clear.

Do I have that right?

[iredmail]

You're right.

Unlike duplicate parameters with different values, there's no need to judge which one to use as final value, so ideally it should be allowed. :)

Note: ideally it should apply to all duplicate parameters with same value, not just boundary=. :)

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[tpaschalis]

I'll take a stab and open a CL for this if it's okay. With a quick look through the RFC, it seems like the the tokens are case-insensitive, but I'm not sure if this is okay for edge-case tokens using different character sets.

[gopherbot]

Change https://golang.org/cl/363094 mentions this issue: mime: allow duplicate media type parameters with equivalent values

[iredmail]

Dear @tpaschalis @rsc

Thank you very much. :)

[ianlancetaylor]

Wait, we shouldn't close this issue yet. This now tracks actually implementing the change.

[gopherbot]

Change https://go.dev/cl/450280 mentions this issue: go1.20: add release notes for archive/zip, encoding/binary, mime