email-nodemailer: move to nodemailer 10 for the September advisories?

[admin-laicadev]

Is a move of @payloadcms/email-nodemailer to nodemailer 10 planned for 3.x?

@payloadcms/email-nodemailer 3.90.2 depends on nodemailer ^9.1.1, and so do the 3.x branch and 4.0.0-beta.1. Several nodemailer advisories from September have their fix only in 10.x:

• GHSA-6vj9-mwq6-2f5v: DNS cache reuses the TLS servername across transports, fixed in 10.0.2
• GHSA-v53p-9fqp-m79j: quadratic backtracking in the address parser, fixed in 10.0.6
• GHSA-g57g-f23g-4646: malformed envelope recipient from comment parsing, fixed in 10.0.9

We tried forcing nodemailer 10.1.1 through a yarn resolution. The only break we saw is in the types: NodemailerAdapterArgs.transportOptions is typed as SMTPConnection.Options from nodemailer/lib/smtp-connection. nodemailer 10 ships its own types, and its SMTPConnectionOptions has no auth field, so the usual config fails to compile:

nodemailerAdapter({
  defaultFromAddress: 'noreply@example.com',
  defaultFromName: 'Example',
  transportOptions: {
    host: process.env.SMTP_HOST,
    port: 587,
    auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },
  },
})
// TS2345: 'auth' does not exist in type 'SMTPConnectionOptions'

nodemailer 10's only listed breaking change is "Node.js 20 or newer". Would you take a PR that bumps the dependency and types transportOptions as SMTPTransport.Options, or is there a reason to stay on 9.x?

[iamsurajchahar]

Can't speak for the team on the PR itself, but a few things that should help.

The last nodemailer bump (^9.0.1 → ^9.1.1, #18158, merged mid-September) was done precisely to clear the early-September advisories, so a follow-up for the late-September ones is in line with what they've been doing. The list is slightly longer than the three you found: GHSA-prgh-xp8r-p3m5 (addressparser O(n²), fixed in 10.0.5) and GHSA-8vvx-rff5-p5rq (nested recipient arrays, fixed in 10.0.2) also only have fixes in 10.x. All of them are covered by 10.1.1.

On the types, your diagnosis is right and SMTPTransport.Options is the correct target in both worlds. nodemailer 10 bundles its own declarations, and nodemailer/lib/smtp-transport there declares namespace SMTPTransport { export type Options = SMTPTransportOptions } specifically so the @types/nodemailer-style references keep working; SMTPTransportOptions extends SMTPConnectionOptions and adds auth. @types/nodemailer has the same SMTPTransport.Options, so the change compiles against 9 and 10, and @types/nodemailer can be dropped from devDependencies once on 10. It's a two-line change in packages/email-nodemailer/src/index.ts:

import type SMTPTransport from 'nodemailer/lib/smtp-transport/index.js'
// ...
transportOptions?: SMTPTransport.Options

Until that lands you don't have to fight the types at all: the adapter also takes a ready-made transport, and that path never touches SMTPConnection.Options. Keep your resolution so there's a single nodemailer 10 in the tree, then:

import nodemailer from 'nodemailer'
import { nodemailerAdapter } from '@payloadcms/email-nodemailer'

email: nodemailerAdapter({
  defaultFromAddress: 'noreply@example.com',
  defaultFromName: 'Example',
  transport: nodemailer.createTransport({
    host: process.env.SMTP_HOST,
    port: 587,
    auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },
  }),
})

createTransport is typed by nodemailer 10 itself, so auth is accepted, and because the adapter resolves the same package, its Transporter type matches and no cast is needed. After that the adapter only calls transport.sendMail. The one runtime change to keep in mind is nodemailer 10's Node ≥ 20 requirement, which Payload already needs anyway.

[nathanlentz]

Thanks for raising this and providing the detailed write-up, and thanks @iamsurajchahar for the extra context and analysis. Both are correct.

We'll move @payloadcms/email-nodemailer to nodemailer 10 for both v4 and 3.x.

I'll get this taken care of!

[iamsurajchahar]

Thanks for raising this and providing the detailed write-up, and thanks @iamsurajchahar for the extra context and analysis. Both are correct.

We'll move @payloadcms/email-nodemailer to nodemailer 10 for both v4 and 3.x.

I'll get this taken care of!

Thanks Nathan. If it saves you time I'm happy to open the PR for the bump plus the SMTPTransport.Options type change against main and 3.x, otherwise I'll leave it with you.

[nathanlentz]

Updates for nodemailer have been merged for both v4 and 3.x! We'll get these released soon.

main: #18737
3.x: #18736

Thanks again for bringing this to us!

[iamsurajchahar]

Updates for nodemailer have been merged for both v4 and 3.x! We'll get these released soon.

main: #18737 3.x: #18736

Thanks again for bringing this to us!

Thanks for the quick turnaround, Nathan. Good to see #18736 / #18737 go with the SMTPTransport.Options change and drop @types/nodemailer, so transportOptions with auth just works on 10.

@admin-laicadev once the release is out you won't need the transport: workaround above any more. If one of the comments here answered your question, marking it would help others hitting the same advisories find this thread.

[admin-laicadev]

Great work, thanks @nathanlentz for the quick fix and @iamsurajchahar for the support and the explanation