I really like this approach.<p>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.<p>There are two ways to do it:<p>1. Call the SMTP library like some here suggested.<p>2. Create your own encapsulation of the SMTP functionality, and call these functions to send email.<p>It is obvious why you want to use 2. But, from experience, it makes your code base bigger and debugging more problematic.<p>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.<p>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.<p>All you do is create a new docker instance and then shutdown the old one. Tada!
It migt be just me, but I honestly don't understand why people would use an HTTP API to send mail.<p>SMTP really is a very simple protocol, that's matured for decades now. Also it is fully specified by RFCs.<p>I can see why mail services that provide templating (eg Mandrill) have special APIs, they offer something different from sending regular emails.<p>This specific REST API seems more like a standin for sendmail, which IMO makes things only more complicated.
The total opposite of this project would be way more useful :<p>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
I've worked with APIs like this. The email gets more complicated, and inevitably, the API starts breaking down. E.g., with this API, how do I send attachments?<p>To essentially every email endpoint in the world, I always end up wondering: why is there not just an endpoint:<p><pre><code> 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.
</code></pre>
i.e., these endpoints conflate two tasks: building the email and transmitting the email. I'm fine with simple helper methods like those offered, but once things reach their inevitable complexity (because lets face it, I'm sending an email designed by marketing. It's got tons of inline images and shiny design stuff…, and maybe an attachment) I really just want a "transmit this email to these people" endpoint.<p>(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!")<p>(And just to note: I don't want to trivialize building an email. Email's format is <i>super</i> complex. But I have in my standard library a module that handles that for me…)
The example in the readme uses curl to send an email.<p>But curl can already send email through SMTP directly.<p>I'm sure the author has a good reason for creating this but it needs a better example.
I wouldn't add another HTTP layer for a functionality that is within my own app / network, unless I were to expose this as a service for outside the network as a service.<p>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 really like this library (from a conceptual level) id love to see more "drop in" API's, rather than proxying to a bunch of other services.
Could do with an end-point to do some basic validation of email addresses. I.e a syntax check, and also a DNS check to make sure that the domain has MX or A/AAAA records, and potentially a check to make sure that there is an SMTP server listening at the destination on port 25. Perhaps all 3 of those things configurable at request time.
We wrote a similar service in Erlang [1] which is used for bug reporting of client side software (since most corporate networks block outgoing SMTP).<p>[1] <a href="https://gitHub.com/lindenbaum/http2smtp" rel="nofollow">https://gitHub.com/lindenbaum/http2smtp</a>
Love the idea.. although we can call SMTP directly, having the SMTP APIs encapsulated with a HTTP interface is pretty neat. Plus its a readymade microservice that you just spin up and use.<p>I worked for 2 years on a monolith that used to call SMTP directly and it was a pain to debug.