Email, decoupled from where and how: A cross-runtime, cross-provider email library for JS & TS
3 points by hongminhee
3 points by hongminhee
I really hate that libraries like this exist. A "cross-provider email library" for the purpose of sending email should just be an SMTP library, not a collection of provider-specific clients. (Yes, this is the fault of the providers.)
I think the core complaint is fair. In an ideal world, sending an email would just mean speaking SMTP to whichever server is willing to relay it, and having a dozen incompatible HTTP APIs for what's fundamentally the same operation is a real cost the industry mostly brought on itself.
One thing worth adding, though: in the part of the JavaScript ecosystem where edge runtimes have become common (Cloudflare Workers, Vercel Edge Functions, and similar), SMTP runs into trouble that goes beyond it just being “another protocol.” Sending a single message means a TCP handshake, EHLO, often STARTTLS, AUTH, MAIL FROM, RCPT TO, and DATA: at minimum five or six sequential round trips, even to a cooperative server. A server that tarpits or greylists, which is common enough as an anti-spam measure, pushes that count up unpredictably. All of it has to fit inside a single request's execution budget, and edge runtimes are built around short, bounded requests.
It's also not just a matter of degree. A fair number of edge runtimes don't expose a TCP socket API at all, only fetch(). Where one does exist, like Cloudflare's connect(), there's still no way to keep a connection open across separate invocations, so every send pays the full handshake cost from scratch.
None of that argues against the general point. It just seems like “SMTP is enough” runs into a fairly specific wall on that class of runtime, and that's probably a real, if narrow, reason this kind of fragmentation exists.
A server that tarpits or greylists, which is common enough as an anti-spam measure
It’s super important to make a distinction between different SMTP server roles. The two main ones are public MX target (which has to have lots of anti-spam measures) and message submission server (which should be fast and focus its anti-abuse measures on the AUTH command). [There’s a third older “smarthost” role which is like a message submission server but traditionally used IP-based authorization instead of the AUTH command.]
If you are operating a message submission client (or a dumb SMTP client that needs a smarthost) your software should never be talking directly to an MX server. If the server is subjecting your client to tarpitting or other anti-spam measures then something is misconfigured.
That's a fair correction. I'll take back the tarpitting/greylisting example specifically, that's an MX-role concern and shouldn't apply to a submission server talking to an already-authenticated client.
The round-trip count and the runtime-level points from my earlier comment still stand though.