What happens
The SMTP protocol internals are the least-tested code in the repo by a wide margin. Measured with vitest run --coverage:
File | % Stmts | % Branch | % Funcs | % Lines
-------------------|---------|----------|---------|--------
src/core | 97.65 | 93.36 | 98.64 | 98.04
src/render | 94.11 | 93.75 | 100 | 95.65
src/drivers/_ses | 92.45 | 66.66 | 85.71 | 91.48
src/middleware | 88.12 | 81.59 | 83.33 | 90.32
src/drivers | 81.7 | 72.54 | 82.53 | 86.05
src/drivers/_smtp | 37.17 | 46.96 | 31.57 | 40.08 <-
Two thirds of the statements and two thirds of the functions in src/drivers/_smtp/ are never executed by the suite. That is roughly 1,100 lines covering DKIM signing, four SASL mechanisms, and the connection pool.
Why it matters
This code was carried over from 0.x unchanged during the v1 rewrite, so it is also the code the rewrite reviewed least. The failure modes are quiet ones:
- DKIM — a signature that is malformed, or canonicalized wrongly, still sends. The message is simply not authenticated, so it lands in spam. Nothing in the suite signs a message and verifies the result, so a canonicalization bug would ship silently.
- AUTH —
CRAM-MD5 and XOAUTH2 have no test at all. Only PLAIN is exercised, and only through the driver-level happy path. A wrong challenge response means a provider we claim to support cannot be used.
- Pool — reuse,
maxMessagesPerConnection, idle expiry and the dispose grace period are all untested. A connection returned to the pool in a bad state corrupts the next message, which makes the bug look unrelated to its cause.
Where
src/drivers/_smtp/{dkim,auth,pool,connection}.ts.
Suggested fix
Test them against their specifications, not against current behaviour:
- DKIM: generate a key with Web Crypto, sign a known message, and verify the signature independently. That proves canonicalization and signing agree with a verifier rather than with themselves. Cover both
rsa-sha256 and ed25519-sha256, and assert the bh= body hash for the relaxed canonicalization in RFC 6376 §3.4.4.
- AUTH: assert the exact base64 payloads the RFCs define for
PLAIN, LOGIN, CRAM-MD5 (RFC 2195) and XOAUTH2, plus pickAuthMethod's preference order.
- Pool: drive it through the existing fake server — reuse across sends, retirement at
maxMessagesPerConnection, and that a connection which failed mid-transaction is discarded rather than handed to the next message.
What happens
The SMTP protocol internals are the least-tested code in the repo by a wide margin. Measured with
vitest run --coverage:Two thirds of the statements and two thirds of the functions in
src/drivers/_smtp/are never executed by the suite. That is roughly 1,100 lines covering DKIM signing, four SASL mechanisms, and the connection pool.Why it matters
This code was carried over from 0.x unchanged during the v1 rewrite, so it is also the code the rewrite reviewed least. The failure modes are quiet ones:
CRAM-MD5andXOAUTH2have no test at all. OnlyPLAINis exercised, and only through the driver-level happy path. A wrong challenge response means a provider we claim to support cannot be used.maxMessagesPerConnection, idle expiry and the dispose grace period are all untested. A connection returned to the pool in a bad state corrupts the next message, which makes the bug look unrelated to its cause.Where
src/drivers/_smtp/{dkim,auth,pool,connection}.ts.Suggested fix
Test them against their specifications, not against current behaviour:
rsa-sha256anded25519-sha256, and assert thebh=body hash for the relaxed canonicalization in RFC 6376 §3.4.4.PLAIN,LOGIN,CRAM-MD5(RFC 2195) andXOAUTH2, pluspickAuthMethod's preference order.maxMessagesPerConnection, and that a connection which failed mid-transaction is discarded rather than handed to the next message.