Public discussion #245

EmDash

A discussion summary, not a made-up integration guide.

worker-mailer matters to the EmDash conversation because it already covers SMTP on Cloudflare Workers. What remains open is the shared provider contract around it. This page stays on that line.

What is already true

worker-mailer already brings a concrete SMTP transport to the table.

  • Cloudflare Workers SMTP transport exists today.
  • Queue helpers, hooks, CID images, and DSN are already part of the package API.
  • This makes worker-mailer a relevant transport candidate when CMS-side provider APIs mature.

What is still open

  • The exact provider lifecycle and registration surface in EmDash.
  • How transport-specific configuration should be modeled across different providers.
  • What should live in interception hooks versus provider-specific delivery hooks.
  • How observability and post-send behavior should be normalized across transports.

Pipeline ideas in the thread

beforeSend, deliver, afterSend

These stages summarize the shape of the public discussion, not a finalized contract. They are useful because they show where a transport like worker-mailer might fit.

email:intercept

beforeSend

The EmDash discussion describes a pre-delivery interception stage for validation, enrichment, or policy checks.

email:provide

deliver

A provider stage would choose the transport that actually sends the message, whether SMTP or something else.

email:send

afterSend

Post-delivery hooks would be the place for logging, analytics, follow-up automation, and result handling.

Transport status

What belongs to worker-mailer, and what does not

The distinction matters. This site can document worker-mailer accurately today, while leaving future provider work to future documentation.

SM

SMTP

Stable today

Available today with auth modes, HTML, attachments, CID images, DSN, hooks, and queue helpers.

RS

Resend

Under discussion

Not part of worker-mailer core. Any EmDash-facing provider shape is still under discussion.

PM

Postmark

Under discussion

Referenced only as a possible provider category in ecosystem planning, not as shipped functionality here.

SE

SES

Under discussion

Also in the future-facing conversation, but not documented as an implementation on this site.