It looks to be a static site generator. It's surprisingly easy to weather that storm with a simple web server + static sites, it's dynamic sites using Wordpress etc. that have the most trouble.
To this day none of the mail servers I’ve setup can send to verizon.net.
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.
It's not 'hard', it's 'a gigantic pain in the ass' which is (in normal word use) one form of 'hard'. Which is why most sane people stopped doing it themselves say 15 years ago. Especially for the few cents you can get professional 3rd party email hosting for.
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).
Eh, it used to be pretty bad but the other year the people from the openbsd project wrote a new mail server with a trivially easy to understand config file (I wrote mine from scratch just a couple hours after finding it.)
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.
The config file format is the least of your worries (unless you're running Sendmail, ofcourse). It's about havimg to know about DKIM/SPF/dns weirdness/ etc, and having to stay up to date; about blacklists and greylists and the social dynamics around it; about mailbox storage and backups and users complaining about quotas and attachment sizes and that sort of shenanigans; about how will I let my users set auto responders and filters etc (just send them a link to the sieve man page! Lol); about having to worry about being called over the holidays because every custom server has its own peculiarities. And his talk about 'it used to be hard but not any more!' - yeah sure, just like the dozens of times people said that over the last decades? There's a 'year of Linux on the desktop' analogy in here somewhere.
Yeah, that's the folk wisdom on sendmail. But really, since version 8.0, writing your own .cf (or reading it) should have been regarded as bizarre as crafting your own object files with an hex editor. And sendmail has served me well, over the years; its scariest feature (sendmail.cf) is also a strength - as a Turing complete programmiong language, it allows you to tie your incoming/outgoing mail in square knots, if you feel so inclined, or to solve some unforeseen mail routing configuration/problem/whatever. Of course, if you find someone that has gone to the lenght to write a _LOCAL ruleset that does it - and alas that is a creaft I do not possess, and is dying out. When it does, I will probably make the postfix jump.
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.
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.
> just looking at man sieve is enough to understand why no sane person would give an average end user access to that
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.
" You can put the same kind of GUI or web interface on top of a Sieve file"
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...
> 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
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.
Config files really are not the problem with running email. The "why the hell is provider/BigCo/... XYZ rejecting our emails again" dance is, with the answer typically being "no clue, they certainly won't tell us, let's hope it works in 48 hours?"...
People also have different ideas of what "hard" is. I've never tried setting up a mail server so I'm talking out of my ass a bit, but after reading the article it sounds like you'd need to do a bit of googling/trial and error changes to get things set up, probably one of those projects that would take up most of a saturday or at least a saturday afternoon and might run into some hiccups every few months that requires more googling/tweaking.
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."
How does running my own mail server save me time, money, or give me capabilities that I don’t have by paying someone else? What other criteria should I use?
When you eat home grown vegetables, the experience isn’t objectively worse. When you run your own mail server it is.
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.
"When you eat home grown vegetables, the experience isn’t objectively worse. When you run your own mail server it is."
^ 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.
It’s not “just my experience”. It’s practically a universal experience that the chance of emails sent from your mail server will be blocked or go into a spam folder a lot more frequently than using a commercial provider.
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”.
This. Even running your own IRC, while not "hard", is a PITA enough that companies will shell out a chunk of change to have someone else do it for them. And, they may even get better features as a result.
There's also a huge difference between setting up a properly configured server and actually getting things delivered. The big ones (MS, Google) mark your mail as spam even with SPF, DMARC, DKIM and the like. Even on the service I use (purelymail.com) the low volume of mail and the fact that it's less than a year old means that even when I email them first, the replies are sometimes marked as spam.
Running my own for about 2 years now. Spf dMarc and dkim set it is accepted by all mail providers. I also get daily reports from Google how well it behaves
Same here, except to Charter, who has apparently just blacklisted swaths of DigitalOcean IPs, probably for some reason. So I just can't email my mom. Other than that, a great experience.
Well I just have to do the one more step of forwarding the SMTP to sendgrid or whatever and then it will be top notch. It hasn't been enough of a pain for me yet to do that next step. I just signal her instead of email.
> Running my own for about 2 years now. Spf dMarc and dkim set it is accepted by all mail providers. I also get daily reports from Google how well it behaves
This is false. The dmarc reports from Google do not actually give you the portion of email that is placed in recipients' spam folder.
The big ones (MS, Google) mark your mail as spam even with SPF, DMARC, DKIM and the like.
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.
The article points it out, but it used to be harder than it is now.
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:
So despite your claim that it's 'very easy to do', in the very next paragraph you are basically saying that you need to be around people who 'mention in passing' obscure details of email server configuration, otherwise it will 'make a lot of difference'? I mean it seems you disagree with me at first, but then in the rest of your post you seem to be making my point for me, so...
I totally agree with this and this is actually something that my Engineer Brain and Product Brain are constantly in conflict about. I ran gitignore.io for 6 years and it was not "hard" to run. It was two commands on a web server. The problem was when I was on vacation or at work and AWS/Heroku crashed and I got flooded with GitHub issues/Tweets telling me the service as down[1][2]. All of a sudden, I have to go take a look.
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.
> it's 'a gigantic pain in the ass' which is (in normal word use) one form of 'hard'. Which is why most sane people stopped doing it themselves say 15 years ago
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.
Incidentally, it is threads like these that make me regret posting anything on HN. Respond to a vaguely worded FUD with a specific first-person example (of doing something for almost 20 years, no less), and get downvoted into negative territory.
> - 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.
Amen. I ran my own personal mail server for ~15 years (started with qmail+squirrelmail, moved to postfix+dovecot+opendkim+zpush+roundcube at some point). I enjoyed it but eventually just didn't have the time to care anymore.
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.
No mention of RBL? Thats what makes running a mailserver cumbersome - being put on an RBL because of bad neighbours in your subnet and your emails silently failing to deliver because of said RBL.
It's a bit of a black box, but how do you get around this? Is it a matter of domain age? IP trustworthiness? Or do a lot of people have to categorize it as "Not spam" first?
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.
I think I more understood the ethos of where the author was coming from at the end:
“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.
Let's see... Postfix, Dovecot, SPF and OpenDKIM on the server-side, each of them with their own config.
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 run my own mail server and as long as you use TLS and the one that’s really easy (I can’t remember if it’s DKim or Dmark) most domains accept mail from you.
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.
What do you use for automated messages (ie, login emails, password resets)?
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.
And Postifx is not just one thing, it's: smtp, smtps, submission, relay etc... And Dovecot: pop3, pop3s, imap, imaps, lmtp, passdb, userdb, sql, ldap, seive etc.
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 used to run postfix/ssmtp/etc on Gentoo. From time to time, when updating the single components, something stopped working and then I had to quickly debug and find a fix. In the end it was too much time-consuming for me to maintain.
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... .
I run my primary mailserver on DigitalOcean.
It seems to work fine. I think you have to have either your account, or the Droplet, active for 30+ days before they'll let you have port 25 open.
Trying to avoid the landmines of blacklisting is really the biggest peril in all of it. I refuse to move a company I support away from GSuite to self-hosted, because I have a high level of confidence that just one person sending a lot of mail to another person outside the company could result in our domain ending up in RBLs, which is very difficult to reverse. Running a mail server in 2019 is not something I need the headache of.
And RBLs aren't that great. I visited this in January of 2018 [1] and in my case (where I do greylisting [2][3]but nothing else for spam) it wouldn't help.
[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.
https://mailinabox.email/ does everything and more. Of course, this doesn't make it easy. You still need to do more things than were you to simply use protonmail/fastmail/etc.
I think the biggest pain in hosting your own mail server is getting your outbound mail delivered into the mailboxes of the large providers without being marked as spam. Especially if you don't actually send a lot of mail, so you can never really build up a good IP reputation.
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.
The article handwaves this by pointing out that it’s “proof-of-work”. Which is a fancy way of saying “it requires a bunch of work, continuously as the rules change over time”.
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.
It would be nice if these big mail services accepted actual proof of work as a way to guarantee that your mail gets through. Maybe someone could extend SMTP with a bitcoin-like challenge where the server sends the client a nonce and a difficulty factor, and the client has to reply with a suffix that you can append to the nonce so that the whole string hashes to something with the corresponding number of zeroes at the end. People sending personal emails will be happy to burn a penny of CPU time as "postage" but spammers won't be able to send their spam profitably, especially if you increase the difficulty factor based on how many emails you've sent in the last hour.
> People sending personal emails will be happy to burn a penny of CPU time as "postage" but spammers won't be able to send their spam profitably
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.
(Note: deleted and moved here because I put it in reply to the wrong comment)
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.
Sure, I do this. A lot of stuff people buy is often a lot cheaper with promotions. Just the other day, I bought a $600 set of tires for $300-380 (depending on whether or not I remember to do the mail in rebate). That alone is well worth the few clicks it took to filter mails from that list out of my inbox and into a label for car-related marketing.
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.
One of the big corner cases I've noticed is transaction-oriented email-- the password resets, "welcome to your account" emails, order details, shipping notifications. People want these, but they're probably harder to deliver than personal email or much spammier bulk mail sent directly via outsourced experts.
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 paper's argument assumes that the PoW scheme is required though. It could be an option which just guarantees that individual mail can get through, while still keeping the usual reputation-based spam filtering for clients which don't want to participate.
If there's one lesson from the history of spamming, it's that spammers are among the fastest adopters of anti-spam technologies. If PoW meant that spammers could only send 1/100th the email, but the email was 1000× more likely to actually show up in an inbox, spammers would jump on it in a heartbeat.
The value to spammers isn't in email delivered, it's the actual user engagement at the end of the process. A million messages delivered to the inbox is worth far more than a billion messages delivered to the spam folder.
Yeah, but if the marginal cost of the next message is higher than the marginal expected increase in revenue then they won’t. It doesn’t matter optimizing inbox delivery rates if per-delivery you lose money.
Keep increasing the PoW cost and think about where that line of argument leads you. "One message delivered to the inbox is worth far more than a billion messages delivered to the spam folder." One single delivered message is going to be profitable for the spammer? Clearly not. This proves the existence of some break-even point at a lower cost. Mail providers just need to set the cost above this point.
Given that spammers mostly use others' computers to blast their email out, I suspect that the price point that would truly throttle spam would be higher than the price legitimate users of email would be willing to pay. I'm not sufficiently knowledgeable in spam and black market economics to throw any actual numbers around.
A million messages delivered to the right inboxes are valuable.
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.
It's an interesting idea, but wouldn't this be easy to abuse though, like Gmail could force Fastmail to do huge proofs of work before accepting their mail?
In my experience of over 15 years, the "rules" have only changed 3 times since I started. First to require good reverse DNS, then to require SPF, last to require DKIM. The transition on each of those was generally several years with plenty of publicity.
That hardly covers it. The problem is that who "you" are, your identity as a sender, is not entirely within your control. The big mail operators figure in a ton of stuff, like the reputation of your subnet - /24 maybe, or /96, it's an approximation - or the reputation of your AS, your domain registrar, all kinds of stuff. If the guy on the next IP over is sending spam that's going to pollute your reputation.
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.
> Which is a fancy way of saying “it requires a bunch of work, continuously as the rules change over time”.
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.
>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.
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.
This would allow spammers to evade the rules all the same. For anything that is standardized or agreed upon, we can of course have packages like this. Time zone data (tzdata), IP Geolocation databases, etc.
I would also recommend setting up a dmarc record so you can monitor your deliverability.
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.
In essence this is one of the principles, the thing is the emails don't need to be perfectly identical, just identical-ish with the identicalish matching implementation being not public (as this would immediately lead to spammers adding just enough randomness to whatever they are sending)
You can't actually measure deliverability with dmarc reports. They will only tell you the portion of emails that are bounced, but they don't differentiate between email in inbox and email in spam folder.
SPF and DKIM are best practices to get delivered to the inbox and DMARC reports are the richest source of aggregate email authentication performance results.
However, you are correct, DMARC reports will not provide the disposition of an email getting delivered to the inbox or spam folder. The report is generated based upon the transaction at the MTA level before the message is handed off for delivery.
> I think the biggest pain in hosting your own mail server is getting your outbound mail delivered into the mailboxes of the large providers without being marked as spam
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.
I think that because I tried it and my outgoing emails weren't being delivered.
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.
Not GP, but it matches my experience: with reverse DNS, DKIM, SPF, being in DNSWL (and not in DNSBLs) some of my messages end up in Gmail spam folders (very recently received a reply to a message I sent 3 years ago because of that, for instance). A while ago there were strange issues with Google-hosted mailing lists as well, with some messages not being visible even to an ML administrator, while Gmail servers accepted mail just fine (maybe it still happens, I'm just not writing to those). I hear similar stories from other mail server administrators too.
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.
Indeed, a quick search suggests that spam is automatically removed every 30 days there. The wording was "Google hid it from me", so either I have wrongly assumed that it's about the spam folder, or it is possible to disable autoremoval.
Edit: or, as the sibling comment suggests, it behaves strangely with respect to removal as well.
Or user accidentally archived it. “X did Y” is often a user’s way of saying “I accidentally made X do Y” without having to accept blame. It’s the “dog ate my homework” of excuses.
I recently checked my Trash folder in Gmail. I had emails in there that were several years old, right below the text that says Gmail deletes emails in the Trash folder older than 30 days.
> 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.
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.
UCEPROTECT was the pits and its operators were unprincipled lowlifes. Luckily they (like all the pay-to-delist BLs) never got more than minimal traction, so ignoring them and their BS mostly worked ('course you needed a /19 to be effective at doing that)
You use past tense... why? They still exist and seem to be continuing their blacklist/blackmail BS. The ISP in question was AT&T and their subsidiaries (I mostly got hit sending to bellsouth.net), which I wouldn't consider to be that small of an ISP and was enough that I eventually gave up.
Past (more than 5 years ago as I reckon) is when I locked horns with them. They may have switched policies, I may have gotten smarter than them, who knows.
I was the ISP, & they had BL'd one of my servers for delivering NDRs. They used to blacklist /16 netblocks wholesale for this kind of, "sins", and demand ransom for getting out.
I work in the industry and it's no myth. Even using expensive relay servers doesn't guarantee the big email providers will deliver your or mail or care much to explain why it isn't being delivered. Big email won't even respond to their own customer complaints that they aren't receiving email.
> None of my emails are considered as spam, and I haven't touched the mail configuration since.
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.
New domains and new IPs are penalized heavily by most services' spam filters.
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.
No - the article contradicts itself. The author says it's "a myth" and "just set up spf/dkim", and then later says "This is already happening with one specifically requiring mails to be sent from another Big Mailer Corp to hit the inbox, or requiring that senders be added to the contacts for others. Any other sender will hit spambox unconditionnally for a while before being eventually upgraded to inbox."
Which is it? Those of us who have run mail servers know that you get unconditionally spammed all the time.
As a person who does run a number of (smallish) mail servers, some outgoing mail does get classified as SPAM and I have to fix it. It's very rare - every 3 months or so maybe, but it does happen. (Possibly the most irritating thing about this is they won't tell you what emails made them think you are sending spam, lets alone why they thing it's spam which makes root cause analysis damned near impossible.) The reverse happens too - we occasionally block non-spam emails.
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.
I tried it a couple years ago. Delivering to large providers wasn't the problem. The problem was smaller ISP, one of them flat-out banned all IPs from my host provider (Digital Ocean), others for no reason I could find banned my specific IP. (I was not on any public block list BTW)
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.
This is true, I run a small mailserver for myself, friends and family. I eventually gave up trying to get mail delivered to the major mail services and now just send postfix mail through Amazon Simple Email Service.
People do not run their own mail server for the same reason people ( including the author of that guide ) do not host jquery and bootstrap on their own servers -- it is not that it is hard, it is that not running their own mail server or not hosting their own jquery and bootstrap code is easier.
The thing I've always worried about is that to my knowledge there's no ACK for outbound mail.
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.
The "host-your-own-email-server" being "hard" vs "not hard" is an unresolvable discussion because everybody has a different mental threshold of "hard".
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.
>There are also different sets of features people want, some are actually pretty difficult to set up.
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.
Fun thought experiment. Let's rephrase hard. If you have to hire a team to manage your email for you, how much would it cost you?
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.
"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.
To all the folks answering basically "yes it's hard" I think the headline is a bit clickbaity but there are some interesting takeaways... To summarize, (a) yes it's harder than setting up Big Corp Mail, but (b) a lot of the horror stories are either old or secondhand, and (c) it's a lot less hard to set up than it used to be.
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?
Exactly. I'm curious too. It seems like the author has something up their sleeves -- OpenSMTPD, apparently. But when I look at the homepage[0], I see a very typical linux-y man-page-style homepage... A far cry from what I would consider simple.
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.
On redhat derived systems, setting up a basic mailserver was never harder (post 2010) than service "sendmail start & & service dovecot start" + adding a couple of DNS records. Not knowing this means not having done one's homework. Which is also a good indication that one should not be messing with email.
And knowing it is still being long way from running an effective mail server.
Everything is easy to folks that have the time to grok the tech.
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.
To add to your point, I like writing software, I know how to set up networks, load balancers, VMs, databases, messaging servers, etc. I have no interest in doing it or being on call. I mercilessly recommend managed alternatives anytime I can. I have a manager who was glad to kill our SFTP server and pay more money for AWS’s managed solution.
He would much rather hand his boss - the founder - a bill than have to explain why our server went down.
That's all great until interruptions in the service you are depending on interferes with your business getting done (and you can't fix or mitigate the problem yourself).
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.
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.
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.
Wow. I'm surprised that this upset anyone. I apologize for that. There was no disrespect or sarcasm meant.
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.
Work at a email provider. Mail is not "hard", definitely tricky. Deliverability is a problem, spam is a problem. How do I know? We spend a lot of time working to improve on our services because of these issues.
In general : computers don't solve the issue of trust. End of story.
Which user demographic is running one's own email server ideal for?
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.
Lots of businesses run their own email server. It's not that complicated.
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 these things up is not the hard thing. Building reputation, not getting refused because your subnet neighbour decided to start spamming, having to deal with BIG_EMAIL_HOST not accepting your emails, bla bla bla.
I have run my own mail server for years. It absolutely was complicated for me to set up but I loved the process of learning and got it going without too much trouble. Now I can get mail delivered to nearly everyone, except Charter. It's been NBD from a maintenance point of view. Spam is all tuned nicely and I generally don't have to think of it.
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.
Or at least, choose an existing decent one email server software stack, and then focus efforts to make on-boarding/setup of that stack as easy as possible. I think you're onto something because the Thunderbid (and of course the mozilla) brand is respected enough to take seriously. AND, users would flock to it because it is highly respected as an org. Yeah, kudos for this idea!
I disagree. There is next to no code sharing between the server and client side of email--implementing the server side of the protocol is vastly different than the client side, and even the server-server versus server-client sides of SMTP and NNTP are practically different protocols. Furthermore, Thunderbird already struggles to get enough developers to avoid compounding on its technical debt; such a large undertaking is simply not possible with the current manpower.
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.
Is there any reason you can't forward all outgoing mail through AWS SES with a custom MAIL FROM domain so it looks like it's coming from you? That way you would have a high reputation IP pool at nominal cost for a low volume.
I don't understand why it has to be so difficult to run a mail server on Linux, BSD, etc. So many different pieces to set up and configure.
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 an interesting thing that with the emergence of cloud computing, we get so many open source library and tooling almost for free but all of this came at the cost of killing the market for professional desktop software.
The installers from 90s and 2000s in windows that people used, were really good at extracting config questions from the users in a very user friendly way. The cloud services today are basically hiding the installation wizard but at the cost of rent seeking as opposed to running unfettered software on your own hardware.
Heres the point though: I want to be writing email, not configuring email servers.
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.
310 comments
[ 3.0 ms ] story [ 92.8 ms ] threadLoad time is under one second, not sure where the salt is coming from.
https://tools.pingdom.com/#5b3b39a913800000
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.
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
[2] - https://github.com/toptal/gitignore.io/issues/2
[3] - https://youtu.be/DngAZyWMGR0?t=460
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
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.
“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.
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.
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.
http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf
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.
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.
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.
[1] https://news.ycombinator.com/item?id=15525505
[2] https://news.ycombinator.com/item?id=19757607
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.
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.
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.
[0] https://www.opensmtpd.org/
And knowing it is still being long way from running an effective mail server.
TFA is on par with this.
That tweet is way too hard for me.
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.
In general : computers don't solve the issue of trust. End of story.
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.
For example, adding 2FA to your users, monitoring access, spam detection, etc...?
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.
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.
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?
The installers from 90s and 2000s in windows that people used, were really good at extracting config questions from the users in a very user friendly way. The cloud services today are basically hiding the installation wizard but at the cost of rent seeking as opposed to running unfettered software on your own hardware.
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.