Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

61–70 of 75 posts

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

#61

Post by vram22 »

vram22 wrote: post #43
laumars wrote: post #16

Earlier quoted context omitted.

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…

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…

>it's name was

Sorry, "its name was" :)

Still forget that rule sometimes.

http://data.grammarbook.com/blog/pronouns/1-grammar-error/

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

#62

Post by dc2 »

csomar wrote: post #33

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 experi…

Author here. There seems to be a lot of discussion over use cases. Here's the use case I built it for:

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.

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

#64

Post by Tepix »

kwhitefoot wrote: post #48

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.

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

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

#65

Post by mike-cardwell »

zAy0LfpBZLC8mAC wrote: post #45
mike-cardwell wrote: post #34

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.

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.

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.

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

#66

Post by zAy0LfpBZLC8mAC »

mike-cardwell wrote: post #65
zAy0LfpBZLC8mAC wrote: post #45

Earlier quoted context omitted.

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.

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.

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.

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

#67

Post by 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=&to=&to=
   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…)

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

#68

Post by GordonS »

lugg wrote: post #37
bjpbakker wrote: post #2

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…

> SMTP really is a very simple protocol, that's matured for decades now. Also it is fully specified by RFCs. 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.

Having an RFC hardly means it's not simple; it means it has a well-defined specification.

Do you actually think HTTP isn't specified in an RFC?

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

#69

Post by mike-cardwell »

zAy0LfpBZLC8mAC wrote: post #66
mike-cardwell wrote: post #65

Earlier quoted context omitted.

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.

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 th…

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.

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

#70

Post by robinj6 »

avenoir wrote: post #59
johns wrote: post #54

Earlier quoted context omitted.

Looks like it is using https://www.npmjs.com/package/swagpi

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

No, it's not. It's its own thing.
Post reply on HN