SMTP really is a very simple protocol, that's matured for decades now. Also it is fully specified by RFCs.
I can see why mail services that provide templating (eg Mandrill) have special APIs, they offer something different from sending regular emails.
This specific REST API seems more like a standin for sendmail, which IMO makes things only more complicated.
So what ? Is not like you implement the SMTP protocol into your application to send emails. Any language under the sun has a SMTP implementation exposed as a library.
Creating the relay is the hard part of any mail service because even SMTP aside, you need to set DNS entries on your FROM domain to authorise your SMTP relay's IP (otherwise spam filters will just block your email). And if it's regular commercial mailshots then you'd need to register with one of the trusted services (which isn't free) and have all sorts of controls like rate limiting in place - again so you don't just get rejected as spam.
Honestly, I would welcome a complete ground up re-implementation of email - SMTP, POP/IMAP and all. The "very simple protocol, that's matured for decades now" is really just a mess of different protocols - different authentication models, different encryption methods, etc and all operating without a standard format for error handling. Plus all of the additional bloat bolted on to handle the swell of abuse that the email "network" has had to endure. There's nothing simple about email any more.
However going back to the topic: the unfortunate thing about this REST API is it seeks to solve the least complicated part of the whole SMTP stack.
[0] https://documentation.mailgun.com/en/latest/quickstart-sendi...
Using an HTTP API for this is a massive overkill.
* I'm aware using utf-8 like this may confuse older clients but I didn't have problem with anything relatively modern I tested the receiving on.
In general I agree that I'm not seeing a big advantage in having another service to keep up and maintain, just to wrap SMTP.
So simple and so mature it needs an RFC.
I'll take the http API I can figure out in 10 seconds because I make API requests all day over some ancient tech I don't even want to begin to understand.
Does that make me lazy and a shit developer? Probably. Do I care. Definitely not.
Do you actually think HTTP isn't specified in an RFC?
[1] https://www.bleepingcomputer.com/news/security/mongodb-apoca...
[1] https://github.com/dthree/mailit/blob/master/readme.md#passi...
Let's say you want to build a first beta. You are going to use your own server for sending mail to reduce costs and also not introduce dependencies early on.
There are two ways to do it:
1. Call the SMTP library like some here suggested.
2. Create your own encapsulation of the SMTP functionality, and call these functions to send email.
It is obvious why you want to use 2. But, from experience, it makes your code base bigger and debugging more problematic.
By using a Docker container, you are separating matters: Now sending emails is a small service that can scale in the future, but doesn't consume lots of resources today.
With a docker/rest api, it also means that have you decided to switch to Mailchimp in the future; it'll be an easy task. You don't have to go through all your code and look which parts send emails and update them. You don't have to update your library encapsulation. You don't have to redeploy your whole instance to update the code.
All you do is create a new docker instance and then shutdown the old one. Tada!
Instead configure a local sendmail (so you have all the benefits of local mail delivery, like queuing and availability so on) to relay through your provider's mail servers.
Instead it takes your existing SMTP settings, so you can take the advantage of your existing reputation, or your provider's one.
(assuming you already have an email account somewhere, and it can be gmail, outlook, [popularprovider]...)
All traffic for my (large) application hits a load balanced API gateway. Its role is to authenticate and forward requests to one of many services.
The gateway is the only point of exposure to internal services. After something has cleared the gateway on a route with roles approved for that user, there is little worry about security. Certificates between servers and containerized deployments such as Kubernetes help on this as well.
I'm not going to write email-sending logic in my gateway. It just handles AAA and then proxies the request.
By forwarding to microservices instead of a monolith, I can scale workload better and have less risk of a mail bug taking down other services.
Regardless, that's why I said it should be configurable.
A sendmail replacement that can call a REST / Webhook endpoint. You'll get free alerting directly from crontab/smartd/zfs to your monitoring / logging system
But curl can already send email through SMTP directly.
I'm sure the author has a good reason for creating this but it needs a better example.
To essentially every email endpoint in the world, I always end up wondering: why is there not just an endpoint:
POST /email?from=<sender>&to=<recipient1>&to=<recipient2>
Content-Type: message/rfc822
… the actual email to send, encoded according to RFC 822. I.e., an email.
(Of course, this starts to very much resembled SMTP. I'm frankly okay with the above: I have tons of readily available tooling for HTTP, and I understand how TLS works and doesn't with it. But I do also understand why some might balk at this with a "that's just SMTP!")
(And just to note: I don't want to trivialize building an email. Email's format is super complex. But I have in my standard library a module that handles that for me…)
I would think that this is bad design - call a http service that wraps smtp, when pretty much every language has an SMTP client.
I worked for 2 years on a monolith that used to call SMTP directly and it was a pain to debug.