Great discussion here, not necessarily about the OP's link, but still learned a lot. Would love to contribute my 2 cents...
Our app[1] sends/receives several million emails per month. Not an exaggeration, it's actually seven figures.
Meaning it's more than 100k a day. Meaning it's 5-6 emails every friggin second. On average. It, of course, peaks during US daytime, up to 30 per second.
We tried a looooh-ot of solutions (all priced at THOUSANDS a month at this volume) including Mailgun, Sendgrid, SES etc, but finally settled to a tiny Ubuntu micro-instance on EC2, running Postfix. It has 1 gb of memory, costs us $4 a month and the CPU load rarely goes higher than 4%.
Of course you would need to get yourself familiar with SMTP, postfix, SPF/DKIM, mx-validation, blacklists etc. And by "familiar" I mean "learn it tothe core" :))
Another thing - you need to build-up reputation for your IP, cause email providers like outlook/gmail/yahoo will simply reject your emails if you start sending a LOT out of the blue. You have to build it up gradually, takes months to get there. Makes it a huge PITA when you need to change your IP :((
PS. If you need incoming email to call some external REST-api - postfix can launch a local php-script that does that. Not sexy but - $4 a month, right.
So firstly, I don't work for AWS or Amazon, or any Cloud provider. Just wanted to make sure that was clear.
After reading your very interesting comment I thought I'd do some maths on the costs SES should be charging you. Essentially at $0.10 per 1,000 messages, and sending "several million" or "seven figures" worth of messages per month, so a possible total of 9,999,999, you should be paying almost exactly $1,000 for that. That's not really "THOUSANDS", but it is substantially more than $4 haha :)
If you're sending 5,000,000, then the figured drops to $500/month.
Anyway your $4/month server is a very cool concept. Would you be willing to share the configuration? Perhaps you've written an Ansible Playbook to provision it for you?
EDIT: So essentially my point is this: it's not that expensive, compared to compute resources to actually run your application, to have someone else manage all of that for you.
> Developing and managing your own system, like the OP did, takes a lot of time and energy - all of that, when calculated, costs a lot more :)
> costs a lot more
> costs a lot more
> costs a lot more
The point was super clear, and yet you managed to miss it.
@jitbit clearly stated that he and his colleagues evaluated several possibilities, and the decided to set up their own system.
It's literally short-term decision: it's a make-or-buy problem.
The make options surely takes some time, but it is a one-time expense with pretty much low maintenance and super-low operating-cost ($4/month). It also requires some study but hey, that's know-how that is going to stay in the company.
The buy options is a lot more costly, but gives the gift of ignorance: you are not required to know or do anything.
And if you are wondering what the costs are: setting up a basic mail server for a domain takes as little as a couple of hours. A little-more complicated might take a day, and a complex setup not more than a week, for a skilled person.
Considering other options, it might just be cost-effective to hire a consultant to set it up.
Source: i've been running my mailserver for years, and I've done consulting in setting up and troubleshooting mail servers.
you would need to get yourself familiar with SMTP, postfix, SPF/DKIM, mx-validation, blacklists etc. And by "familiar" I mean "learn it tothe core"
Why? Wouldn't the "proper" or "best" way of configuring all these things be pretty much the same for everyone? Why could this just not be a receipe: do all these things, in this order, etc.
I don't know anything about this space, but I strongly suspect the generic answer applies: because you need to be able to debug the system when things go wrong. Things always go wrong, and no recipe can replace expertise when they do.
As OP said, there are also things to consider, such as IP reputation, etc... I've done higher volume mailing from a tiny server just like OP, but we also had a couple huge slices of a /24 and pile of /16 net blocks GRE tunneled and used different blocks of addresses for different types of mail. It's not as simple as just setting this up and forgetting it, there's a good bit of arcane knowledge required to do it right. If you're sending millions of messages per day, you cannot afford to burn a bunch of IP addresses because you triggered grey/blacklists for major ISPs or email providers. Shit, these days, you can't afford to burn IP addresses, period. They are officially exhausted. If you HAVE to hit a user's inbox, you can assuredly afford to spend a few grand setting it up right, and then reap the rewards for months/years afterwards for very little recurring cost. Just my two cents, as someone who built a single server to send millions of messages per day.
Well, there ARE recipes indeed, but sometimes people (legitimate people, not spammers) have their email settings misconfigured and you have to fix things...
Example: good practice is to reject (or at least defer) an email if the sending server is not listed in the domain's SPF record. But lots of people are sending email "on behalf" of gmail without even knowing it (when their mail-server forwards a gmail-message to another address, and this address never receives it).
There are tons of little gotchas like this that you need to look into :((
This is what I would do as well. Coming from a hosted mail solution (one of the earliest in the Industry as part a of the initial Dotcom bubble) that cost 10000x5+thensome as much to run, albeit with higher send rates and clusters, It totally makes sense to use ec2 for these needs today.
In the beginning I used to setup just personal "cloud", but now actually using it to send emails for other businesses I run.
In theory it should be possible to run these playbooks without all extras and just keep bare minimum to send emails (never tried it, so not sure what it will take)
Sovereign will configure postfix + dkim + spf + blacklists for you. Plus provides your imap mailboxes to receive bounces and regular mail.
Dumb question, can you reassign an already assigned public IP address to a different EC2 instance?
Let's say GP's micro instance goes down, or extra load brings the need for a larger instance, can they spin up a different EC2 instance and reassign the existing public IP address to it?
Absolutely, this is done on AWS with EIPs (elastic ip's). You can migrate an EIP between instances via the AWS API and the change takes effect nearly instantly.
This is a big reason for sure. As you can see in this post, those IP addresses can be hit or miss depending on the provider. At Postmark, we don't really believe in dedicated IPs for all customers. We think that our customer base should not include any bad actors, and instead manually approve every customer to ensure our entire CIDR ranges are clean. The benefit is not just clean IPs, but clean IPs that have an incredible transactional-only reputation with the ISPs. This is how we are able to delivery so fast to the inbox. We only really believe in dedicated IPs for higher volume senders, especially since reputation is moving toward the domain more and more. I wrote about this six years ago, and it is even more true today (https://postmarkapp.com/blog/the-false-promises-of-dedicated...).
At the same time, if you are willing to install and manage Postal on your own servers, it's not that hard to maintain your own IP with a great reputation. You just need a good hosting provider (probably not AWS), you need to set up your infrastructure like DKIM, SPF, DMARC, rDNS, and Return Paths, and most importantly you need to maintain good engagement (low bounces, high opens). At a glance, Postal looks like a nice option if you want to do it on your own for cheap. You just might lack the stability, support, maintenance, and performance that goes behind an ESP.
> manually approve every customer to ensure our entire CIDR ranges are clean
This is probably a key element of good performance. To keep my mail admin duties part time I simply whois the IP of evil senders and drop the resulting entire CIDR block into the our local blacklist.
Judging from the amount of it the sending email portion is not what spammers struggle with. It's the "maintain your own IP with a great reputation" part. How would Postal help?
That's apparently a process that takes time, but in the long run it could easily pay off. Over the years I've dealt with "Verio" selling my ip address to spammers. Before that they had entire ranges of IP blocked that I got caught up in.
A couple years ago I did the work to use "Mandrill" in an app and they got merged with "MailChimp" who changed how my app could use their service and I had to redo those routines again.
Well from the install directions they recommend 8GB of memory for the server. A simpler SMTP server like Postfix or Exim can do with much fewer resources, and a spam operation doesn't care about abiding by protocol for redelivery attempts, they just fire and forget and mostly opt for direct SMTP delivery.
I tried using Sendgrid and was surprised to find out that unless you buy an expensive plan, then:
* You get IPs from a shared pool, and the reputation is nowhere near guaranteed. In fact, many of my mails were blackholed or rejected.
* The "bad" IPs that were used by someone for spamming are not immediately removed from the pool, so you will encounter them.
The net result for me was that Sendgrid is not a solution for my transactional E-mail, because of the high risk of my E-mails getting blackholed/rejected. I use it for newsletters/marketing only.
I had exactly the same experience. For context I run a SaaS targetting small/medium businesses, who usually have in-house email servers with extremely restrictive spam filters. The IP was on a blacklist, so some of my customers just couldn't use my service. I contacted SendGrid and their only solution was to upgrade from a $20/mo plan to a $80/mo plan with a dedicated IP - they wouldn't even move me to another IP in the pool.
Given this, and my volumes of mail were increasing (once you go over 100k emails/mo SendGrid's pricing goes up a lot), I setup my own mail server using Cuttlefish [0]. I set it up on an OVH instance that I pay £2.50/mo for. I contacted them to enquire about spam policies before opening an account, and they said they take it very seriously and monitor outgoing SMTP for spam.
The IP address I ended up with was still on one blacklist, but the process to remove it was pretty easy (fill out a form, and explain the situation) and took about 1 day. I set this up around 6 months ago and have had no problems with deliverability since then, I'm now up to sending around 300k emails per month.
Unless you are doing a TON of sending, you are better off with a shared ip since it will have a known reputation. That is assuming that the provider is maintaining the integrity of those allowed to send with that ip. I haven't used sendgrid, but mailgun has been good about moving me off of any ip I don't like. Although I wish they were more proactive about it, I have setup a weekly monitoring script to check a bunch of the blacklists. If there are any issues, I will have them move me. And I am still on the free tier so I can't complain.
I've been doing this for 6 months now, and haven't had any issues. Over the last 7 days my deliverability of 64k emails has been 99.5%. The only bounces I have are because of invalid email addresses or mailboxes being full. I didn't do any 'warming up' of the IP when started, I just started sending.
I've heard this many times, and maybe it was true before but it doesn't seem to be any more. I suspect now companies like Sendgrid still spread this FUD so people are more willing to buy their services and assume it's the only option.
I'm curious to know what type of customer you have? My customer base is made up of quite a few less tech-savvy types and we get a lot of issues with spam for AOL and MSN accounts.
And I don't show any bounces either. Stuff getting sent to spam doesn't give you a bounce message usually. It will appear to have been delivered successfully.
As for needing to warm up the IP, I think there is still something to that. I am surprised you were able to just start right off sending large volume. My guess would be that that you lucked out and got a gently used IP address by chance. The fact that it was on a blacklist would indicate that it probably was previously used rather heavily... just enough to get blacklisted at one place. But not abused in a way that got it blacklisted other places.
We really need a better solution to fighting spam.
https://github.com/jimktrains/email_ng is an overly complicated idea I had once, but the basic gist is that the receiver could give the sender a signed receiver email address that is for the sender's email address. This way, transactional email (and sure, I guess marketing from your company) would be able to get through and the email given out wouldn't be able to be used if sold or stolen, as the receiving mail server would reject it because of a bad signature (bad sender, and coupled with DKIM and SPF, a malicious user wouldn't be able/allowed to spoof the sender's email).
This sounds like a cryptographic way to achieve the aliasing scheme many people already use, e.g "chatmasta+hackernews@gmail.com".
Your proposal requires at least the status quo (aliased email address at signup), but the problem is it also requires cooperation of the receiver's email provider (e.g. gmail) and the sender's email provider. You are unlikely to ever see any new standard adopted by all major email providers, unless it came through a standards committee.
But your idea is interesting. Perhaps you could lower the cost of adoption by replacing the dependency on TLS/SSL with some sort of pgp signing scheme. This way all the "protocol" happens within the message body, so email providers do not need to adopt a new standard. As long as at least one website and one user implement the protocol, it can work without any cooperation from third parties.
As an aside, it would also be nice if password managers included functionality around generating temporary/isolated email addresses.
There are services like 33mail.com, which I've used for years, which do exactly that. You give a service an email like servicename@chatmasta.33mail.com (or a custom domain, if you're on a paid plan), and then you can block/unblock/track emails per username.
Actually curious, so if I understand you correctly what you are saying is that a receiver had some software generated an address like johndoe+A16789HFF...@gmail.com and then sent it to the sender for use, that would require email providers cooperation.
I am not clear on the "cooperation" parts work. I THINK its basically that email providers block emails based on other criteria like DNSBL. And the "cooperation" bit is to get the providers to manage these cryptographic email addresses like guard against their possible misuse?
That's more-or-less what I was thinking. The receiver would require understanding of the signature to white-list the message; the sender just sends to an email address as they would normally. No or invalid sig would fall back to our current anti-spam methods.
why not just add +sitename to your email when you sign up..... eg me@example.com becomes me+flickr@example.com ? it's just a comment that will be ignored. I don't feel that we need software support to help with that. Your password manager will store that address (since it's probably your username) and help you fill it in / remember it when you come back to the site.
It’s not a comment. Some mail services allow you to have aliases in the form of normal-username+something@service.com but that doesn’t mean all do. If it were a comment the address +@example.com would be invalid but it’s not. Comments in email addresses are written in parentheses like username(i'm_a_comment)@example.com.
> We really need a better solution to fighting spam.
I rarely receive email spam these days. The spam I get is on my voice line. I'm getting several robocalls per day. If you have the skills to work on this stuff, I'd love to see a solution to phone call spam because email spam feels solved.
yes, but as someone who's worked on the sending of emails side of this i can assure you that the techniques for fighting spam are TOO effective. There are many legit emails that go into black holes before any standard idea of spam filtering comes into play. I wrote an embeddable smtp server so that you could have an app that sent email without ever asking your users to put in their SMTP server info... it was USELESS because of SPF filtering. The blacklisting of whole IP ranges means that no app could use it on a home computer because all those IPs are banned.
we definitely need a better solution to fighting spam.
I hear this all the time, but the culprit is always someone sending spam, who does not consider it spam. Usually stuff like missing unsubscribes, spammy language, sending bulk to bought email lists, etc.
As someone running a personal email server for >10 years I can promise you this is a legitimate problem and the false-positive issue is not even close to solved. It's just that most people use a big provider to send personal email, so nobody is incentivized to care about solving it.
For a company I worked for, it was transactional emails (recipes) that would get blackholed. So while you're probably right that a lot of people doing legit marketing, but not 100% correctly often complain, it's also people doing legit work as well.
It's the former. I use gmail and for me, they are almost perfect. It's been probably three or four years since my last false positive and less than 1% of the email I do see is spam that was missed.
For phone calls, somewhere between 30 and 50 percent of my calls are robocalls or other telemarketing (I receive far more emails than phone calls).
If there were an easy way to tell my phone to just drop callers if they aren't in my phone book, I would. Right now, my phone lets me know if a caller is a suspected spammer, but when I hit dismiss, it goes to voicemail. I'd rather have the call just dropped or for the caller to get a busy signal. That reminds me - I can't remember the last time I heard a busy signal.
My only phone number that people have is a Google Voice number and it's really funny when I have five five-second silent voicemails every day. Because none of them ever go through to my phone...
I get more spam and more robocalls every single day. I can't rely on even Gmail's spam filter, because it has a non-negligible amount of false-positives.
I think overall ISPs do a very good job at fighting spam. Compared to a decade and a half ago, I would call it a minimal problem.
My greatest fear is that Google and Facebook will co-opt email and charge money for companies to get access. Google has already made some progress with this by selling ads in Gmail that look like email while pushing commercial messages in to other inboxes.
This is bad because it penalizes companies with low margins while shifting the advantage to those who are able to squeeze more money out of the users (you can see the effect of this on Google Search, Facebook, and now Amazon. It isn't pretty.)
Correction: large^W giant mail systems, that can observe a significant portion of world's mail, and have a lot of R&D resources, do a very good job at fighting spam (in their own systems).
A DIY home mailserver will still let, like, 5-15% of spam emails slip through.
The last few times I went to spam and saw emails that shouldn't be in there, a careful inspection revealed they were actually very well crafted phishing messages.
Ever since, I don't bother checking the spam folder. Too dangerous. Gmail is smarter than me.
I'd start with the "email postage" proposal—the one where either a proof-of-work or physical payment (which can also be digital, e.g. a Bitcoin private key) is required to get an MTA to take your message. This proposal was declared unworkable due to rendering high-volume transactional email impossible.
But then:
1. as you say here, divide everyone's email account into a set of "channels" (i.e. subaddresses in a+b@c form, that each have a corresponding message signing key), with one or more published or well-known channels, and then individual private channels for each contact/list, or for each conversation(!);
2. make MTAs aware of "channels", and extend both SMTP and email web services to allow users to configure their provider's end-of-line MTA, over-the-wire, to set the amount of "postage" required to message each channel they own. (This way, the MTA doesn't have to be aware of the distinction between private and public channels; they're just destination addresses with a stored config parameter.)
3. make the MTAs that use channels, reject any Internet message directed to the base address without a channel. (Messages generated by the MTA itself can arrive without a channel.)
4. Set the clients' default new-channel configurations such that public channels have a cost, and private channels are free.
5. In email clients, add a "Subscribe" or "Allow" action-bar item to messages that identify themselves as email-confirmation/newsletter-opt-in emails (presumably with a header), that, when clicked, creates a new channel for the sender, and replies to the message with the signing key you want them to use attached. (All this would be hidden from view; the reply message wouldn't end up in your Sent Items.)
6. In transactional-email-sending services like Sendgrid/Postmark/etc., create a distinction between "opt-in messages" and "ongoing transactional messages"; allow each account to send one "opt-in" email to each previously-unknown destination-address (and charge for this); but then, for that account, put that destination-address into holding state, where the account can't send them any "ongoing transactional messages", until the email-sending service receives the user's conversation key. (You probably want to allow accounts to re-send the opt-in email after a 24-hour-cooldown, though. Though they'd have to pay again!)
7. In any product/service backend that uses a transactional-email service, consider new signups unconfirmed until the transactional-service reports (by polling or webhook or whatever) that the user has replied with a key and is now in the "authenticated and free to send to" state.
A bit complicated in the initial changes, but in the ongoing state it's nearly ideal: it costs money to initiate contact with an address, or to continue pestering an address that doesn't want to speak with you, but not to send messages to someone that wants to hear from you. (Though, a user can "unsubscribe" from your list simply by telling their MTA to begin charging you to deliver to their channel again—maybe, UI-wise, by just deleting the channel. Transactional-email sending services could detect the bounced-with-payment-required delivery error, and put the user automatically into an "unsubscribed" state, which could webhook you to let you know!)
How can you check if an IP is good or spammy? It would be nice to get an elastic IP in the cloud, test it for spamminess, and give back the bad ones. Catch and release fishing for IPs.
In practice, while there are some services which will purport to tell you an IP's reputation, their output isn't well correlated with actual delivery outcomes at scale (depending, to some extent, on what domains you're sending to).
This is because the big consumer mailbox providers often don't rely on public datasources for assessing reputation, and because reputation is tracked at the domain level, in addition to - or sometimes instead of - the IP level.
For example, there have been some indications from Gmail that they no longer use IP reputation at all, starting a year or two ago.
And re: blacklists: +1 to Spamhaus, but in practice it's one of very few blacklists that have meaningful impact to net delivery.
> there have been some indications from Gmail that they no longer use IP reputation at all
I can believe it. I posted already about my experience with the free tier of Mailgun's service. I went through all their instructions about setting up the service and verifying my domain etc. but still had a lot of email rejected, especially by yahoo.com but also hotmail.com due to poor reputation IPs
I found this service a few days ago to monitor our own deliverability. It allows you to test if your emails are delivered by the most common ESPs: https://glockapps.com
(I do not have anything to do with the product or team behind it)
In years past, many RBLs would categorize IP Addresses by type. e.g. dynamic IPs assigned to DSL/Cable subscribers. This would enable a receving SMTP server to check if the email came from an ISP subscriber, rather than an email server. If so, it was usually a good guage that the email was "spammy", because it was sent by a subscriber's infected computer.
In this sense, it was (and may still be) possible to simply block, or at least score differently, email from any/all AWS Elasic IPs.
The term to search for is "RBL" (real time blacklist). Search for "check rbl" to find interactive sites, or maybe "check rbl github" for code that you can use yourself (though you may have to sign up for several services if you go that route).
Neither, though, helps with checking if one of the big providers, like Google, would not like your IP. For those, you have to send an email and watch/parse the SMTP error responses.
Same experience with Mailgun. The "free" tier servers do not have good reputations. As you can imagine, being free, they are used by spammers. I found it impossible to send to yahoo.com recipients. Gmail, interestingly, did accept and deliver almost all messages.
I use sendgrid for transactional email and I have had no problems regarding that in the year I've been using them.
I have found their nighttime support team to be terrible though, resulting in 14hrs downtime because they didn't have authority to re-enable my account.
I generally don't believe these anecdotes when pertaining to successfully companies with 10s of 1000s of staisfied business users. Most are far better off with shared IP addresses. After you establish a sterling domain reputation you can think about your own IPs.
I second to that. For a few years now my opinion was that Sendgrid is a good guys of sending email... until I realized most of the spam I'm getting is from Sendgrid IPs, including for example continuance of work offers from Uber (I am disabled and I cannot even drive a car)
I'm unsure what problems Sendgrid is battling but their customer support staff is certainly understaffed or they simply gave up on fighting spam. So yes if you want to send spam and can start with highest paid account they offer, probably Sendgrid is your best bet.
Also their spam@ and abuse@ is a waste of time. It came to point that they simply started ignoring my inquiries at all! Here is example of one of my emails that is not getting any response, if Sendgrid is actually reading this: support+id1021573@sendgrid.zendesk.com
As sending spam is a Federal Crime, I have already reached out to FBI, FTC and next plan to write my State Attorney General.
Spam sucks, but don't waste your time reporting it to federal agencies. In practice, 'unsolicited' isn't a high enough bar for them to care - it has to be overtly fraudulent, malicious, etc. in order to have a shot at getting attention.
Unfortunately, unless you're paying for a dedicated IP address with Mailgun, their sender reputation is mostly quite bad. We are constantly having to request our account to be moved to a new IP due to them landing up in some blacklist.
This is an area that we're actively working to improve. The system is designed so that customers who are sending high quality messages get moved into better IP addresses. We look at metrics like complaint, bounce, and engagement rates to help make these decisions. This works much of the time, but is imperfect, especially when you start using Mailgun for the first time. We're developing and iteratively rolling out several machine learning classification systems that look at various features when you signup for Mailgun and place your account into better IP pools based on our internal risk calculation.
If you are seeing continuous problems, I'd love to take a look! My email address is on my profile.
Hi, we've been seeing problems like this with Mailgun for about a year (with the support ticket record to show for it) and I'd love to get in touch. FYI your email address is not currently visible in your profile (should be in the 'about' section).
Is this per-project, or per-customer? I run https://spa.mnesty.com/ with you, which has a 1.5% bounce rate (I'm guessing that's high? I don't really know), and I wouldn't want it to be interfering with my personal email (0% bounce) that I also run with you.
I used to use Mailgun for sending out licences for my product. I got a lot of people saying they had never arrived, especially Microsoft addresses and Chinese ones. This continued despite repeated complaints and IP switches. I switched to sending through Fastmail and have never had a problem since.
It depends. Most hosting providers will either discourage you or prevent you from relaying messages from your servers, so that is something you need to check for. Also, you'll want to make sure that your dedicated IP is persistent and won't be lost across reboots. Once you establish a good sending reputation, that's valuable in making sure your messages reach the Inbox.
In the case of Mailgun, you should be assigned an IP with a neutral reputation. For example, before dedicated IPs are reassigned we leave them dormant for at least a month, usually much longer, before assigning to a new customer.
Paraphrasing Oscar Wilde, every IP address has a past; in theory, an email service will ensure that the IP they give you has a clean bill of health (not marked in blacklists and such), whereas your ISP or VPS provider may not.
Since I've complained about the free tier reputation issue elsewhere, I will say that Mailgun gives you a great set of management tools and a very nice API. Those are things you're going to have to build/assemble yourself (or do without) if you just go the "postfix on an EC2 instance" route.
If they aren't paying for a dedicated IP, those emails would be going out across the shared IP pool, and a particular IP's reputation would be affected be everyone who's email went out via that IP.
From personal experience, if you're not jumping straight from no emails to a million an hour, your mail setup is good (SPF/DKIM/etc), you're not reusing a IP address that was sending spam last week (so be wary sending from cloud servers), and you aren't actually sending spam, then you can send from your own infrastructure just fine.
This is true, with the exception of AT&T. The Deathstar rejects all mail from my server, despite (a) no spam ever having been emitted from my domain in almost 20 years, (b) the IP having been stable for coming on eight years, and (c) I don't send bulk mail. Best I can tell, their blacklist-removal process is auto-deny with no humans in the loop.
I gave up and decided screw them, I don't need to talk to anyone with an ATT address, and bounce messages from them with an explanation.
I think AT&T was also the reason I started using a bulk mail delivery service for my low volume personal mail when 1&1 migrated their datacenter after I had been using them for a decade or something (thereby changing my IP address).
Until recently I sent newsletters from our own infrastructure and I agree that it's doable, but:
- You have to ramp up sending from new IP addresses VERY slowly if you want to avoid getting grey / black listed by Yahoo and AOL, this makes it quite a tedious process
- Make sure you also have rDNS set up, Gmail uses it as an important quality signal
- Accurately handling bounces is a bit of a nightmare because each mail server has a slightly different format and you want to make sure you don't process out-of-office messages
- Bounces and "message delayed" messages can arrive days later
So we ended up switching to mailgun and although they do sometimes give you a bad IP the time saved is worth it, especially their option to have a web hook back to your backend to process the bounces.
Sure. Until they email you your account is "temporarily suspended due to some spam complains" and before you find out some angry customer felt that tmher refund process took too long and filter her email to see yours and click "mark as spam" each email and you scramble to setup your own mailservers before you let employees go because your company is unable to send a single email to make a single sale this month...
Mine was suspended for spam and I was falsely accused by Mailgun of have compromised servers. Initially I freaked out and then discovered that my servers were fine, but my account at Mailgun was hacked and used to send thousands of spam emails. This happened a couple of times. I asked to see the IP addresses of the senders and Mailgun said they didn't track that/could not tell me. And then they had the audacity to bill me for sending spam that was sent as result of their system being compromised.
And their collective knowledge of how many concurrent connections to open with each provider, how many emails to send in a single SMTP session, how fast to send, etc. There's a fair amount that experience lends to staying out of the spam box.
Sendgrid gives you dedicated IPs so you are responsible for your own reputation. When you start out using it you might start on a low reputation depending on what the person on that IP did before.
For me, it's more the support you get from using third party APIs. It's nice to break away from companies to a certain extent, but if you need help/support you only have yourself to fix the issue. If you go with a third party and something happens, you can go to them for a solution.
And if the third party service goes down, you're SOL -- there's nothing you can do to fix the issue, and it's your users who are suffering. What's your answer when a customer says "my emails aren't getting through, please fix it" and you...can't?
If emails are a part of your core business, you should have a business continuity plan for this situation. That may be to fall back to another service, or even a temporary in-house server.
Of course, if it's that important, then you'd be foolish to not have invested in a better solution, or to not have a proper SLA with a third party.
This is a major risk of outsourcing part of your operations. You probably
shouldn't do this to the core of your business, as you lose control over
problems. But sending marketing e-mails usually is not the core of business,
unless one is selling the service of sending e-mails.
There's lots of effort in building AI for chatbots, but why aren't there more efforts in building AI for better spam classification? As much as I would like email to die a horrible death just like snail mail died and have everyone (individuals and businesses) start using some form of IM, it's still quite an integral part of the interwebs for people that it deserves a bit more focus on smarter spam filtering instead of relying heavily on IP reputation pools which screws over many legit users.
Gmail stopped using IP reputation entirely a year or two ago, and effectively every major consumer mailbox provider relies on domain reputation heavily these days. Almost all major filters look at a combination of indicators, so it's becoming less and less common that a good mail coming from a bad IP is subject to filtering.
The answer to why better spam filtering AI hasn't been developed in a non-proprietary setting is fairly straightforward: the success of any filtering method is heavily dependent on consuming data at scale - including recipient behavior (e.g., mark as spam, vs. spend time reading a message), and this underlying data is just as important, if not more so, than the machine learning approach used to compute filtering assessments.
In short - you more or less have to be a large mailbox provider in order to have a chance at doing this well.
I think reputation is counted towards your DKIM these days, which also makes the reputation somewhat portable by moving your private key to with you to a new server/ip.
IP reputation continues to be the most important factor that impacts deliverability. Providers are slowly moving to domain-based reputation systems that leverage DKIM. Gmail seems to weight domain reputation in their calculations higher than most currently.
I took a look at the github project and I hope they do great.
As a side project I've been working on setting up my own mail server using "Mail-in-a-Box" (https://mailinabox.email) for about a month now.
It's been a learning process but I do like the idea of having control over this. I've got it set up to send emails from a remote app server using a perl script and an email account configured on my Mac Mail app all working.
Mail-in-a-Box is really pretty sweet. It walks you through the install and has a very nice Control Panel that handles DNS and user account setup and it comes with the Roundcube email web client and ownCloud.
There are hurdles. I got a clean IP from DigitalOcean with no problem, but the domain name I'm using is new and has no reputation so when I tested it last week sending emails from the app server to my personal Gmail account the Gmail server responded saying:
"Our system has detected that this message is 421-4.7.0 suspicious due to the very low reputation of the sending IP address. 421-4.7.0 To protect our users from spam, mail sent from your IP address has 421-4.7.0 been temporarily rate limited."
I only sent about a dozen emails, all to my own Gmail account, so that seems to be a bit harsh.
Then it occurred to me why Gmail exists and it made a lot more sense. So, there are hurdles.
We sent a lot of emails which makes services like Postmark or Mandrill very expensive. Since switching to Amazon SES, the cost has been much lower but the lack of individual email tracking has been a pain (in case a recipient claims they haven't received it or we need to track opens, etc).
This UI with an Amazon SES backend would be ideal.
The Sendy codebase is horrifying. [...]Just lots and lots of rough PHP _vs_ This isn't software to be used for analysis. Sendy is f-in awesome!
Amazon SES rocks from a pricing standpoint but deliverability isn't its strong suit _vs_ I find no difference between SES and MailChimp regarding delivery
I would stick with Sendy, but I could never get the unsubscribe links to work _vs_ there is a version 2 of Sendy, which appears to fix all these problems
lighter version of Mailchimp and super cheap [...] Configuration is a bit painful
I have been using it for almost 1.5 years and really like it.
if you are taking all the trouble to install Sendy you should look at Mandrill (2 years go) _vs_ Major changes to Mandrill, must be tied to a MailChimp account (1 year ago) | https://news.ycombinator.com/item?id=11170713
Sentopia.net founder here. I agree that the codebase could be better, a lot better.. but we have made heavy modifications and it's not a problem anymore, I should add that we have tried to work together with Sendy.co developers but seems our emails are being ignored.
Sendy is a platform, and a good one at that. but our value is on our SMTP server pools and their reputation as others have mentioned. We are always looking at new platforms like postal, that we can jump on board with if it means a better user experience for our clients.
Seconded. Can only highly recommend send. The license is inexpensive, you get the whole code base and can modify when needed as well. Setup is easy as integration into SES very mature at this point.
The codebase is a bit of a horror, though, of the old "PHP+SQL+HTML mixed in a blender" variety. I went in to make a few mods at one point and it was pretty scary.
I co-founded https://emailoctopus.com which might be what you're looking for - we're an AWS partner offering marketing features (list management, open tracking, etc.) on top of SES.
You could also try something like Sendwithus hooked up to your SES account. They provide a consistent template, delivery and customer support interface for email that integrates with a lot of different providers.
It's a nice layer who's pricing works if you're sending a lot of emails to the same people over and over again. The entire setup (pricing and interface) is build around individuals sent to and not total email volume.
> Postal was developed by aTech Media to serve its own mail processing requirements and we have since decided that it should be released as an open source project for the community. It was originally launched by us as AppMail but renamed to Postal as part of making it open source as we felt the name was more suitable.
The reason why we use Mailgun is to avoid deploying and maintaining e-mail infrastructure which is very hard and high cost. We would rather keep paying Mailgun about $20/mo as this is cheaper by several magnitudes than the self-hosting option.
> 20/mo as this is cheaper by several magnitudes than the self-hosting option.
exactly this, even the cheapest cloud instances cost around 100$/m, while some might be 20$/m it's just not worth the effort to host your own because it also needs management/maintenance if you do which translates in to hours of work. Yes you can automate these things but it simply not worth it when the only thing you want to do is sent mass emails, without even caring about anything besides configuration to connect to XYZ service.
Hmm... We use Sendgrid to do things like sending confirmation emails. We send a lot of them because we have a lot of customers (long may it continue ;-) ). That's what I was thinking when I read "mass emails". YMMV.
Will this platform be actually usable for independent developers considering today's spam blocking scenario. How one should proceed with this in order to not get blacklisted while actually using it for the first time.
It's an interface, it doesn't take care of email reputation for you. This is for people who want to DIY to have a pretty dashboard on top, but you're on your own for email deliverability.
This sort of thing is fantastic to see, regardless of whether you want to run your own mail servers for this task.
That they provide a hosted service using the same stack is great to see: host it yourself, or pay them to host it for you. This is what great open source businesses can look like.
No "open core" where the good stuff isn't available for the community, and community efforts to implement the same thing get rejected.
No viral licensing like the GPL or jesus shit on a stick, the AGPL.
Completely agree with this, my only concern is that an open-source solution increases the likelihood of spam-ridden senders popping up more frequently and becoming harder to shut-down as they can spin up instances more easily and get going from a new location more quickly.
There is actually some benefit to be had by the process of setting up a mailing service being a little trickier.
From a business perspective, it's also a great decision, as it shows customers who outgrow (or are in fear of outgrowing) your SaaS have a first-party path to scale.
And you could still make money off those customers if you can offer a strong support/hosting solution.
It's a massive win. As an aTech customer with some of their other products in the past, I'm really pleased to see this and I wish them all the best!
Also, proud to support fellow Brit tech companies ;)
> No viral licensing like the GPL or jesus shit on a stick, the AGPL.
This GPL hatred is completely orthogonal to your point. In fact, GPL/AGPL ensures that other services won't turn your lovely free software project into an open core product. See ShareLatex for a similar free software business and project that uses the AGPL and appears to be working just fine.
The reason that Linux is what it is today is the GPL. Otherwise it would be just like BSD, and bundled into the OS for worst of the worst for propriety shit, Apple.
Interesting, I was just looking for something like this the other day, thanks HN! The software looks quite polished. Hopefully there'll be a dockerzied version to play with it.
Awesome, I've been waiting for this, because I don't believe in the "delivery" promise of big brand mail providers. Most newsletters* go to spam, no matter if they're via Mailchimp, Aweber or transactional mail providers.
Maybe the big names work better with Gmail, since Gmail has quite an aggressive spam filtering. But neither I, nor most of my customers (Germans) use Gmail, so I don't care.
I'm most interested to see what their solution for handling INCOMING email looks like. Having used the inbound APIs with the others they are all pretty polished and reliable but have inconsistent APIs. I've always been a little bit concerned about how to handle high volumes of inbound email functionality if the prices on those services ever went up.
If I were to host this myself, I'd still need a static IP that had a good reputation. GCP and Azure both mention that we should not be hosting mail servers on their platforms (rather, they all suggest we setup mail servers + relays to a reputed IP).
How would I go about getting a static IP or a reputed IP?
Is this more than an SMTP server? Those are services designed to send emails as an API service for many different parties. Is that what "Postal" is? Or is it a another SMTP server like Postflix or something? It's not at all clear from your description...
Does Postal allow you to set up an email group? I.e. an email address that will forward to a defined list of other email addresses any email that is sent to it? This is a feature of Mailgun but unfortunately it does not quite behave in the way we need with regards to setting the 'Reply-to' address.
I'm looking forward to seeing the documentation and setting up Postal on my server.
More an open-source alternative to Sparkpost, if you're looking to compare it with a Message Systems offering. (But not really all that comparable, since Sparkpost is nothing without Momentum, and this does not appear to rely on or include any specific MTA.)
Is it common now to call email "mail?" I don't know anything about this area (never even heard of mailgun or sendgrid) and wondered if this was some kind of service for sending actual mail.
Not sure if you or I will catch any hate as I point out that your disclaimer as founder of emailoctopus was included elsewhere in the thread but not here.
Just pedancics/semantics from me; many in this situation include the info (some:only) in the profile instead/as well and that has been mostly accepted in the past. I also appreciated your mention of another alternative too, it's definitely not over-the-top astroturfing in any way!
After the demise of Mandrill I started to divide transactional email between Elastic Email and SparkPost. I send around a thousand messages a month through them and haven't had any problems with either. I still miss Mandrill though. I send high volume mail through Mailgun and have had a great experience with them and their API. I tried integrating with Sendgrid but they have some constraints around MX records that were showstoppers for me.
Fair. To a certain mindset, "self-hosted" is its own advantage -- but to pick a couple of advantages out of thin air:
+ Free: I can run Postal on my own hardware, with no usage limits or costs other than the VPS or AWS costs (which I'm paying anyway)
+ Independent: I'm not relying on a third-party to provide core features. If SendGrid goes down there's nothing I can do about it
+ Private: Maybe I don't want to hand over a list of my user's email addresses to SendGrid.
Self-hosting services means I maintain control over them. It's a tradeoff, and you may value control less than, say, convenience. YMMV.
I feel like you're still begging the question. The proposition is not really "SendGrid vs Self-hosted SendGrid", but "Self-hosted SendGrid vs any IMAP/SMTP server":
> Free: I can run Postal on my own hardware, with no usage limits or costs other than the VPS or AWS costs.
So is postfix.
> Independent: I'm not relying on a third-party to provide core features.
What features? This is the crux of the question. What do you actually need that justifies having to maintain a web application?
> Private: Maybe I don't want to hand over a list of my user's email addresses to SendGrid.
Imagine a retail business that relies on emails to get information on what's next: what are the most popular products, what's a good tag line, which segment of its customers are interested by what, who is most likely to buy. Sendgrid allows you to add A/B testing, scheduling (send a % of emails at a specific hour), track who opened emails when, track who unsubsucribed.
If you are doing simple emails like email confirmation or simple user reminder, these features are totally overkill. But email has still the best ROI for many businesses and thats why they need sendgrid
Assuming it has an API, I would prefer to use this over a service such as Mailgun. We used to have our own mail server, but without an easy API to get deliverability details per mail, we ended up switching to Mailgun. Since the switch, our deliverability has nosedived (we're currently not paying for a dedicated IP though) and mails are constantly bouncing due to the low reputation of Mailgun's shared IPs.
Mailgun's 30-day retention period is also a bit absurd, since most of our clients require mail audit trails in the region of 6-12 months.
Some organizations can't (due to regulation) or won't (due to privacy/security concerns) give their email list to third parties. That eliminates most of the third party MTAs as they all maintain sending lists, logs etc.
Is Postal and services like Mailgun solution for a functionality where email can be viewed/replied from personal email inbox and a web app? Then somehow magically these services routes mail to relevant inboxes and the web app like Zendesk etc?
Our app[1] sends/receives several million emails per month. Not an exaggeration, it's actually seven figures.
Meaning it's more than 100k a day. Meaning it's 5-6 emails every friggin second. On average. It, of course, peaks during US daytime, up to 30 per second.
We tried a looooh-ot of solutions (all priced at THOUSANDS a month at this volume) including Mailgun, Sendgrid, SES etc, but finally settled to a tiny Ubuntu micro-instance on EC2, running Postfix. It has 1 gb of memory, costs us $4 a month and the CPU load rarely goes higher than 4%.
Of course you would need to get yourself familiar with SMTP, postfix, SPF/DKIM, mx-validation, blacklists etc. And by "familiar" I mean "learn it tothe core" :))
Another thing - you need to build-up reputation for your IP, cause email providers like outlook/gmail/yahoo will simply reject your emails if you start sending a LOT out of the blue. You have to build it up gradually, takes months to get there. Makes it a huge PITA when you need to change your IP :((
PS. If you need incoming email to call some external REST-api - postfix can launch a local php-script that does that. Not sexy but - $4 a month, right.
[1] https://www.jitbit.com/hosted-helpdesk/