send_mailto now skips empty/whitespace-only recipients in the ; separated To list, so a stray leading/trailing/duplicate ; no longer produces an invalid RCPT TO:<> and breaks the SMTP transaction.
This brings the envelope in line with how format_addr_list already normalizes the headers.

I’d request changes on PR #28262. The overall direction—separating SMTP envelope addresses from RFC 5322 header formatting—is good, but I found two correctness regressions in the new mailbox parser.

• P2 — split_mailbox truncates valid quoted local-parts containing >. After finding the opening <, the implementation uses index_after('>') for the closing delimiter. That search is not quote-aware. For example, User <"a>b"@example.com> is valid, but this parser will treat the > inside "a>b" as the end of the angle address and extract "a as the addr-spec. RFC 5321 permits > inside a quoted local-part. ([RFC Editor]1)
  Fix: scan for the closing > while tracking quoted-string/escape state, and add a regression test such as User <"a>b"@example.com>.

• P2 — quoted display names are not unescaped before being re-escaped. strip_quotes() removes only the outer quotes, while format_addr() later escapes every backslash again. A valid input such as "A\(B" <x@example.com> semantically represents display name A(B, but this code serializes the retained backslash and changes the display name. RFC 5322 permits a quoted-pair to escape any visible character or whitespace, not just " and \. The trimmed[len-2] != '\\' closing-quote check also fails for even-length runs of backslashes before the closing quote. ([RFC Editor]2)
  Fix: parse quoted strings left-to-right, decode quoted-pairs to their underlying characters, then escape them once when serializing. Tests should cover a generic quoted-pair and a display name ending in a literal backslash.

• Adjacent Bcc issue worth addressing in this PR: Client.send() sends envelope recipients only from config.to, while message_data() emits populated Cc: and Bcc: headers. So Cc/Bcc recipients do not receive the message through send(), and a configured Bcc address can instead be exposed in the DATA sent to To recipients. This behavior predates some of the parser work, but the new Bcc-header test effectively blesses it, which conflicts with the PR’s stated goal of correcting Bcc handling. RFC 5322 describes Bcc handling specifically so blind-recipient identities aren't exposed to other recipients. ([RFC Editor]2)
  I’d make envelope recipients To + Cc + Bcc, while omitting populated Bcc addresses from the normal message copy (or using separate recipient-specific copies).

The tests otherwise cover the common cases well—plain addresses, display names, Unicode names, semicolon-separated recipients, and envelope normalization. The targeted vlib modules CI is green on head df331b59…; the PR as a whole is not fully green yet, with other workflows still failing.

I haven’t posted anything to GitHub. If you want, I can turn the first two findings into concise inline review comments and submit a Request changes review.

I can also keep an eye on the PR for fixes or new CI results.

Thank you for the thorough review and for taking the time to point out the weak spots.
I'll continue working on this PR to get it in shape.

I would also suggest merging main into this PR, to (hopefully) cut down the CI errors.

Fixed split_mailbox to properly handle quoted local-parts containing > and unescape quoted display names before re-escaping.
Envelope recipients now include To + Cc + Bcc, while Bcc addresses are kept out of DATA headers.
Also added CRLF injection hardening in address fields.

Re-reviewed the updated head 78acc116.

Your three previous blockers are fixed correctly:

• Quote-aware closing > parsing now handles addresses like User <"a>b"@example.com>, with regression tests.
• Quoted display names are decoded before re-escaping; the tests now cover A\(B and a trailing literal backslash.
• To + Cc + Bcc are all sent as SMTP envelope recipients, while Bcc is omitted from DATA, with an end-to-end SMTP test covering all three classes.

Also, correction to something I mentioned while reviewing: cfg.subject.is_ascii() is fine. In V, is_ascii() specifically checks printable through ~, so it preserves the old Subject behavior for CR/LF/control characters.

I found one remaining P2 in the CRLF hardening, though:

split_mailbox() only calls strip_crlf() after it successfully finds an angle-address. For the very common bare-address path, it returns trimmed directly:

open_at := index_unquoted(trimmed, `<`, 0) or {
    return none, trimmed
}

That means a bare value such as:

victim@example.com
X-Evil: yes

can still put a newline into format_addr(), and malformed bare/envelope input can still place CRLF into RCPT TO. The newly added tests only exercise CRLF inside <...> or the display-name path.

The simplest fix is to sanitize before branching:

trimmed := strip_crlf(s.trim_space())

and then remove/reduce the later duplicate stripping. I'd add one bare-address CRLF regression test for both format_addr() and envelope_addr().

There is also still a CI blocker: the current head has vlib modules CI green, but both Linux GCC and Clang fail the “All code is formatted” step. The PR branch is also behind current master, which is now e9bb2f0d….

So my current verdict is request changes for the bare-address CRLF path + get formatting CI green. After those, I’d be comfortable approving.

I fixed the bare-address CRLF path - split_mailbox() now strips CRLF before branching, so a value like victim@example.com\nX-Evil: yes can't slip a newline into either format_addr() or envelope_addr().
I also added the two regression tests - one for each of those.

About the "All code is formatted" CI step. I rebased onto the latest master and re-ran the formatter locally.
Ideally I'd have checked against a freshly built compiler, but I couldn't - master currently fails to self-build.
Running make from scratch and building from an older ./v both error out in the V3 code:

// `vlib/v3/transform/transform.v`, `vlib/v3/transform/transform_parallel_notd_v3_no_parallel.v`
cannot assign to a.file_node_ids: expected []i32, not []int
// `vlib/v3/gen/c/names.v`
cannot copy map: call move or clone

So I ran v fmt -verify / v fmt -inprocess -verify with the one compiler that does still build.

The failures on this step are all in files outside this PR (mostly vlib/v3/, plus a few in fasthttp, net/quic).
Every file I touched under vlib/net/smtp passes both formatter checks.
I'd rather not reformat unrelated files here - that would bury this PR under dozens of formatting-only changes.

And if the CI failure actually does depend on something in this PR, I'm honestly not sure what I'm supposed to change.