Although I truly think this is a fantastic product, both in the simplicity of the offering and the simplicity of the API, I was a little concerned about being able to use my own domain and phone number when sending messages, for the sake of building trust with my users. Also, I (selfishly, perhaps) have more faith in the reliability of an established service than something recently launched.
For anyone who has similar concerns and wants to use something more customizable and reliable like Mailgun/Twilio, but wants access to the same elegant API showcased here, you can use something like this (admittedly naive) implementation:
const mailgun = require('mailgun-js')({apiKey: api_key, domain: domain});
const twilio = new require('twilio')(accountSid, authToken);
export default function notify (to, msg, options) {
if (Array.isArray(to)) {
to.forEach((toSingle) => notify(toSingle, msg, options));
return;
}
if (to.includes("@")) {
mailgun.messages().send({
from: 'Your name <yourname@example.com>', // your email
to: to,
subject: options && options.subject,
text: msg
});
} else {
twilioClient.messages.create({
body: msg,
to: to,
from: '+5555555555' // your number
});
}
}
This implementation wouldn't require that much extra effort to set up initially (i.e. signing up for two API credentials instead of one and installing two packages instead of one), but it gives you a lot more flexibility to configure the from address and phone number and might help you sleep easier at night.
However, as a fellow startup founder, I think it's noble to support newer projects like this. As such, I've signed up for an account and plan to test it out for at least a month.
Yeah, you are probably not the target market for this lovely hobby project. Email service reliability matters, and is a very difficult problem at scale. This is why my team has been working on a production-ready, enterprise version of a unified email API for about a year now, that's free for up to 100k messages/month, and has functionality that you couldn't easily build yourself, like auto-failover over multiple providers, full-text elasticsearch of your email history/logs, and a non-technical interface for your customer support team to easily view your recipients email history.
Send me a tweet @flutemail if you're interested, I'll let you know when it's ready (should be in about a month).
> Also, I (selfishly, perhaps) have more faith in the reliability of an established service than something recently launched.
This was my thought as well. I've had a number of projects where I had to deliver large numbers of emails and SMS and the problem has never been the design of the API I used to send them. It's always about the delivery rates of those messages. Particularly with SMS we've had to be very careful with our providers, often needing to select a different one in different countries.
It's basically 10x what Mailgun charges, which is pretty reasonable overhead imo. $10 to send 1,000 email notifications to your team is peanuts. People will 100% pay that.
Beacause these types of services go to great effort to keep their repuation high on email services. You use these services so your 1000's emails get delivered instead of being rated as spam or being blacklisted.
My self-run mail server I set up before I had any sysadmin knowledge also has high reputation, isn’t on any blacklist, and successfully is rated non-spam by Gmail, Yahoo, Outlook and all others.
Is there something special why you’d need to pay for a product such as mailgun, and not just something like the ISPmail guide suggests?
Both for small bootstrapped projects, and for larger companies it should be cheaper to just run it yourself.
> My self-run mail server I set up before I had any sysadmin knowledge also has high reputation, isn’t on any blacklist, and successfully is rated non-spam by Gmail, Yahoo, Outlook and all others.
That is most definitely not the norm. Entire ISPs get blacklisted on a regular basis, working around that is difficult.
There are a lot of hurdles to hosting an email service, and some of them are geographic, and out of your immediate control.
If things are difficult... Why wouldn't you pay to make the hassles go away all together?
Hm, I’ve just never actually seen that. I started out with the ispmail guide plus SPF/DKIM/DMARC tutorial from linode and DO, and applies those on my cheap server. Just worked, never had issues (and this is the fifth server already, previously I’ve been with OVH, Hetzner, Online.net and KimSufi).
It’s just, I can’t believe that it’s just luck that I never had these issues. Is it luck? Is it because people try configuring email without such tutorials (which actually would be quite complicated)? Is it because people with no devops experience try it?
On the other hand, if a devops engineer can set it up in a day, it’ll cost you ~270€ (taking a usual European salary for such a person), which would you get 27000 emails with this service. So it might actually be worth it.
I’m curious what sort of email you’re sending and at what volume. Depending on the use case, it may be easy to start clean, but if you’re sending millions of emails a day, you may find it difficult to keep that clean reputation.
It’s certainly not impossible but takes more work as you scale up. I think that’s part of the attraction of these services. Pay for it to be their problem (in theory anyway) :)
Because we live in a world where most people use large E-Mail services like Gmail. And those providers don't know how to filter spam from your inbox. So they decided to blacklist IPs and IP ranges (if they have bad reputation, which is a completely intransparent metric), so people are now forced to pay services like Sendgrid or Mailchimp to get their E-Mail in those mailboxes.
Funny part is, that Google has all the best ML engineers working for them, yet they seem to be unable to check a mail for spam... They can teach a computer to play Go at superhuman level yet they are not able to check an E-Mail for the words Viagra and Cialis.
I would argue that they work a bit too aggressively and are also not intelligent as one would expect or assume them to be. I only have anecdotes here. I've seen instances where one personal email sent from Gmail's web interface is in the spam folder of the receiver. Sending emails to Google Groups subscribers also doesn't get delivered to the inbox several times (even when the receiver has never marked it as spam).
With many people using smartphones to check email, my guess is that only a very small percentage of people still check their spam folders regularly to see if there were any false positives and help train the spam filter (to the extent it's willing to learn). Most people only check their inboxes (and many may not even know about a slam folder), and I'm sure there are billions of harmless and expected emails around the world that just got lost because of these filters.
I'd argue, something like Mailgun/SendGrid/alikes are not really better than e.g. my home mail server. I mean, both land in spam at random and there is literally nothing one can do about it, except trying to randomly tinker with things (message content and headers, or, maybe, change IPs) in hope it will somehow help.
I'd argue having a home mail server is nothing like sending email for a business.
If your business sends out any kind of transactional emails, the Junkie McJunkbuttons of the interwebs will trash your domain and IP reputation because they use the Junk button as the Delete button.
Why does this matter? Please, let me invite you in to this rabbit hole. What I say here is based on information my best friend, who is an engineer working on email transport for a national ISP. And let me tell you, blacklists like Spamhaus, SORBS, etc. and code like SpamAssassin are the Tonka toys of spam filtering.
1. The storage for their mail system is close to 1PB of usable storage via RAID 60 storage modules in their SAN. It's a lot of drives. A lot of Enterprise-class, high RPM, expensive drives.
2. The SAN stores about 3% of all email they receive. This is not because their users are all about Inbox Zero. No, this is because they route ~97% of their received email straight into the bit bucket. Because it is clearly SPAM. Think about that 1PB of storage being multiplied to 33PB just because SPAMmers want to send email. Think about even larger ISP/ESPs that operate at much larger scale and face 97% influx of utter crap.
3. Keeping up with the constantly-evolving threat models used by SPAMmers is too much for just about any engineering team that wants to get some real work done, so they outsource the filtering. These are companies like CloudMark and Symantec to name a couple. They provide APIs where you send an email, and they return an extensive SPAMminess profile for that message. They are the Caterpillar 797F's of SPAM filtering. These companies are used by numerous other companies, so SPAM reported at one customer site aids detection at all customer sites. BTW, they have no page to log in where you can request removal from their blacklist.
4. Since false positives on classifying mail as Junk (the Junk that actually gets to the Junk box) is a huge drain on support resources, they decided to employ two such companies from the Email Filtering Industry. This is because they get different profiles from each company. They glued the two results together in multivariate tests until they found the right formula to significantly reduce the "SPAM False Positive" type of support inquiry.
5. When someone hits the Junk button in their webmail client, the ISP reports that email to both of their Email Filtering partners.
These filtering companies can extrapolate the volume of email your domain sends because they see those emails as they are received by their customers. They can also track how many times a user reports it as SPAM. A few SPAM reports won't hurt your domain/IP reputation, but once you hit a certain threshold, you're blacklisted across all their customers.
So what Mailgun or SendGrid can do for a customer in this ecosphere is use their relationships with the CloudMarks and Symantecs of the world. And gain some forbearance to to de-blacklist customers who are sending legit email, or who suffered an incident and were exploited by SPAMmers. I've witnessed this happening on the ConvertKit Facebook group multiple times. A marketer posts that suddenly their emails aren't reaching their canary accounts, say at Gmail. CK support gets in and says they'll contact their email provider. A day later, problem resolved and said marketer reports their mails being delivered again.
So where does Junkie McJunkbutton come in to all of this? Well, they are usually non-hostile people who don't understand the implications of hitting the Junk Button. That they are essentially reporting a bad faith email event to the "Equifaxes of the email world" about you.
PS Junkie McJunkbutton + going it alone for email transport is what will kill PopcornNotify and similar solutions.
Hi FriedPickles,
Great product first of all, liked the simplicity of the product, I am also working on somewhat similar product, https://ingwe.io . I am planning to launch on hn in couple of days, best of luck :)
To those less familiar with email standards.. this means the 3rd party service send grid are the ones actually sending mail on their behalf.
More specifically, SPF exists for a domain owner (in this case, popcornnotify.com) to specify who is authorized to send mail on behalf of the host email.popcornnotify.com. This is set in a DNS record and used by spam filters to prevent spoofing and such.
Really like the simplicity of the project, well executed ! Good luck with it and I hope that you will resist any feature requests which will turn the product into another Mailgun/ Twilio etc.
I think this is a nice idea, but I'm worried about the, let's be honest, needless single point of failure this adds to my architecture. Nothing this does ought to be more than a 100 line open source project (which is not criticism btw - if you can monetize a tiny codebase, more power to you!). But because it's SaaS, you need to depend on someone else to keep their service up and running.
Because of that simple reason, I'd only use this for optional stuff, but I struggle to think of a use case where notifications are optional.
ps. that said, this is a very attractive service to send SMS to Europe. I know of no service that undercuts $0.10 per SMS to European countries unless you buy in huge bulks.
The monthly cost of a number with plivo seems a bit higher, overall, but also looks like they have free incoming SMS, which may end up being a much better deal for some use cases.
For anyone who has similar concerns and wants to use something more customizable and reliable like Mailgun/Twilio, but wants access to the same elegant API showcased here, you can use something like this (admittedly naive) implementation:
This implementation wouldn't require that much extra effort to set up initially (i.e. signing up for two API credentials instead of one and installing two packages instead of one), but it gives you a lot more flexibility to configure the from address and phone number and might help you sleep easier at night.However, as a fellow startup founder, I think it's noble to support newer projects like this. As such, I've signed up for an account and plan to test it out for at least a month.