
Mailit: A Tiny Drop-In REST API to Send Emails - robinj6
https://github.com/dthree/mailit
======
csomar
I really like this approach.

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!

~~~
bjpbakker
For a first beta (MVP?) I would strongly advice against using your own mail
server. It takes a while for a server to build up a reputation, hence mails
from an "unknown" server are quicker marked as spam (especially by common
services like gmail and outlook).

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.

~~~
askz
MailIt doesn't provide a SMTP server.

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]...)

------
bjpbakker
It migt be just me, but I honestly don't understand why people would use an
HTTP API to send mail.

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.

~~~
kowdermeister
I've looked at setting up sendmail as a "LAMP guy" and I said nope nope nope,
just use mailgun.

~~~
laumars
You still need to set up the SMTP server with this solution.

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.

~~~
vram22
Yes, good point about email being complex to implement - both the server and
the clients that use it. Example: Some years back, I remember reading a book
(I think from O'Reilly) about using programming email, by an author called
David Wood [1].

Update: I just did this google search:

java and email book david wood

and looked at the results.

The first hit is that book - it's name was actually Programming Internet Email
- and it was by O'Reilly Media:

[http://shop.oreilly.com/product/9781565924796.do](http://shop.oreilly.com/product/9781565924796.do)

It has info on both the fundamental concepts and protocols of email, as well
as examples in both Perl and Java.

Other results of that search show that there are multiple books about
programming email (as can be expected), including a list of books about
Internet email on an Oracle site:

Books on the JavaMail API and Internet Mail:

[http://www.oracle.com/technetwork/java/javamail/index-139773...](http://www.oracle.com/technetwork/java/javamail/index-139773.html)

Not all of those are exclusively about email, and some probably have
overlapping content, but still, it shows (as Wood's book did too) that it is a
big topic:

JavaMail API, by Elliotte Rusty Harold.

Internet Email, by David Wood.

Programmer's Guide to Internet Mail, by John Rhoton.

Internet Email Protocols: A Developer's Guide, by Kevin Johnson.

Java Network Programming, 2nd Edition, by Elliotte Rusty Harold.

Essential Email Standards: RFCs and Protocols Made Practical, by Pete Loshin.

Internet Messaging: From the Desktop to the Enterprise, by Marshall T. Rose
and David Strom.

Internet E-Mail: Protocols, Standards, & Implementation, by Lawrence Hughes.

Managing IMAP, by Dianna Mullet and Kevin Mullet.

Professional Java Server Programming J2EE Edition.

Java Cookbook: Solutions and Examples for Java Developers, by Ian F. Darwin.

JavaServer Pages (JSP) Fast & Easy Web Development, by Aneesha Bakharia.

[1] From what I read about David Wood, he seemed to have a lot of experience
with email (and other stuff) and had for some time, a company providing
products and/or services in that area.

[http://www.oreilly.com/pub/au/565](http://www.oreilly.com/pub/au/565)

And that Java Cookbook by Ian Darwin is pretty good too - I have it.

~~~
vram22
>it's name was

Sorry, "its name was" :)

Still forget that rule sometimes.

[http://data.grammarbook.com/blog/pronouns/1-grammar-
error/](http://data.grammarbook.com/blog/pronouns/1-grammar-error/)

------
thesorrow
The total opposite of this project would be way more useful :

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

~~~
beagle3
Kenneth Reitz's inbox.py does 99% of that for you. Just add a call to requests
(also by reitz) and you are good.

------
deathanatos
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?

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.
    

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.

(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…)

------
kwhitefoot
The example in the readme uses curl to send an email.

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.

~~~
Tepix
Good catch. I suppose it's because curl seems to be the standard tool when
showing an example for a REST API.

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

~~~
carl_dr
> This service defaults to no authentication.

~~~
beefhash
That default really did not work out well for MongoDB[1]. Why are we
perpetuating this mistake?

[1] [https://www.bleepingcomputer.com/news/security/mongodb-
apoca...](https://www.bleepingcomputer.com/news/security/mongodb-apocalypse-
professional-ransomware-group-gets-involved-infections-reach-28k-servers/)

~~~
e12e
Perhaps, more importantly, that didn't work out very well for smtp either ;
aka "open relay".

------
azifali
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.

I would think that this is bad design - call a http service that wraps smtp,
when pretty much every language has an SMTP client.

------
chrismatheson
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.

------
mike-cardwell
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.

~~~
zAy0LfpBZLC8mAC
The latter is a terrible idea: Mail servers as well as networks can and do
fail temporarily, that should not prevent you from sending emails to addresses
hosted on those servers, that is exactly what MTA queuing is there for.

~~~
mike-cardwell
I'm not going to make assumptions about other peoples use cases. If your use
case demands that an email be immediately accepted, then the idea is not
necessarily terrible.

Regardless, that's why I said it should be configurable.

~~~
zAy0LfpBZLC8mAC
But it doesn't give you that guarantee. Just because you can connect now, does
not mean you can actually send an email later, let alone that particular
email. If you want that, then you should provide feedback whether the email
that you want to send actually was accepted by the destination server. But
even that is probably not a sensible idea: Just because the MX accepted the
messages does not in any way guarantee that it will actually be delivered
immediately.

~~~
mike-cardwell
Nothing you've said is non-obvious. What if the thing you want to do is not
"send an email", but is: "test if an address is likely to be able to receive
an email". Could you conceive of a scenario where a message pops up to a user
stating:

"It looks like you may have entered your email address incorrectly. Are you
sure it is ok?"

I'm sure there are lots of use cases. Just because you can't think of one does
not mean that none exist.

~~~
zAy0LfpBZLC8mAC
Except that I have seen way too many incompetent uses of APIs that support bad
ideas, and so, in reality, everyone would use "the best setting!", aka, all
validations switched on, and thus probably lead to all kinds of false
positives with hard rejects. See also the common rejection of +-suffix
addresses, for example.

For address validation, connection checks are a bad idea. For address
validation, turning any temporary failure into something that could end up as
a hard reject is a bad idea.

~~~
mike-cardwell
I'm not a fan of leaving out useful features because bad developers don't
RTFM. This is all hypothetical though. I don't personally need the feature, it
was just an idea.

------
blablubbla
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).

[1]
[https://gitHub.com/lindenbaum/http2smtp](https://gitHub.com/lindenbaum/http2smtp)

------
bmn__
There are no hypermedia controls. This isn't REST, merely HTTP (with tight and
brittle coupling).

------
jitix
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.

I worked for 2 years on a monolith that used to call SMTP directly and it was
a pain to debug.

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

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

~~~
johns
Looks like it is using
[https://www.npmjs.com/package/swagpi](https://www.npmjs.com/package/swagpi)

~~~
avenoir
Err.. Didn't bother to check dependencies. So this is just a UI generated on
top of swagger. Thanks for pointing that out :)

~~~
robinj6
No, it's not. It's its own thing.

------
homero
Like a reverse ssmtp?

