Public discussion #245
EmDash
Sandbox-ready bundles, plus the discussion context.
worker-mailer matters to the EmDash conversation because SMTP and Resend already run on Cloudflare Workers. The sandbox bundles exist today; the shared provider contract is still evolving. This page keeps those two realities separate.
What is already true
worker-mailer already ships concrete SMTP and Resend transports.
- Cloudflare Workers SMTP transport exists today.
- Resend delivery ships as a Worker-native API client.
- Queue helpers, hooks, CID images, and DSN are already part of the SMTP package API.
- Sandbox bundles exist for both transports so teams can test now.
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 ships now versus what is still being debated
The distinction matters. This site documents what ships today while the EmDash contract matures in public.
SMTP
Stable today
Available today with auth modes, HTML, attachments, CID images, DSN, hooks, and queue helpers.
Resend
Stable today
Available today as a separate Worker-native package aligned to the SMTP API surface.
Postmark
Under discussion
Referenced only as a possible provider category in ecosystem planning, not as shipped functionality here.
SES
Under discussion
Also in the future-facing conversation, but not documented as an implementation on this site.