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

71–75 of 75 posts

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

#71

Post by [deleted] »

icebraining wrote: post #27
mariusmg wrote: post #23

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.

[deleted]

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

#72

Post by zAy0LfpBZLC8mAC »

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

Earlier quoted context omitted.

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…

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.

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

#73

Post by mike-cardwell »

zAy0LfpBZLC8mAC wrote: post #72
mike-cardwell wrote: post #69

Earlier quoted context omitted.

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…

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

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.

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

#74

Post by BrandoElFollito »

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…

For instance to send messages from client only web applications where the only thing you have is an AJAX call.

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

#75

Post by Michielvv »

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…

In our case the reason we switched from SMTP to an HTTP API was mostly speed. At least for Sendgrid, their HTTP API is much faster than SMTP.

In general I agree that I'm not seeing a big advantage in having another service to keep up and maintain, just to wrap SMTP.

Post reply on HN