Mailit: A Tiny Drop-In REST API to Send Emails

I really like this approach.<p>Let&#x27;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&#x27;t consume lots of resources today.<p>With a docker&#x2F;rest api, it also means that have you decided to switch to Mailchimp in the future; it&#x27;ll be an easy task. You don&#x27;t have to go through all your code and look which parts send emails and update them. You don&#x27;t have to update your library encapsulation. You don&#x27;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&#x27;t understand why people would use an HTTP API to send mail.<p>SMTP really is a very simple protocol, that&#x27;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 &#x2F; Webhook endpoint. You&#x27;ll get free alerting directly from crontab&#x2F;smartd&#x2F;zfs to your monitoring &#x2F; logging system

I&#x27;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 &#x2F;email?from=&lt;sender&gt;&amp;to=&lt;recipient1&gt;&amp;to=&lt;recipient2&gt; Content-Type: message&#x2F;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&#x27;m fine with simple helper methods like those offered, but once things reach their inevitable complexity (because lets face it, I&#x27;m sending an email designed by marketing. It&#x27;s got tons of inline images and shiny design stuff…, and maybe an attachment) I really just want a &quot;transmit this email to these people&quot; endpoint.<p>(Of course, this starts to very much resembled SMTP. I&#x27;m frankly okay with the above: I have tons of readily available tooling for HTTP, and I understand how TLS works and doesn&#x27;t with it. But I do also understand why some might balk at this with a &quot;that&#x27;s just SMTP!&quot;)<p>(And just to note: I don&#x27;t want to trivialize building an email. Email&#x27;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&#x27;m sure the author has a good reason for creating this but it needs a better example.

Is this authless? You just send mail as the account configured and anyone can send mail?

I wouldn&#x27;t add another HTTP layer for a functionality that is within my own app &#x2F; 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 &quot;drop in&quot; API&#x27;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&#x2F;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:&#x2F;&#x2F;gitHub.com&#x2F;lindenbaum&#x2F;http2smtp" rel="nofollow">https:&#x2F;&#x2F;gitHub.com&#x2F;lindenbaum&#x2F;http2smtp</a>

There are no hypermedia controls. This isn&#x27;t REST, merely HTTP (with tight and brittle coupling).

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.

Built this for a hackathon the other day. The ability to send email attachments is a must.

Is there some kind of a template out there to create the API documentation used by this project?

Like a reverse ssmtp?