Establish RFC recipient parsing boundaries #4

New issue

Closed

opened 2026-07-22 22:12:33 +00:00 by phg · 2 comments

phg commented

2026-07-22 22:12:33 +00:00

Owner

Part of #1

Question

Against the relevant email-format and internationalized-email RFCs plus mature parser documentation, what exact parsing boundary is required to reliably extract recipient local-parts from repeated and folded Delivered-To, X-Original-To, To, and Cc fields, including malformed fields, comments, groups, quoted local-parts, multiple plus signs, non-ASCII addresses, and duplicate recipients, while implementing the agreed tiered fallback rule?

Part of #1 ## Question Against the relevant email-format and internationalized-email RFCs plus mature parser documentation, what exact parsing boundary is required to reliably extract recipient local-parts from repeated and folded Delivered-To, X-Original-To, To, and Cc fields, including malformed fields, comments, groups, quoted local-parts, multiple plus signs, non-ASCII addresses, and duplicate recipients, while implementing the agreed tiered fallback rule?

phg added the

wayfinder:research

label 2026-07-22 22:12:33 +00:00

phg referenced this issue

2026-07-22 22:13:00 +00:00

Define flat plus-tag encoding and collision rules #5

phg referenced this issue

2026-07-22 22:13:03 +00:00

Define verification and release acceptance criteria #12

phg commented

2026-07-22 22:14:06 +00:00

Author

Owner

Claimed by Codex agent /root/research_rfc_parsing for RFC recipient parsing research.

phg commented

2026-07-22 22:20:48 +00:00

Author

Owner

Resolved.

Parse only the message header section, preserve and unfold every matching occurrence, and require complete syntactic validation rather than regex or partial recovery.
Collect plus tags from every valid Delivered-To and X-Original-To single-addr-spec field. Only when that tag set is empty, parse every To and Cc address-list and flatten mailbox members from groups.
Derive the plus tag from the semantic local-part after RFC quoting/comment handling: split once at the first literal +, reject an empty suffix, and retain all later + characters.
Accept SMTPUTF8 only as valid UTF-8/RFC 6532 syntax. Preserve exact case and Unicode sequence; perform no case-folding or normalization. Deduplicate exact semantic suffixes only.
Reject a malformed occurrence as a unit, continue with valid sibling occurrences, and emit a rate-limited diagnostic without logging the full recipient address.

Primary-source citations, parser-library caveats, and required acceptance vectors are in the findings.

Context: branch research/rfc-recipient-parsing, commit 9ddb9b08.

Resolved. - Parse only the message header section, preserve and unfold every matching occurrence, and require complete syntactic validation rather than regex or partial recovery. - Collect plus tags from every valid Delivered-To and X-Original-To single-addr-spec field. Only when that tag set is empty, parse every To and Cc address-list and flatten mailbox members from groups. - Derive the plus tag from the semantic local-part after RFC quoting/comment handling: split once at the first literal +, reject an empty suffix, and retain all later + characters. - Accept SMTPUTF8 only as valid UTF-8/RFC 6532 syntax. Preserve exact case and Unicode sequence; perform no case-folding or normalization. Deduplicate exact semantic suffixes only. - Reject a malformed occurrence as a unit, continue with valid sibling occurrences, and emit a rate-limited diagnostic without logging the full recipient address. Primary-source citations, parser-library caveats, and required acceptance vectors are in [the findings](https://git.s1q.dev/phg/fuse-mail-dir-by-tag/src/commit/9ddb9b08e149c7b0accef6e1227590e4cdf04657/docs/research/rfc-recipient-parsing.md). Context: branch [research/rfc-recipient-parsing](https://git.s1q.dev/phg/fuse-mail-dir-by-tag/src/branch/research/rfc-recipient-parsing), commit [9ddb9b08](https://git.s1q.dev/phg/fuse-mail-dir-by-tag/commit/9ddb9b08e149c7b0accef6e1227590e4cdf04657).

phg closed this issue

2026-07-22 22:20:49 +00:00