The “mail is hard” myth
poolp.org
poolp.org
Writing applications is hard. Designing a website is hard. Professional work is hard.
But setting up your initial mail server is not hard. Read some guides (ahem: https://flurdy.com/docs/postfix), fix a lot of typos, and you're up an running.
Same with developing the initial version of an application, or designing the first draft. Not rocket science. Not easy but not that hard for an experienced person with simple initial requirements.
But what is hard is keeping it running with more and more users, more requirements and evolving tech and less time to maintain it. Never mind forgotten skills and less priority.
Mail servers have a special knack for running out of disc space or going down for some reason only when you are on holiday and can not get online easily. And you usually only find out after a day or more as you start not receiving messages but don't really notice it for a while.
Or you friends, family or colleagues using it start complaining that some random person they are emailing is not receiving their email and you need to look into it... (Ps. Use DKIM and then DMARC reporting)
If you just want a reliable mail service, just use https://fastmail.com. If you want even more freedom and configurations, do try to set up a mail server. But it is hard. A bit hard.
I used to run my own mail server, but I eventually migrated to Fastmail. I liked then because their software stack was similar enough to mine (compatible filter rules) and I knew where to find their admin on IRC.
The reason I made the switch is because I was sick and tired of my Email reliability depending on the reliability of my home Internet connection, and my co-lo/remote-hosting situation (at the time) had different reliability issues I didn't want to risk.
Fixing up an old car is fun. Doing it in chunks of a few hours so you can drive it work the next day is less fun.
Running your own mail server is a fun challenge at first, as you have to figure out why some random site won't talk to your server, or why your load spikes at random times. Then you decide that diagnosing other people's broken configs and dealing with drive by spammers is annoying and boring.
non-Fastmail options that are a lot cheaper for multiple mailboxes and provide more, like Posteo, Mailbox.org, Runbox.com, Mailfence, Migadu, etc.
Thanks for mentioning some alternatives, but I've just checked the first example and it does not support custom domains (which Fastmail does), so it does not "provide more".
If you want to apply logic like that, you have to apply it correctly. To falsify a universal claim you only need one counterexample, but the original poster never used a universal term (all, never, etc). If it wasn't a universal claim then you can't apply the rules for universal quantification to it.
More to the point, my comment wasn't attacking your logic, but that you seemed to dismiss the entire list based on the one example. I didn't see where you mentioned you were happy with the alternatives and only critical of the one, if that was the case then I just missed the larger context and I apologize.
Just for arguments’ sake, I could argue that Fastmail’s privacy stance and policy don’t matter much compared to Posteo because of what’s written on their websites as well as which jurisdictions these are located in, and hence Posteo is better for privacy. I could also argue that for non-technical people, having a custom domain and managing it is a pain, compared to just choosing some domain from a list of predefined domains in a drop down and not having to worry about domain renewals, MX records, etc.
I’m not saying that custom domains are bad (they do allow you to switch to another provider easily), but there are trade offs to consider in both cases, and hence what may be “more” for one may be “less” for another.
Also consider the price difference when multiple mailboxes are required. Fastmail becomes quite expensive very soon compared to the others.
yeah, but compared with other services like WWW mail is IMO harder. You deal with two main Protocols and a lot of software. While mail takes 11 components in your tutorial, you'd get a website in 4. And some parts are hard to debug. I have very little means to debug why my mail wasn't delivered to my bosses gmail.
Not because DKIM and DMARC those you setup once and don't care.
Because doing something for people and for free is hard.
It's a consumer-oriented SaaS for taking control of your personal mail - there is no enterprise pricing, nor even a subscription pricing option - though you can you can choose to pre-pay for the service years in advance.
Kopi uses Amazon SES for email delivery. We know Amazon wants to make sure that their service is a viable product for mail delivery at the commercial enterprise level. The idea is that Kopi can survive as a viable retail product by riding on the coat-tails of that desire and arbitraging the cost of mail handling via SES so it's cost-effective at consumer level.
The intention is to run it as cheaply as I can, ($1USD / month at the moment, though I make no guarantee that it can stay that cheap forever) and to give people the ability to choose between different mail services.
The idea is that you can manage your own domain, and setup your DNS to use Kopi as your mail exchange via DNS MX records to forward your email to whatever mail service you choose to use. If people don't want to even run their own domain, they can can use the shared Kopi domains if they want - with the understanding that those mail addresses are locked to the Kopi service, but at least they can change mail service whenever they want.
The goal is to be easy enough to use that you can set up your email handling via a smart phone, and cheap enough that running your own email handling using free software should seem expensive by comparison.
Though I'll admit - marketing this thing is a bit of a problem right now :)
That's why I generally recommend a hybrid setup: Host inbound mail completely by yourself so that you have full control, but ship off outbound mail to a trusted relay of a privacy oriented provider. For example https://posteo.de/en doesn't filter any outgoing messages by sender, so you can send mail from your own domains. Your local Postfix can DKIM sign your mail before sending them to Posteo and if you add include:posteo.de to your SPF record all your mail will be DKIM signed, SPF authenticated and coming from a reputable IP, so all your deliverability issues will be gone.
Which is why I’d consider it “hard” to run my own mail server. The complexity of running a daemon with a config file isn’t the issue, nor is it that any individual task of SPF/DKIM/etc is complex. It’s that I generally want to put 0% of my time into making sure my emails are being received, and I’m receiving other peoples’ emails.
> Hashcash was proposed in 1997 by Adam Back[1] and described more formally in Back's paper "Hashcash - A Denial of Service Counter-Measure".[2]
The problem with this idea is that spammers don't use their own computer, they borrow other people's computers to send the spam. It also heavily penalizes people who legitimately need to send bulk email.
Aka spammers.
I work for an email marketing provider (opinions my own, obviously), and I was extremely surprised how many people genuinely want to receive lots of commercial bulk marketing email. And by "want to" I don't mean "don't mark as spam", I mean "continually sign up for different marketing newsletters, and consistently use links in newsletters/marketing emails to make purchases from multiple companies". It's an alien phenomenon to me, and it may be a minority of bulk email, but it definitely is useful to a lot of people. Maybe it's their equivalent of coupon-clipping-based shopping, or maybe they just like learning about things to buy in that format? I have no idea.
That aside, the last thing an email marketing platform wants to do is send spam. Every time someone marks an email such a provider sends as spam, the reputation of their sending addresses is damaged, and therefore their ability to deliver mail to aforementioned people who want to receive them (and therefore the ability of the marketing platform to make money by facilitating that kind of desired email) is jeopardized.
TL;dr there's bulk marketing email and then there's spam, and surprisingly little overlap (and overlapping incentives) between the people who send each.
I have a couple of broad categories for these filters like car stuff, computer stuff, other-hobby-related-stuff and of course clothing, and just take a look at the appropriate one when I need or want something. Takes virtually no time, and saves a lot of money.
Of course I'm not gonna lie, I do end up buying things that I wouldn't have bought otherwise by doing this. But some of those things are pretty cool, too. :) I do have a few more cheap ARM boards of various types than I can probably use, though.
These have a lot of iffy issues.
* Since they're going to be generated by the ecommerce service, it may not be running on the same server or IP block as your main mail infrastructure, so you might have to specially configure around that.
* The content-- hundreds of messages a day, at seemingly scattershot recipients and highly templated-- screams spammy nto the wrong algorithm.
Yeah, there's services like Mandrill, but the whole ecosystem feels broken. It's not serving mailers. It's not serving the recipients very well. It seems designed to please a small, delicate, vocal audience. The people so upset at the prospect of false negatives (spam in the inbox) that they rally around providers who are prone to aggressive false positives. Who are these people and what makes them tick?
I could see this backlash in a situation where it's high risk or cost, but users can manage their own filters in any half-decent mail system, and frankly, clicking through a few pieces of spam a week is not a big deal-- arguably far less a hassle than spending an hour on the phone to get a tracking number that a spam filer ate.
The quantity-above-quality model in the spam industry probably lead to low-quality or vague list criteria. Broad demographic groups and domains. A lot of third party data of questionable legitimacy. If you've been running the list a long time, some "email address foo@bar.com clicked on campaigns A and B" data. You might be able to say on a large scale "List A is likely to convert better than B", but it still comes down to spray-and-pray at the individual address level.
If you went to a spammer with a few "sucker lists" of 100k emails each, and told him "you can only send 1k per day", will he have the data to triage his list to get a decent return on it anymore?
This would also snowball over time. Without being able to do high-volume campaigns initially, they'd have a harder time building up the knowledge they can use to manage their lists, and the quality would decline over time.
If you have your own ASN and your information is registered with reputable parties in lawful countries, you might not have much to worry about. If you are using a cheap cloud VPS service whose network is registered to a Romanian holding company, nobody will deliver your mail.
Wouldn't this be a good task for an open-source package to handle? If you'd just updated the package regularly, your mail would always be sent according to the rules. No need for any third-party handling your mail.
Some of the "rules" for reliable outgoing email delivery cannot be encoded inside the source code files of a github repo, or email setup bash script, or a Docker image, or a EC2 virtual image, etc.
An example of an unspecified "rule" outside the boundaries of a local machine holding the email server is recovering from an unexpected blacklisting of ip addresses. Example.[1] A preconfigured Docker image of Dovecot isn't going to magically ask Amazon support staff why the ip address is blacklisted and/or move the server to a different ISP etc. If a bad actor (that you are unaware of and have no control over) happens to share your ip address block and sends out spam which then causes Gmail/Hotmail/Yahoo to reject your server's emails, there's no open-source programming code that can detect and fix those problems happening outside of your control.
Or put another way, if HonestJoeBlow could download a constantly updated Docker image that has the so-called "correct rules" for sent emails to always be accepted by Gmail, it would mean the DishonestSpammers could also download that same Docker image to get their emails delivered.
The issue is that "trust" in the email ecosystem is an emergent property among participants and therefore, it can't all be embedded inside email server configs, or in a DIY blog article trying to explain the exact 12 steps to make email delivery work perfectly with all receivers. Eventually, something can break (because a receiver changes their idea of "trust" and "spam") and it requires troubleshooting & debugging to get email delivery working again.
A tldr would be: You can't put "sender reputation" into a downloadable software package.
[1] https://forums.aws.amazon.com/message.jspa?messageID=724690
Spam however is still a hassle and you're never going to match Gmail or Outlook when you're small. Say it takes a few hundred identical spammy emails to trigger a filter. For Gmail it means the chance of receiving that spam is less than 1 in a million. If you're small and managing say a 1000 users - a large percentage will end up with receiving the spam.
Wait, is this really the way how spam filters work? All I need to do is to add a random number to all emails to bypass spam filters?
Last thing you need someone on a self-hosted email server is running EDM campaigns.
Why do you think that? The article mention exactly this could just be a myth that perpetuates because people repeat it without actually trying it.
In fact, I used to think exactly like you when I originally set up my personal mail server and opted for the hybrid setup you suggest. However, when the third party service I used to send mail shut down a couple of years ago, I quiclky set up outbound mail on my own server. None of my emails are considered as spam, and I haven't touched the mail configuration since.
Big mail companies have blacklisted entire C-blocks of IP addresses at VPS providers, because parts of those blocks have been used to send spam in the past, and you won't know until you actually check with people you are sending mail to, to ask if they've received them. It sucks.
I think it's more of a Gmail/BigMailerCorp issue, and still using a private mail server myself, but I don't think it's fair to say that it's all easy and works flawlessly, even with strangely behaving mail servers on the other end.
How did this happen if Gmail deletes spam after some weeks?
Edit: or, as the sibling comment suggests, it behaves strangely with respect to removal as well.
Not sure about OP, but many people have tried it and it is a PITA. Even once you have everything setup right (SPF, DKIM, etc.), you still have to deal with IP issues. I ran my own mail server for years (actually, still do for incoming) and it worked fine for about 10 years until I needed to switch providers and got a new IP. Then I found I had to deal with an IP with no reputation and IP whitelist/blacklists. The deal breaker was finally dealing with blacklists that you had to pay to keep off of.
UCEPROTECT was the one at the time. They would randomly add my provider's entire IP space to one of their lists and during those times all email to a couple ISPs would bounce and the only way to get my IP whitelisted from those blanket bans was to pay $$. Switched to using an external provider for outgoing mail and haven't had a problem since as they take care of that crap.
Sounds like you never actually tried to measure the delivery rates of your outgoing email. No email server is actually able to get 100% of its outgoing mail past spam filters.
I've ran my own email server for a few years and I can confirm that the article is making false claims. It's incredibly difficult to deliver email as a low volume sender. The article falsely claims that it's not difficult and that people simply haven't tried it. Well guess what, I did try it - for years - with countless hours sank into it.
I wrote a blog post documenting my numerous, unsuccessful efforts to get my email delivered. I wish people would stop spreading these baseless falsehoods.
https://www.attejuvonen.fi/dont-send-email-from-your-own-ser...
Given that, 100% delivery rate seems like a dream.
https://penguindreams.org/blog/how-google-and-microsoft-made...
My guess is that a lot of people try it, have poor delivery rates, and abandon the effort before they have enough time to develop decent domain & IP reputations.
I've been running my own personal mail servers since 1995, on my current IP addresses since ~2016. If I add a new domain to my configuration, it takes 1-2 weeks before Gmail will reliably accept mail from it. Once I wait that out, delivery is mostly flawless.
I found it to be very time consuming and complicated, mainly because of the trouble of outgoing mail.
Which is it? Those of us who have run mail servers know that you get unconditionally spammed all the time.
But, and it's a damned big but, AFAICT, my email servers make less of those mistakes than the big email providers like Google or Microsoft, so the overall reliability of my home grow system is higher. It's got to the point that when someone complains they didn't get an email I got, my first question is "do you use gmail?".
The other big but it is it complex. It isn't just a single server - they are a network of them that distribute email across a geographically dispersed organisation. Despite being distributed it archives copies of all email that passes through it (as required by law here). There are some 2.5K of configuration lines driving it. So yes, it requires some effort to set it up. However, like your case those 2.5K lines haven't changed overly in over a decade.
The flexibility the system provides us in the way we handle email is invaluable. As a consequence of that flexibility a lot of emails are never seen by humans - they routed to a place they can be automatically processed.
Personally I wouldn't say email particularly hard, or particularly easy. It seems no more difficult than all the other things you have to do to manage a cluster of servers. The rewards for getting do it inhouse are pretty big, because just like everything else a programmer or sysadmin has control of, over time it will be scripted so heavily it will become almost invisible.
Getting off their block list was either impossible or involved digging some old forum posts to find an email address that you could try your luck with, usually with no result as it seems nobody was reading it anyway.
Nothing quite matches the gut punch of being on time for a deadline then having to push it back to troubleshoot mail problems. Or losing a weekend because while you know enough to get started your experience isn't deep enough to fix deliverability problems in a timely manner.
> I work on an opensource SMTP server. I build both opensource and proprietary solutions related to mail. I will likely open a commercial mail service next year.
Translation:
"I am an intelligent guy who works hard. My entire professional career is devoted to designing and maintaining mail systems. I work full time to achieve mastery of my craft. Yet I can't understand why people outside my specialization might find it difficult to do my job."
Email _is_ hard. That's why I'm very happy to outsource mail to experts like OP.
True, but it is generally fairly minimal.
That's actually kind of the problem. It's the same thing with phone systems. Any IT person worth a shit can follow a decent tutorial and end up with a system that works. Until it doesn't.
What happens when it doesn't is the issue. For a lot of businesses this will be an immediate critical problem. This is not a great time to be learning by experimentation.
If these services are not critical then go nuts, but if your business depends on these services you really want to have someone whose full time job it is to run them. If your business is not large enough to support having a person's primary role be administering these systems you should really have a third party vendor do it for you.
The article is right, you don't have to use one of the big names, but most of the time it's not a good idea to run your own if you consider email to be a critical service.
The only thing that gets mail dropped big style these days, in my experience, is the saddest one: Reverse DNS entries, ie not getting PTR registered. This anachronism still seems to be a fixation by everyone.
Content checkers seem to be pretty decent these days. My fav. is rspamd nowadays with Exim on the front. I generally wind back from doing anything fancy and leave it to defaults. Even more bizarrely, I do add a domain blacklist for all return addresses. As you know email addresses are easily fakeable but the semi legit spammers do stick to a list of domains and hence can be dropped with a few rules. They will go away after a while.
Then you've got to set up your domain, and domain headers on your domain host. Oh, DMARC is also another thing.
Then, most ISPs will outright refuse to accept incoming mail from your IP address, since they've basically changed from blacklisting to whitelisting. So you've also got to relay your outgoing mail via your domain host.
And then spam rules. I took the recommended rules from the Debian/Postfix/something-something-sorbs.net website, and I rarely receive email from e.g. eBay, because they've been marked as sending spam. Often happens with gmail addresses, too.
Despite all this... I still run my own mail server, but hotdamn, you're calling this not hard?
EDIT: Oh, and nowdays you've also got to entangle your TLS certificates into the whole process somehow. I managed it, but don't ask me how, I'd need to read up on that.
I really didn’t have a hard time setting mine up and I’ve done it multiple times. Dovecot is a bit of a pain if you really want imap... but overall none of it is harder than most other things.
And this is precisely why I don’t think it’s worth it. I don’t want to have to worry that “most” domains will accept my mail, I want a big email service that has the clout to force domains to accept my mail. I shouldn’t have to solve the mystery of why my mail was rejected (or rather, why some provider thinks I’m sending spam). That’s why I do Fastmail.
I asked Fastmail support, and they basically said, "we're not really built for that." However, most of the other services I looked at had arduous terms (arbitration agreements), and even they were talking about delivery rates in ranges of 85-95%.
My takeaway has been that as an app creator, email is really unreliable, and I should try whenever possible not to make it a critical part of anything I build. If 5-10% of the people using your service can't get a password reset email, what do you do?
As someone without much experience with email of that nature, it doesn't seem like the major services actually solve the deliverability problem. If they have Google-style support where I can't get one of them on the phone if my emails aren't sending, then I might even be worse off using them rather than my own setup that I can at least debug and experiment with.
Look, I don't want Google changing this tomorrow because to something tied to and controlled by them because they don't do evel, isn't faster or people like it, but please, don't say it's not hard because you will be misleading people for sure
Edit: to be crystal clear, I agree with parent but don't agree with op
And then there's also the password/username database, that defaults to tying into the Linux pass/user database, so if you want to set up some custom login-data... ugh, I don't even want to think about it.
I set it up once, maintain it here and then, and am keeping it, because dismantling the system is more work than maintaining it presently, but seriously... with the above setup, do it only for educational purposes.
...I'm guessing I spent a week or so properly setting everything up.
...but I'm also willing to try a universal, one-size-fits-all program, if anyone knows anything for Debian?
I then decided to search for a big-monolithic-do-it-all-solution (from a SW-perspective) and the only option I found was Xeams ( https://www.xeams.com/Xeams.htm ) - I didn't find anything open-source. I'm using it (the free variant) since 2017 and it works.
Runs on Java, provides all services (smtp, pop3, imap), has greylisting, has embedded user administration, users can have email-aliases, has a web-admin-UI, 1-click-sw-updates, etc... .
pretty much a set & forget solution. He also writes a new one with all-you-need-to-know extras every time a stable release of debian comes out.
And you have to manage diskspace, backups, firewall/fail2ban, OS updates etc etc etc
I'm in the same boat as you. Managed to grind my teeth and pull through something like this for my own use and family, but it was painful.
I think really old droplets might have had them open though. I guess they grandfathered these in
[1] http://boston.conman.org/2018/01/10.1
[2] https://en.wikipedia.org/wiki/Greylisting
[3] And yes, I do run my own server. It's just for me, so I have no issues with "customer requests" and I've been using the same IP address for about a decade (maybe more). Then again, I've been running my own email sever since 1998.
However, ‘Hard’ is a subjective term. The deeper you are in a trade or the longer you have done it, the easier it comes to feel. I visited a family farm and found it very very hard to squeeze milk outta buffalo. My great uncle however has dealt with that buffalo that for years and didn’t sweat it one bit.
In a similar vein, do I really want to tend a buffalo in my backyard, when I can get the milk I need from a supermarket?
But I'd probably go with goats instead.
I don't think maintaining your own email server can be very fulfilling, but hobbies are a matter of taste.
How's that?
Raw milk from grass fed animals has a very different, much richer taste.
For one you can control what you feed your animals. The taste and quality of milk varies greatly depending on what they eat. You can feed them high quality grass, although in winter some cereals are fine. Anybody that drinks raw milk knows that the taste of what they eat really is reflected in the milk. E.g. if you let them graze on a field with flowers, it will have a flowery taste.
Leave raw milk on the table to turn sour and you get yogurt. It's quite good too. And you can't do that with the pasteurized milk from the store, it doesn't matter if it's whole or not, doesn't work.
Goes without saying that with high quality raw milk it's quite easy to make cheese too, which again, you can't with the milk your can find at the store.
As for why it's more healthy, the pasteurization process reduces the nutritional quality of milk. There are also weak indications that people with a lactose intolerance can tolerate raw milk better than they can tolerate pasteurized milk. It might be that it contains some lactase. Although this claim you should take with a grain of salt.
And in the US at least you can argue that the pasteurized milk you find in stores is ultra-processed. Read the following article:
https://www.latimes.com/archives/la-xpm-2000-aug-02-fo-62752...
Note that I'm not saying that you can't find a good source of raw milk from a farm with free range, grass fed animals and great quality control. But it's harder to do so and if you're living in the city, depending on the city, next to impossible.
I do encourage you to try find such a source. The difference in taste is well worth it.
And if you grow it yourself, it's much like anything else. For example tomatoes no longer taste well due to being picked too early. Grow your own tomatoes in season and the difference is night and day.
I'd also note that "pasteurization" can mean different things in different countries. In Europe it's usually more extreme than in the U.S., as the milk is heated ~60 °C higher for a shorter period.
[1]: https://www.healthline.com/nutrition/drinking-raw-milk#claim...
I'm in Europe.
> the pasteurization process reduces the nutritional quality of milk
It doesn't reduce the nutritional quality substantially though does it?
Europe Food Safety Authority advises to not drink raw unpasteurised milk due to potential health risks (http://www.efsa.europa.eu/en/efsajournal/pub/3940.htm) echoing what many national countries have advised "at a minimum, boil the milk before drinking it to kill potentially harmful bacteria"
Any perceived nutritional gain is marginal and is far outweighed by risk of illness.
If you wake up one day and the only email you can use is the one you can get from a major provider, you have just become a consumer.
A. Ideology. If the agent wants a different global equilibrium, they might decide that them choosing differently, (1) calms their conscience and/or (2) actually make a material different in the choices of others.
Yes, it is a similar result, but not the same. You give up a lot of control even using a smaller email service provider -- not the least of which is direct control of your own email data. Obviously, since it is email, there is nothing you can do about what others do with emails once they are received on their end, but it is still nice to have direct control of your side.
The counterpoint, however, remains valid. There is some work involved in maintaining your own mail server. If you use a provider, you don't have to deal with any of that -- it's always about tradeoffs. As the article says, however, maintaining your own mail server isn't as hard as a lot of people make it out to be. It takes a little of your time, but once you know the few things you need to do, I find it to not be a big deal at all.
Buffalo milking seems to be variously related to experience (see effortless squeezing) or Buffalo as a service ie. no buffalo on-prem or a backyard required.
I agree with this. I don't think mail is particularly harder than other serious Linux and network system administration tasks. But it does require those sysadmin skills, and it's not something I would recommend to a typical software developer unless they were interested in broadening their sysadmin skills or had a particular need that could benefit from a self-hosted mail server.
I've been operating mail servers continuously since 1992, so I guess that's the buffalo I'm milking.
Number of times I had this problem when running my own mail server (and presumably would have today): non-zero.
There's your entire explanation as to why this is a losing battle. Just one incident of an email delivery problem probably outweighs any privacy risk wrt using a centralized provider wrt email. That prior could change if there is a privacy related incident with these providers, but so far their track record has been good.
By the way, how many times did you get locked out of your Gmail account vs how many times did the same happen with your own server?
That's the part that I really don't understand. If the recipient hired someone to throw away their emails, why would that possibly be my job to rectify? I sent them a legitimate email, they hired someone who promised them to throw away spam, but obviously is incompetent at doing so, so it's up to them to hire someone else!?
Is it "up to them to hire someone else"? Totally. Will they? No. Your turn. Will you bend backwards to acommodate that client or will you drop it?
But, yeah, sure, I see the point--but my impression is that people automatically see it as their responsibility to figure out why someone else's email provider is throwing away their emails, regardless how much you depend on them.
I eventually caved in and switched to fastmail - and everything is good since then.
Google is giving you no trouble because the main instigator of trouble these days is google.
You may find it acceptable to use them with this in mind. I do not.
In any case, this is a argument as to why it's an uphill battle to convince people that running your own server is an easy endeavor. (Which seemed to be the point of this post.) It says nothing about switching off of gmail to another provider as you did, or if the actual burden of running a server is worth the privacy trade-off for an individual (i'd argue for most it isn't, but wasn't really the point i was trying to make.)
Switching from Google to another 3rd party provider doesn't eliminate privacy risk, it shifts around the probability distribution for certain kinds of events to occur. (Arguably, so does hosting your own server, but hosting your own server does rule out large classes of failures.)
This is incorrect. By using Gmail you've lost several legitimate incoming emails due to their horrendous spam filtering. It's just hard to be aware of the emails you've never seen, so you think nothing ever failed.
In addition, if you are relying on @gmail addresses, you run the catastrophic risk of permanently losing access to your email with no-one to call for help. There's so many instances of this happening that you can't even call them isolated instances. All it takes is for Google's ML algorithms to think that you have violated their T&C somehow. And poof! Everything is gone.
Gmail randomly filters github commit emails into Spam for us. It randomly filters messages from our own hosted domain, that pass DMARC into Spam.
As far as false positives go, for me, Gmails filtering is crap. Much worse than an untuned SpamAssassin setup.
They have crap filtering, a crap web UI, and crap mobile apps. And yet people still use them.
I'm still amused that back in October 2017, a commenter (lucb1e) argued[1] that I was exaggerating the difficulties of reliably sending email but a year later in 2019, he confirmed the same difficulties![2]
The discussions in that thread (May 2019) and today's HN thread (September 2019) contradicts author's claim that mail stopped being "hard" 10+ years ago:
>Another reason is because it used to be hard a long time ago. [...], citing the very real difficulties they faced over a decade ago,
Hosting your own email is certainly not impossible and lots of people are successfully doing it. (Or they they're actually not successful because their outgoing emails are sometimes getting silently spamholed without them realizing it.) In my case, I'd rather expend mental energy on other pursuits (machine learning, learning Swift language, etc) than constantly worrying about a personal email server's "reputation health" and then debugging whatever goes wrong.
That's true but I think if we analyze discussions (see this thread and old threads I cited) of one group of HN experts (email is "not hard") debating other HN experts (email is "hard"), the most contested issue isn't the difficulty of advanced SMTP features and enhancements -- it's about outgoing sent emails being reliably accepted.
Edit: I also very much like the disingenuity of articles saying 'X isnt' hard! Just execute these 20 commands!' Duh, executing those commands isn't the problem, it's knowing which commands to execute, and the pain of having to figure out the new commands to execute 4 months later when for some reason something broke and now 20 people are twiddling their thumbs until you fix it. Screw that, running email servers is a horrible tedious pain in the ass you should almost never do yourself unless it's the sort of thing you enjoy (I've run Postfix, Qmail and Exchange servers from the mid 1990's until mid 2000's).
If you’re already basically competent with the OS you’re using and have a machine with a decent connection that can be used for mail then it actually isn’t hard.
I cannot claim prescience, because I started ont the trade when sendmail was THE mail program (though ed was no longer THE text editor): but consider, had I listened to the sendmail bashing crowd a couple years later I would have gone qmail (!!!). For not having done that, I thank the almighty weekly.
That would work if mail providers actually used Sieve, but almost none of them do. I've never understood why.
Can't tell if you're serious or not - but if you are, just looking at man sieve is enough to understand why no sane person would give an average end user access to that. I mean I used it for many years but I'm a nerd weirdo.
You don't have to force an average user to hand edit Sieve files. You can put the same kind of GUI or web interface on top of a Sieve file that current mail providers put on top of whatever hand-built custom non-standard filtering rules system they currently have. To the end user it would look the same.
But for an end user like me, who already has a huge number of filter rules expressed in Sieve and would like to be able to upload them to an email provider, not supporting the Internet standard format for filter rules is a showstopper. I don't want to have to re-input all my filter rules into an email provider's web interface one by one. I want them to be able to understand the rules I already have in the Internet standard format I already have them.
From a quick google, there does seem to be a Roundcube plugin for managing Sieve filters, but man yet another dependency (or two, as it seems you need a separate daemon as well) in an already brittle (by the time you get to this point) stack...
Look, I understand where you're coming from, and I used Sieve for many years, but it's 2019 - something is not an 'Internet standard format' when the number of users actually using it can be expressed with 4 or 5 digits at best... This horse is not just dead, we're snorting its ground up bones by now. Nobody caters to power users any more. Back when power users made up a sizeable portion of the internet population, yes, but not in 2019...
Well, there is no other standard format at all, so basically you're saying we might as well just give up trying to have an internet standard for email filtering. That doesn't seem like a good outcome to me.
Even if I'm way off base about the mail server set up being this way, some people still consider this type of "saturday afternoon" project hard compared to something that just works out of the box without any fiddling and can be set up in 20 minutes. I'm not trying to be elitist by suggesting these people are dumb or lazy, just that the semantics of what "hard" is varies for people, especially with little projects that require fiddling/tweaking/looking for outside help.
"OK, then why is everyone saying it’s hard ? [...]
Another reason is because it used to be hard a long time ago. People got traumatized by how hard it was to not screw up and never reevaluated the situation. Some people today genuinely discourage other people from running their mail server, citing the very real difficulties they faced over a decade ago, far before some of today’s tools even existed."
The same can be said "why should I grow my own veggies when I can buy them from the supermarket?" - The point is always, always, about Freedom.
If you were running your own restaurant and your home grown vegetables caused a worse customer experience would you do it? Running your own mail server which causes more of your mail to go to spam is worse than using a commercial provider.
^ I both run my own mail server and use someone else's service for another purpose. My experience running my own mail server is objectively WAY BETTER than using the commercial provider (and I've been doing this for many years in multiple scenarios).
Just because your experience (even if it is repeated) with certain technology goes one way, that doesn't make it universally true.
Of all the questions I have to answer on technology decisions, why would I want to answer why did I choose to run my own bespoke mail server instead of spending a few dollars and making it someone else’s problem and so metaphorically chose IBM - ie “No one ever got fired for buying IBM”.
You made the point.
Isn’t that an argument for why you shouldn’t run your own mail server?
This is false. The dmarc reports from Google do not actually give you the portion of email that is placed in recipients' spam folder.
Do you ever read them? If so, how is daily (!) routine maintenance of your email setup not a massive (well, relatively speaking) headache?
"The dmarc reports from Google do not actually give you the portion of email that is placed in recipients' spam folder."
So it is just about the server and and dns part (the things I as an administrator can control)
Since I configured it in the beginning the reports are all green so I just glance over them. Takes about 10 seconds.
Then again I like to work with infrastructure so your mileage may vary in regard to how much headaches it causes
This is such a canard. I have almost zero problems delivering to anybody from my closet server, and the only thing that has happened in the last several years was getting notices that AT&T was blocking me. I did a quick relay check and emailed postmaster@. It only took a day or two to get an email saying I was clean to them again, and that was without the DNS security extensions you mention.
Maybe cable modem users are held to a different standard? Dynamic IP addresses? I have DSL with static IPs.
These days (for a long time now, really), it's hard to set one up that's, say, an open relay by accident. The default configs are pretty much all you need, just replacing a couple of values with those that are custom. Basically, what you're saying is exactly what they're debunking. Also, the article isn't "just execute these 20 commands", it's deliberately non-technical.
I've been running a tiny Postfix mail server since ... 2000 or so, still doing so today. It had grown in to a bit of a monster configuration over 17 years or so, complete with a custom PHP interface to allow me to add user accounts, etc. I learnt a lot doing that, but a couple of years ago I started it all from scratch, with a default config and writing the config into my ansible setup so I don't have to remember it. It was very easy to do. Since then, I've touched that configuration once.
One thing I will mention because I haven't seen it around enough, and didn't know of it until someone said it in passing: if you're getting smap-trapped by gmail a lot, turn on TLS support for outgoing. Made a lot of difference. For postfix that's just adding:
smtp_tls_security_level=may
to main.cf. Don't know why that isn't default.
Martin Fowler said something in a talk a few years ago[3] and I think it speaks to this exact mindset. This post is lacking any economic reasons for people to run their own mail server — tell me why me running my own mail server saves me time and/or money.
As another tangent, I'm actually looking at running my own mail server. For me, it's privacy which coincidentally is not even mentioned once in the article.
[1] - https://github.com/toptal/gitignore.io/issues/369
I've been running my own mail server since 2000 or so. It isn't hard, it takes almost no time at all, and I have my own independent mail that nobody reads, and I make the decision of which mail to accept.
I will take the liberty of classifying the above comment as FUD.
Otherwise your mail is read in transit on the way to you anyway, so self hosting is false privacy.
> - Mail is not hard: people keep repeating that because they read it, not because they tried it
No. Been there, done that. It was a major PITA. It's not even something I would consider again for small organizations as it's an economic nonsense too.
Moved everything over to Fastmail about a year ago and haven't looked back. My inner geek still feels bad about not doing it myself but my rational brain is happy.
Now, there are many solutions that with 1 click do all the painful integrations.
https://mailinabox.org/, https://mailcow.email/, https://iredmail.org/
So please, everyone, stop saying mail is hard now when you don't have any recent experience. A lot has changed in 15 years
If I fail my outbound email setup, it can be months before I realise that most of my emails have been getting dropped. Total cost: I depend on email for work and family, so very high.
I used to host my own email. Tested with gmail: delivery was fine. Half a year later it turns out Hotmail was silently dropping my mails. I felt betrayed, and learned my lesson: email is hard.
My consultancy handles "all things technology" for multiple small businesses (sized 1-50 people, located mostly in South Asia). Anecdotally:
A lot of these folks are happily using mybusinesname.accounts@gmail.com and so-on, but decide to get their own domain for the added veneer of "professionalism".
Many are happy to use Yandex (1000 users with your own domain for free @10GB/inbox. Probably not appealing for some Americans given US-Russia political issues).
Startups/sole entrepreneurs typically come to us after they've purchased a GoDaddy domain and selected the "Business Email" option upon checkout, so they just continue using it.
There's a small sample of companies who are willing to pay for Google Apps because they like Gmail's web UI, and they want the rest of the Apps Suite too.
We also deal with a lot of local big corporations for project work. They're almost always using some kind of in-house corporate email system running Microsoft Exchange Server with a number of different rules like no attachments over 5 MB and other such silliness.
For us to invest time in setting up a mail server for a customer there would have to be a very rare confluence of:
a) I don't want Yandex
b) I don't want to pay for Google Apps / Zoho / other
c) (Optionally) I want to send 500000 marketing/transactional emails per day but I don't want to pay Sendgrid/Mailgun/Mailchimp/SES
To set it up we'd have to establish pricing and SLA. Would I agree that we do it for less than $5/user/month? Nope!
I can't really see a compelling case to do it unless you're a hobbyist with strong philosophical perspectives on this topic. Maybe my point of view is different because of Geography but I doubt things are very different elsewhere in the world as far as cost/effort is concerned.
The easiest way to do it is to buy an email server, you can use Exchange or you can use something like iMail or Kerio.
Install that on a server, get a static IP from your ISP, put the server behind a firewall, and point your DNS servers for your domain to it. Then generate an SPF record, and you should be good.
That's how many people do it. As a bonus, you don't need to pay $10/user per month for hosted mail, or deal with Exchange licenses, but you will probably want to back the server up from time to time. You even get webmail with it!
The advantage/disadvantage of this setup is that it's now up to you get to get yourself off spam blacklists and such. When BIG_EMAIL_HOST is having problems, there's nothing you can do but wait. But with your own servers, you are the one who gets to email the spam department of BIG_ISP to request removal, and then there's nothing you can do but wait.
If you know Linux, you can setup Postfix, but I did say 'the easy way'.
Setting things up is actually the fun, easy part.
I haven't actually had an ISP block me yet, but I also run my mail server from a VPS, so I don't have to send it from a residential line.
E-mail servers are complicated. People with skills and interest can do them, no problem. It's not overly hard. I agree with that.
But I sure don't go recommending it to my friends who wouldn't appreciate spending a few days learning and setting all that up.
What I can do, however, is offer them e-mail accounts! So I guess as long as every group of 50-100 friends has one person willing to run an e-mail server, then we're all good. Of course, it'd probably be a pain to switch when that person dies or loses interest.
Maybe we just need to make it really easy to have a email@myname.tld that is portable and easy to move around.
It’s not “hard”, but there are servers who will not accept a single message from you, rDNS, DKIM/SPF be damned. And there’s fuck-all you can do about it.
If enough users complain, they might change their policies. Ehh, wait, we talk about Verizon here.
Don't bother.
If you are self-hosting the most important authentication fallback for your online identity, an ill-timed downtime or deliverability problem really hurts.
Your reputation can be affected by neighboring bad actors you have no control over. For example, SpamRATS punishes full subnets without an actual appeals process.
From the point of view of a major provider, the same email from your tiny server is going to have a lower score than one from their system. Encountered this a lot against Gmail.
And it's a commitment. If you go the self-hosted route, you will need need to keep up on new security and filtering practices, even if you use a turnkey solution. You might get bored with this after a while.
(tagline: "Take back control of your email with this easy-to-deploy mail server in a box.")
I haven't uses it for a while, but last time I wanted to setup a self-hosted server for a domain, this came out the best. (I've handed over the task to somebody else, so no idea how it went.)
Mail in a Box makes it seem passably easy to someone with basic skills to get everything up and running, but then don't support in-place upgrades of the underlying operating system. This might be fine, but I really hope people realize what they're getting themselves into. https://discourse.mailinabox.email/t/mail-in-a-box-version-v...
This critique is somewhat shallow, if the backup/restore option is easy enough. But I just have a hunch there's going to be a lot of non-upgraded boxes running fullstack-EOL everything.
Of course, a system that does in-place upgrades and then fails is going to leave no-one any happier either.
I guess that my point really is that appliances requiring "complicated" upgrades by moving to a new OS install aren't all that mature. But I acknowledge I have a hard time determining who this product really is for.
If your not in the busines of setting up mail servers every day: Mail is hard. As long as there is no download-and-run-solution for a mail-server: Mail is hard.
The author of the post just explained how most of his friends think this is hard. I don't think email is very hard. But the ROI of doing this in-house is insanely terrible.
^ this is far too much of a blanket statement. I've done it, in house, for both personal and work purposes. The cost in my time was not very high, and the ROI was very good.
Obviously there is a much broader range of experiences with managing your own mail server than many on this thread think there is.
I never got spam filtered once DKIM/SPF/rDNS/DMARC were properly configured. I think _this_ is the myth that Big Email spreads. Linux mail servers are hard, but getting past filters is actually not hard. Spam filters are really good today not just in their true positive rate but also their true negative rate.
Given that a lot of services use your email as a 2FA mechanism, I wouldn't want to use a self-hosted mail server as my _only_ personal mail. You have to have a good reason[1] to make the time and maintenance commitment.
[1] https://en.wikipedia.org/wiki/Hillary_Clinton_email_controve...
https://news.ycombinator.com/item?id=19945846
That's a super high value domain (facebookmail.com) with perfect config getting filtered as SPAM by Google.
If you google, most of the top hits are for free mail forwarding using your domain registrar. I tried this and it was pretty terrible with a ton of caveats. For example using namecheap you can only receive but not send from that domain, can't receive attachments, and can't even send an email to yourself for testing purposes.
I think the easiest way is to pay GSuite $6/month?
- pay someone to send and receive your emails (eg. update your MX records to point to gsuite, fast mail etc)
- host your own mail server (something like http://mailu.io/ will work), basically you’re going to need a program that listens for and stores incoming emails, and a program that sends them, plus all the glue inbetween (IMAP, pop3, webmail, storage etc etc)
If you’re going for simplicity, then the first option would be the easiest. I think Zoho offers this for free for one address, and it works just fine.
That what you're looking for?
2. buy fastmail subscription
3. set domain nameservers at registrar to point to fastmail
4. setup domain on fastmail, setup email on fastmail, setup aliases (you need to pay for extra subscriptions to have separate mail users; i think same applies with gsuite).
Thunderbird org should create/sponsor its own email server software.
That's the way to spur email development by causing development on both sides of the chain. Sometimes in unison.
And they should also initiate an email service to put their development in action.
Imagine the innovation that could happen then.
- Email encryption standards for key acquisitions
- folders/labels stored as imap keywords
- large file sending protocol using third party services
- msg retrieval when email severs experience outages
- development in mail list servers.
I'll also point out:
> - Email encryption standards for key acquisitions
This is basically a standardization problem. I've been involved in at least one failed attempt at standardization here.
> - folders/labels stored as imap keywords
The difficulty here is knowing when you can opt-in to this functionality, which is again basically a standardization process.
> - large file sending protocol using third party services
Thunderbird already supports this, and has for... 7 years or so?
> - msg retrieval when email severs experience outages
If I understand this right, this is basically having your MUA duplicate emails locally... which is what most MUAs do these days (at least on desktop).
> - development in mail list servers.
What development are you talking about? Mailman is pretty actively developed, they even had a GSoC project a few years back to add encrypted mailing list support.
IMHO, the most important thing missing right now to promote more decentralzied mail is a cometivtive open source mail (web) app, with a simple UI and a vibrant plugin system for every use case.
Yes, this is a big deal. So many web applications provided by companies as "cloud services" are orders of magnitude better than equivalent web applications you can run on your own damn servers.
The potential impact of one email I send not being received is absolutely enormous to the extent that certain mails I'd pay a decent amount of money to ensure delivery, probably more than an actual postage stamp.
“And by all means, we must not push everyone to use Big Mailer Corps“
which is totally fair. For the rest of the article though, it’s pretty clear that the author does admit caveats where any business would have to spend time & money figuring stuff out. And the fact is there is no real cabal of Big Email, it is such a commoditized industry. As a business you pay a pittance to protect downside risks, it’s a no-brainer.
I've been running SmarterMail on a Windows VPS for years and it's been rock solid. It's just a single Windows service and all the configuration is done via its web interface.
Why no one has come up with a simple solution like this for Linux/BSD yet?
"It's way too hard" is a HN meme I've noticed regularly. It's really not, if you have any tech skills or the willingness to learn.
I set up my email server in two days between jobs in 2011 and it's been running with minimal attention ever since. I don't have precise numbers, but to try to give some context I'd say about 2-4 hours a year worth of maintenance.
Over the years I've expanded it to handle a few more domains (consulting companies for self and family members). No issues.
To anyone even slightly interested or curious in the technology, just do it. You'll gain some freedom, gain some experience and help (even if just a grain of sand) decentralize the Internet. Don't fear the naysayers.
In general : computers don't solve the issue of trust. End of story.
If the suggestion is, why not give it a try, one thing I feel is missed is, how hard is it not just to set up but to run over the long run, when the technology evolves and you have to keep up, and why would any IT manager or CIO want to gamble their careers on this?
There are a bunch of guides floating online for Postfix, Dovecot etc, and some of them are pretty decent. But they go out of date quickly, or if you want to do something slightly different, you're on your own... And even if you end up with a running system, maintaining or enhancing it is a different kettle of fish. You can't just follow the guide again, you're back to man pages and usenet mailing lists with some info inside a thread 23 levels deep.
And knowing it is still being long way from running an effective mail server.
TFA is on par with this.
Unfortunately this is not a myth. rDNS/DKIM/SPF/not in any greylists, but mail from you goes to Junk folder on GMail®, experienced that myself.
The bigger mail providers (such as Gmail) are pretty strict on checking, and feedback is fairly limited. Thus, figuring out why you were flagged as spam is often difficult and frustrating.
There are so many subtle misconfigurations you can make with the way you have your DNS records set up, but really you need DMARC reports to figure out why your email is getting flagged.
It inspired me to build my startup :) We have successfully fixed dozens of email deliverability issues for our customers.
It's annoying that the default settings of almost all mail server software are suboptimal, but once I set it up correctly (yes, that took some time but nowadays there are plenty of tutorials) I had to do almost no maintenance at all. Apart from power failures that were unavoidable, the biggest issue has been spam blocker lists becoming outdated or going out of service. After that, the occasional hickup after a dist-upgrade or moving to a different country. But on average, my mail server is working perfectly fine 364 out of 365.2425 days. And, this is considerably better than the mail servers at the universities and companies I've worked at. Your Gmail might have given you no problems, but it is not working 100% of the time for everyone either.
So I'd say maintaining your own mailserver is as hard as painting rooms yourself, or changing the battery or light bulbs of a car. Not everyone wants to do that, and that's fine. If you're not afraid of it, it's a rewarding experience.
Actually I repeat it because I ran mail servers for years, for personal use, for small businesses, for large businesses.
It was hard because spam was difficult to deal with, I don't know if that's gotten easier. It was hard because managing mailboxes, spam boxes, whitelists, webmail, etc for users was non-trivial. It was hard because occasionally you would be blacklisted and it took days to un-blacklist you, either from a spam list, or from a "big provider" because for whatever reason they just didn't want to take your mail. It was hard because you couldn't just run an open relay on most ISPs, you usually had to use your ISP's relay, and thus suffer their own issues; if you used commercial IP space that was less of an issue. It was hard because it had to be secure, and follow standards. It was hard because as your own hosting provider, you had to do all the things providers do: have a stable connection, manage your DNS, do backups, manage configuration, upgrades, patches.
We're not trying to bullshit you. We did it, and it was hard. Maybe it won't be for you, or maybe the "hardness" is just fun for you. But it's not a myth.
Over the years, a new exploit type comes along, like backscatter, that I then have to figure out how to secure my server against. And I'm also very proactive at reviewing logs and banning IP's against the constant barrage of probing. I must spend a few hours a week dealing with the mail server.
And then there are periodic "someone isn't getting my mail" problems that I have to track down, where Yahoo or pacbell.net or some other large mail system decides that my server is insecure for some reason, despite not being on any DNS RBLs (which are also sometimes a problem for no good reason).
If it weren't for the fact that I have so much more flexibility and ease-of-use on my own mail server for setting up many domains and multiple email addresses, I would move everything to a provider and not manage it myself.
This is absolutely not true. A server I had mailed out daily run outputs to local users, and was also configured to send an email to one of the users' gmail accounts. I also used that server for personal email, but eventually had to stop because the daily run outputs got us blocked by gmail.
Are you sure? How many tens of thousands of daily run outputs were you mailing?
And, yeah, don't tell me that delivering is easy. I did everything right, DKIM, SPF, PTR, all those things. No black lists. Gmail still does not deliver my mails sometimes.
I felt vindicated, giving up self-hosting of email and pushing it towards a third party provider because I was concerned about backup/disaster recovery scenarios. When something fundamentally shakes up your life - you might not have the ability to function well and managing a mail server is a stress you could live without.
Admittedly my main problems were with people on Microsoft hosted emails. They seem to run some kind of IP address based blacklist-by-default operation. My emails to Hotmail/Outlook.com users would randomly get either rejected or go straight to spam.
I went through countless online forms, Twitter conversations with clueless CSR’s who kept asking me what Outlook client settings I was using, and finding random people on LinkedIn I could message.
In the end the solution that seemed to work was to reach out separately to everyone I was sending an email to on Hotmail/Outlook.com and getting them to explicitly mark my email as not spam. After a while it seemed to take and stop rejecting/marking my emails.
Deriving a large part of my income by supporting Microsoft software in small business environments, I have been running Exchange versions all that time. I have enjoyed Outlook as a primary business tool, and looking at the conversion strategies to move over to a *nix mail server that will support that client and the 25 years of horded emails I now store (don't mess with my jokes folder, dude) has been the most daunting part of it.
Even though I have been on Debian releases as my primary workstation OS for over 12 years now, I still have virtual Windows sessions to keep using Outlook. And granted, that also lets me simulate what my clients "see" when I am assisting.
Unless he's talking of a one mailbox server, accepting outgoing only from localhost and somehow endowed with a non residential ip (or good luck with rdns, rbls, etc.). But that was always trivial, post UUCP era.
Background: I've been running mail servers from 1996, several different MTAs, for my company and for customers. Getting the thing up and running is not (very) hard -for a primary MX net facing machine. That's where work begins though.
My primary MTA is still sendmail, and sendmail.cf was never one of my problems - I do not have a degree in compilers, whatever that is, and surely I never read sendmail.cf
I finally ditched gmail once I realized how politically motivated Google was, and I also realized that I’d rather have a company owe me the service rather than using a free one where they could technically disable my email at any time.
I agree but don't say it isn't hard. It's hard and it's not for everyone but if you can the benefits are worth it.
Now I don't think having more small mail servers will stop big mail servers abusing their power but without a significant number not small servers better just give up.
For the record I do have my mail server on a vps
To be honest it wasn't that hard doing it myself, but it broke 2-3 times over that number of years when providers changed their delivery requirements (see DKIM, DMARC etc). It was never something I enjoyed troubleshooting.
* CVE-2019-11500 : Critical Dovecot and Pigeonhole vulnerability (https://www.openwall.com/lists/oss-security/2019/08/28/3)
I still run my own mail server, but I hate having to keep up with these security vulnerabilities which can come up at the most inconvenient time.
That tweet is way too hard for me.
After countless attempts to fix that or to understand why Google think I'm spamming I set up my own mail server on DigitalOcean Droplet. I used mailinabox and the setup was a piece of cake. it works flawlessly now.
* setting up gitlab ce is easy
* setting up LE certificate is easy
* setting up wordpress is easy
* setting up mail is easy
If at some point in the future any of the first three stop being easy in an obvious way, there's a whole team of developers who will work hard to restore easiness.
That's quite different from a blog author shrugging because their configuration-in-a-tweet is obsolete in three years.
I invested 3 hours of time setting it up, $4/month in hosting, and now I have andrew@ziglang.org as my main email and have never looked back.
Disclosure: Google employee. (I do not work on anything related to mail.)
For example, adding 2FA to your users, monitoring access, spam detection, etc...?
I like to write software. I don't like running a Linux server, although I know that i could learn to be an excellent admin. It's just that every second I spend learning Linux admin, is a second I'm not spending learning Swift.
So I just use shared hosting for my sites; even though I'm perfectly capable of running a VPS.
He would much rather hand his boss - the founder - a bill than have to explain why our server went down.
Don't get me wrong, if you choose your partners carefully you can make this work in many (probably most) scenarios, and save yourself some headaches in the process. But even with the bigger players (like AWS), there is a tradeoff to handing such things over to someone else. Services aren't always as reliable and partners aren't always as resposive as they are advertised.
I totally get why people don't want to do such things themselves. I just think it is important for people to realize that doing so has its own set of consequences and risks that they should be aware of. I suspect most of the folks on HN are aware of this, but there does seem to be an awful lot of "it would be dumb to do that yourself" sentiment here.
AWS is a lot more reliable than almost any in house solution. As far as being responsive, if you have a business support plan with AWS, you can always reach live, helpful support. Trust me, being on the Dev side, when I need resources on AWS, it’s just a click, script, or CloudFormation template away. Getting resources provisioned through the infrastructure gatekeepers can literally take weeks.
And just from the CYA standpoint and “no one ever got fired for buying IBM”. If your colo goes down everyone looks at you crazy and you have a lot of questions to answer. If AWS goes down and you took the appropriate steps at least making your infrastructure AZ redundant if not multi region redundant, it’s going to make news and no one is going to question why you chose AWS.
I simply said that I don't run my own server because I'm not comfortable being an admin; mainly because a part-time admin (which is what I would be) is a dangerous thing.
It's bad for a Linux server to be run by an incompetent admin (that would be me), and even worse for an email server to be run by one.
If the author is arguing that 'mail is easy now' you can't make that argument without addressing the security aspect. I hate google and I still use gmail because their project zero team is so good.
Big consumer tech companies are finding their own ways to make this argument: apple with privacy, google with security research, even facebook with providing better privacy controls, although this isn't in their DNA and they'll fail. More products are supporting MFA/FIDO now.
If 'mail in a box' etc are going to convince me to self host (which I would love to do), security is the missing piece.
If you treat it like a pet, it makes it a lot easier to manager. "Oh, did I forget to check the mail logs this week", and so on..
Load time is under one second, not sure where the salt is coming from.
And if I need a Google/Apple email for usage on my phone, I'd rather just use that one instead of hosting my own email solution.
This is without even considering the fact that configuring email is not as trivial as say, setting up a website. And you're never going to get spam filtering as good as the Big Email corps.