31–40 of 75 posts
Earlier quoted context omitted.
> This service defaults to no authentication.
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...
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…
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!
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…
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.
Earlier quoted context omitted.
>SMTP has some back-and-forth stateful chatter. 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.
It's slower, which is important when you're trying to push a lot of emails. If you keep the TLS connection open, sending an HTTP request is very fast. Waiting for the roundtrips of that chatter reduces the throughput, especially on higher latency links.
I agree that for a high load of sending email it can be beneficial to use an intermediate service. IMO a local sendmail is still preferred, but I see your point.
However, the Mailit service makes the client wait on the SMTP traffic too [1]. So with this particular service you now have to wait for both SMTP /and/ HTTP communication. Doesn't really speed thinks up :)
[1] https://github.com/dthree/mailit/blob/master/src/routes.js#L...
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…
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.
Earlier quoted context omitted.
>SMTP has some back-and-forth stateful chatter. 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.
It's slower, which is important when you're trying to push a lot of emails. If you keep the TLS connection open, sending an HTTP request is very fast. Waiting for the roundtrips of that chatter reduces the throughput, especially on higher latency links.
So I can see the benefits of this approach
Earlier quoted context omitted.
It's slower, which is important when you're trying to push a lot of emails. If you keep the TLS connection open, sending an HTTP request is very fast. Waiting for the roundtrips of that chatter reduces the throughput, especially on higher latency links.
> If you keep the TLS connection open, sending an HTTP request is very fast. Waiting for the roundtrips of that chatter reduces the throughput, especially on higher latency links. I agree that for a high load of sending email it can be beneficial to use an intermediate service. IMO a local sendmail is still preferred, but I see your point. However, the Mailit service makes the client wait on the SMTP traffic too [1].…
That depends, you could host the Mailit service in the same machine as the email server, which your application instances on other machines would call. This could be useful if you have multiple machines but only want to run a single email server.
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…