Read RFC 2231 continuations in one pass and honor every charset the platform names

[tabmail-kmyi]

Two regressions from #230, both in how EMLParser reads RFC 2231 extended parameters. Neither touches the parameter-boundary hardening that commit added.

Continuation sections cost quadratic work

extendedContinuation found each numbered section with extractHeaderParam, and that function tokenizes the whole header on every call. A sender who writes N legal filename*N*= sections therefore made the parser do work proportional to N². Measured with swiftc -O -wmo on the exact function source:

sections	header bytes	before #230	#230
1,024	17,339	0.012 s	0.50 s
2,048	35,771	0.020 s	1.97 s
4,096	72,635	0.031 s	8.08 s
8,192	146,363	0.056 s	did not finish in 25 s

The full EMLParser.parse reaches this through an ordinary multipart body with folded header lines, so a small received attachment can hold a parse for seconds.

The header is now tokenized once into parameters(of:), and both extractHeaderParam and the continuation collector read from that list. The collector also applies RFC 2231 §3 as written: sections count in decimal from 0, no leading zeroes, no gaps, and where a section repeats the first occurrence stands, matching extractHeaderParam.

Blank and non-whitelisted charsets discarded the filename

decodeExtendedBytes accepted only utf-8, us-ascii and iso-8859-1 and returned nil for every other label, including the blank one. RFC 2231 §4 says "it is perfectly permissible to leave either the character set or language field blank" with the ' delimiters present, so filename*=''invoice.pdf is a legal spelling of invoice.pdf, and windows-1252 or iso-8859-15 labels are ordinary real-world mail. All of these lost the name and fell through to a generated one.

A blank charset now decodes as UTF-8, which reads every US-ASCII value unchanged and still rejects bytes that are not text. Any other label resolves through String.Encoding(ianaCharsetName:), the same lookup the encoded-word decoder already uses. A label the platform cannot name still yields nil, and extractFilename falls through to the literal spelling.

Layout

The RFC 2231 helpers move to EMLParser+RFC2231.swift so EMLParser+Parameters.swift stays under the lint file-length limit. Nothing changes in the move beyond the two fixes above.

Verification

• swift test: 624 tests in 77 suites pass (619 existing plus the five below).
• swiftlint lint --strict: 0 violations.
• New tests in MIMEParameterParsingTests: blank charset; windows-1252, iso-8859-15 and ISO-8859-1 labels; unknown charset falling back to the literal spelling; section-numbering rules; and a 4,096-section header that must decode in under two seconds. On the parent commit the blank-charset, platform-charset and linear-work tests fail (the last after 34 s in a debug build); the other two pin behaviour that already held.

🤖 Generated with Claude Code

https://claude.ai/code/session_0132BGdMBGzmQwA6jkB3rPma

[odrobnik]

Requesting changes for one cross-platform RFC 2231 decoding regression: on non-Apple platforms, the new charset path can treat unsupported legacy encodings as UTF-8, corrupting valid filenames and suppressing the safe literal fallback. No builds or tests were run, per the review constraints.

One review with 1 finding, detailed in an inline comment:

• MEDIUM Sources/SwiftMail/MIME/EMLParser+RFC2231.swift:58

To unblock the merge, address every finding: react with 👍 if it is accurate (👎 if not), reply with a brief comment on what was fixed, and mark the item as resolved.

[odrobnik]

The earlier cross-platform legacy-charset corruption is addressed at the new head, and the continuation work remains linear. Requesting changes for one remaining RFC 2231 charset regression: the new UTF-8 safeguard applies narrower label normalization than SwiftCross itself, so resolver-supported UTF-8 aliases are discarded. No builds or tests were run, per the review constraints.

One review with 1 finding, detailed in an inline comment:

• MEDIUM Sources/SwiftMail/MIME/EMLParser+RFC2231.swift:59

To unblock the merge, address every finding: react with 👍 if it is accurate (👎 if not), reply with a brief comment on what was fixed, and mark the item as resolved.

[tabmail-kmyi]

Both findings are addressed and the head is now 53f27c9:

• 9e84bfb: a .utf8 resolution is accepted only when the label itself names UTF-8 or US-ASCII, so SwiftCross's placeholder for GBK/Big5/EUC-KR/KOI8-R/macintosh no longer decodes those bytes as UTF-8.
• 53f27c9: isUTF8Label normalizes exactly as the resolver does (trim, unquote, lowercase, _ → -, collapse repeated hyphens, drop the escape prefix) before matching.

Ready for another look whenever you have a moment.

[odrobnik]

Requesting changes for two remaining RFC 2231 charset regressions. Blank charset fields currently assign UTF-8 meaning to otherwise ambiguous non-ASCII bytes and can suppress the safe literal fallback. Separately, the UTF-8 placeholder safeguard is applied on Darwin too, where it rejects legitimate aliases that CoreFoundation resolves to UTF-8. The continuation collection change is linear and the previously reported unsupported-legacy-label and normalization cases are addressed. No builds or tests were run, per the review constraints.

One review with 2 findings, each detailed in an inline comment:

• MEDIUM Sources/SwiftMail/MIME/EMLParser+RFC2231.swift:56
• MEDIUM Sources/SwiftMail/MIME/EMLParser+RFC2231.swift:59

To unblock the merge, address every finding: react with 👍 if it is accurate (👎 if not), reply with a brief comment on what was fixed, and mark the item as resolved.

[tabmail-kmyi]

Both findings are addressed and the head is now 9f1a2b6:

• A blank charset field decodes only US-ASCII bytes; anything else yields nil and the literal filename= wins (RFC 2231 §4: a blank field "MUST NOT be done in order to indicate a default character set").
• The UTF-8 placeholder guard is compiled only where SwiftCross uses its hand table, under SwiftCross's own platform condition, so CoreFoundation's .utf8 resolutions such as unicode-1-1-utf-8 are trusted on Darwin. On other platforms the guard is a simple discriminator (label letters+digits start with utf8) rather than a copy of the resolver's normalization, so it cannot drift from it again.

627 tests in 77 suites pass, SwiftLint strict is clean, and the new assertions are red on the previous head. Ready for another look whenever you have a moment.

[odrobnik]

MissionControl review timed out for head 9f1a2b6c875b. Auto-merge remains blocked; human review is required.

[odrobnik]

Requesting changes for one build-blocking issue introduced by the RFC 2231 file split. The new file calls SwiftCross's IANA charset initializer without importing SwiftCross, so the SwiftMail target cannot compile. The continuation implementation is linear and the previously reported charset regressions are addressed. No builds or tests were run, per the review constraints.

One review with 1 finding, detailed in an inline comment:

• HIGH Sources/SwiftMail/MIME/EMLParser+RFC2231.swift:57

To unblock the merge, address every finding: react with 👍 if it is accurate (👎 if not), reply with a brief comment on what was fixed, and mark the item as resolved.

[tabmail-kmyi]

Addressed; head is now 5e234fd. EMLParser+RFC2231.swift imports SwiftCross explicitly. No behaviour change: 627 tests pass locally and SwiftLint strict is clean.

[odrobnik]

Approved. The previously reported charset and import issues are addressed at 5e234fd. I traced filename extraction and Content-Type cleanup through their parser call sites and checked SwiftCross 1.2.0's on-disk IANA resolver: the platform split and UTF-8 placeholder safeguard now match the dependency, blank charsets fail safely for non-ASCII bytes, and continuation collection remains linear with contiguous decimal semantics. No builds or tests were run, per the review constraints.

👍 No findings.