There is also no need to perpetuate the fear of running your own email. Decentralization of core internet services helps us all, not just the person doing it. So to anyone seriously interested and willing to learn, I highly recommend running your own email servers.
If you expect 100% delivery rate, you won't necessarily get that, no matter who is running your email infrastructure. At multiple companies, I've seen email end up in spam even though it is sent from gmail-hosted company account to gmail-hosted company account. So that's the bar you want to meet or beat and beating it is not hard.
From ~7 years experience now, I don't observe any problems with email delivery. I don't do anything special. I use postfix, it is well configured and everything works fine. I host several personal domains and a couple small business domains.
And by doing so I avoid giving google the power to cut me off from email because some arbitrary ML gone bad.
Technically maybe. But if most of the people you want to mail are on Gmail, as is the case for many, a cut off from Google is almost as bad.
I would long ago have switched over to a vendor, but I use qmail-style tagging for sub-addresses (that is, instead of user+sub@domain, I use user-sub@domain). Almost nobody supports that. Especially not GMail (where my friends could tell me that was tagged as WONTFIX).
If anybody has solved this, please do let me know (on here, via Twitter, or the email address in my bio). It's maddening.
Running the server is generally "set and forget". Every few years an issue might pop up that requires attention. These issues are generally due to a tightening of other servers' requirements rather than an actual technical issue. When such things do occur, symptoms are an occasional email rejection, and a bit of digging reveals the cause and fixing the cause returns things to normal. I've never had a wholesale rejection of mail from my server
For example, when SPF and DKIM came in, I had to add those records to my DNS. When Let's Encrypt came on-line I proactively added TLS to the server. A number of years ago lack of a Reverse DNS record got me on a blacklist for a short time. That was fixed by contacting the IP address issuer (my ISP) and getting them to add a reverse DNS record. Just make sure the reverse DNS hostname matches the hostname that your email server uses in its HELO messages. A week or so later I was automatically off the blacklist and the few rejections went away. I've never bothered with DMARC. This is the sum total of my experience with running the server.
At times there have been physical problems with the server or network outages with my ISP, but I discount these on the basis that it is my decision to run a server on a desktop PC in my house rather than in a data centre. Easily fixed if I wanted to throw money at it.
Setting everything up in the first place was a massive pain in the arse, definitely not for the feint hearted (I imagine there are tools/scripts to make it much easier nowadays), but it's been almost plain sailing since.
It's very rare that I have delivery problems, maybe once every year or two, which is roughly the same as through my O365 mailboxes!
Only issue is when there is a delivery problem, there is usually nothing you can do. Some of the block lists have a procedure for removal, many don't.
But after running my own mail server for something like 15 years, I've decided I just don't want the hassle any more (even if it isn't much work), and plan to move everything to O365.
I never get bounces from Google. And after the first day or two of removing yourself from 2 or 3 blacklists, its great.
I use mailcow FWIW
I'd encourage everyone to try this on a tiny droplet or linode with an unimportant domain (don't just migrate your entire companies' exchange into it on a Friday afternoon). It takes you an hour tops, after which you can poke around and see all the moving parts that make a good mailserver tick.
You'll also be contributing to a stronger, more resilient internet, by making it a tiny bit more decentralized.
I don't have a problem setting up a full email server, but I don't want to babysit it for just one person using it. I have too many real life obligations these days to try and fix the mess if a problem would arise.
Now try using an email from a domain name with more that 3 letters in the TLD.
Almost no one considers that a valid address.
And you'll be flagged for fraud as well.
It's very frustrating.
As far as I know the most important factor for deliverability is your IP address: my /24 have been clean for many years because the network operator actually respond to abuse@ reports.
If you have problems my first advice (aside from checking that SPF+DKIM+DMARC+PTR+banner+etc... are OK) would be to find a better ISP.
 in this block if it matters: https://rdap.arin.net/registry/ip/188.8.131.52
More, google knew this was a thing because they warned me.
(The base name also has to be different from your real email address, but that's a fairly desirable feature for disposable addresses since it doesn't reveal the real address like the '+' suffix on Gmail does.)
1. Send mail via a static IP (that I pay extra for)
2. Send all mail through a reputable 'smarthost' (mine is provided by my ISP as part of the 'business' package).
This fixes all sending mail problems. For extra fairy-dust, I added SPF records to my mail server IP.
The BIG problem is Spam. Unless you pay for an intermediary spam filtering service, you will NEVER be on top of it. After self-hosting my own mail system for decades, I am now seriously planning a migration to Office 365.
YMMV, but a combination of graylisting, RBL and "sender address valiation" tends to drop inbound spam rate to nearly zero.
My theory here is that statistically, by the time a spammer tries to send one to an active address, they're likely to have already fed things into the trainer, often multiple times.
(Disclosure: xoogler, but still happy with Gsuite...)
Out of curiosity, where does your MTA live? Do you have a VPS? VM/instance at a cloud provider? ISP with static IP? Other?
1. share everyone's mailboxes to an admin user who does the backup via IMAP.
2. create an app-password for each user which can be used to backup that user. This can be done as an admin user on your account.
Neither of them require knowing the user's password - an admin can override into each account unless it's specifically locked down to deny that. It does require a separate app password per account, we don't have a way to create a single password which can view each user's account without them explicitly sharing the folders, but I'm not sure how you reasonably do anything else without it being a backdoor behind all the privacy settings on each account.
Thanks for the tip. Maybe my Christmas present to myself will be to murder my mailserver!
Is there anything you need to enable to allow this? I just tried, and the email got bounced back.
Or are you talking about email aliases? As in, you register <user>-<tag>@<domain> first before sending emails to that address?
I chose it 20+ years ago because that's what qmail supported, back when subaddresing was a new idea. Over the ensuing years, most people ended up converging on + as the more common option, but that's only convention, not a standard. And what standard exists wasn't written until 2008: https://tools.https://tools.ietf.org/html/rfc5233ietf.org/ht...
I have never had this issue. Generally the issue is either IP reputation of your server (common with VPS providers if you get a recycled IP of a previous spammer) or your domain name.
Otherwise you are probably just unlucky enough to tickle the spam-prevention mechanisms in the almighty "algorithm" run by $BIGMAILER.
I keep one "normie" email address at a $BIGMAILER for situations like this, but at this point in my life I mostly just shrug if some big advertising/surveillance company's email system won't deliver my mail, I just won't email that person.
Be the change you want to see and all that.
> I mostly just shrug if some big advertising/surveillance company's email system won't deliver my mail, I just won't email that person.
Because that changes the tone of the opening paragraphs significantly:
> Luckily, running your own mail server is not as daunting as many would have you believe.
Sure, if you can afford to shrug off deliverability issues to major e-mail providers. Then it is, I daresay, a walk in the park!
Still, usually when sending emails to Gmail & Hotmail my emails are "lost" (they don't even appear in the spam-inbox of the receivers).
My usual workaround used to be to 1) login into my throwaway-account on their Gmail/Hotmail systems 2) send an email to my domain 3) reply to that email. After that usually my emails got accepted by those service providers, at least for a while.
I admit that nowadays I don't even do that anymore - when I see a Gmail/Hotmail recipient I just ask for another email address at a different provider or I send the email using my provider's system.
No idea if that's still the case, though.
Every time these posts about setting up a mail server reach the HN front page, there are usually complaints and they always center around third party email services. Perhaps it is the use of those services that is the problem, not the process of setting up a mail server.
Spam is probably made easier by the fact that so many people use the same third party email providers. Spammers have less servers to target. (Not the same situation if every user had their own server.) As HN commenters oft point out, email, the protocol and software, is "decentralised". But the widespread "centralised" use of the same third parties to send and deliver mail has negated the benefits of being (theoretically) decentralised.
If the FROMs top level domain is in the top 500 websites OR is a .edu NOT SPAM, ELSE, send to "proprietary spam filter". The "proprietary spam filter" is some random crap code that is unique to each email server company. You could spend years trying to figure out how to game "proprietary spam filter" - but it is a fools errand.
spam filters really are this dumb at big companies. usually the way we'd get around it is we'd call up $big_company and say, "hey, could you please remove our e-mails from your spam list? we would like to send your users a lot of mail right now." a few hours later, we'd be good to go.
this was ~2007. it may be harder to get them on the phone now, and the value of your company may need to be higher (we only had a few hundred million, which seems like chump change these days).
It's not as bad now, so I suspect someone at Google is finally listening, but I still don't trust the reliability of e-mail. If I sent someone an e-mail I haven't e-mailed before, I'll let them know on Hangouts/SMS/Facebook that I sent them an e-mail and to check their spam folder.
And if there was a secret to building a reputation you could make a lot more money as a brand consultant with it than running an email server.
I have DKIM, SPF and no relaying and the only issue in recent memory was when AT&T started bouncing me for some reason. I emailed postmaster@ saying "hey wats up," and the block was removed a day or so later.
I help with IT for a small non-profit membership org, and the problem isn't the places that throw errors when you send, but the ones that silently accept the message without complaint and route it to /dev/null. We get through fine to Google, but the other big providers are random at best about it.
"I have no trouble sending to anybody (that I've heard of from recipients" might not be as artfully written as I would like, but that's what that refers to.
Furthermore, blackholing emails like you suggest is generally rare. RFC 5321 (SMTP) states:
"[D]ropping mail without notification of the sender is permitted in practice. However, it is extremely dangerous and violates a long tradition and community expectations that mail is either delivered or returned. If silent message-dropping is misused, it could easily undermine confidence in the reliability of the Internet's mail systems. So silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate."
The downstream MX could be configured to then send an NDR email itself but this lands you on spam lists as "backscattering" will then send spam back to whoever owns the email address the spammer is spoofing so it's generally not done.
Yes, maybe rhizome is successfully running his own personal mail server but your anecdote isn't really relevant. We can't learn from your example because the hidden rules of reputation & spam may not affect you but will affect others.
For example, a commenter (lucb1e) argued that I was exaggerating the difficulties of reliably sending email but a year later in 2019, he confirmed the same difficulties! 
Do you see why we can't reliably extrapolate from personal experience?
DKIM and SPF are really good signals to have. I have DKIM, SPF, DANE(nobody cares), DMARC, MTA-STS, TLS (lets encrypt) which are all potentially useful in preserving reputation and repudiating emails spoofing my domain sent from other sources.
I have never had issues getting throough to gmail. But for some mail systems, Microsoft in particular I think, they seem to penalise low volume mailers very heavily. You seem to need a certain volume for their systems to cache a reputation score and if you have a small vanity domain/mail server with very low mail volumes you may go straight to the spam folder.
I just gave Yahoo a try, and that did go to spam, even though it was happy with both SPF and DKIM. I marked it as not spam, and then went and sent another. That went through fine.
I also tried Live. It says my SPF and DKIM are fine, but sends it to the spam box. I marked it as not spam. Nope. Next one still went to spam. Marked that as not spam and tried again. Still spam. Marked that as not spam, but didn't try sending another one yet. I'm going to wait a while, to allow for the possibility that it takes them a while to apply feedback.
I also tried comcast.net. Went through fine.
mailinabox.email is probably close to what you want, though. It's opnionated and my tip is to follow those opinions to the letter (or use another such project).
Hetzner VPS, proper reverse DNS, SPF, that's all, not even DKIM. The only big ISP that doesn't like my mails is AT&T and I couldn't care less (in Europe, rarely have to deal with people @att.net).
I was running my own mail server for nearly 10 years on Hetzner. Prior to that on other hosts and in the distant past at home. Running mail servers is something I have done professionally and successfully.
The last time I moved boxes as I had many times before. I was on clean IP range but I had no IP reputation at all. In the past this wasn’t such a problem, especially with SPF, DKIM, rDNS, DMARC, server-to-server SSL etc. Around the same time I started having to deal with organisations (legal, etc for a death in the family and later rent) rather my my own circle of friends. It became extremely apparent that my mails weren’t hitting the inbox. But they were being accepted. This was extremely problematic.
I was in the group stating that running your own mail server isn’t hard. I still say that. The hard problem is convincing the big players to let your low volume domains and IPs hit the inbox. I begrudgingly gave up my MX servers last year.
Of course, there are some mails where I don't know if they landed in spam or I just didn't get a reply.
Google shows that my domain has a bad reputation, but I can't fix it because it doesn't have enough traffic. https://www.mail-tester.com gives me a 10/10 (I have DKIM, DMARC, SPF, everything), but my email still gets flagged as spam by Google.
Setting up was a bit of hassle, but since it was up, I don't do anything with it.
Occasionally I will get the odd notification that a (usually German for some reason) email address doesn't like our domain. But the major providers, never had a problem.
No idea why we haven't had a problem, I didn't know what I was doing at the time (still don't) just followed an online guide. From memory, spf, dkim which I think is all pretty basic things to setup when setting up a mail server and all guides cover it.
The only issue I have found seriously limiting my ability to use my own self hosted email server is the deliberate decision of Google, Yahoo and Microsoft to make it hard for me to do so.
Their decision is essentially un-appealable. I still get hotmail complaints about spam being sent from an IP I do not own anymore. For the life of me I could not find a way to solve this. Yes I did remove that address from their “responsible domain owner nonsense thingy” to no avail.
Often times I would send an email to a domain owned by one of the big three and that email would just disappear. No bounce back at all. The recipient would not even see it in their spam folder.
They tell you to implement various technical solution line DMARC and DKIM but in the end what really matters is the arbitrary and capricious decision of these three companies against which there is no recourse.
I agree that hosting your own email server is important but this is a battle that I gave up fighting.
I've been running my own mail server without sending problems for almost a decade. Right from the beginning, I had a clue and knew that sending SMTP directly from a subscriber IP address was going to be a nonstarter. Such IP's have a negative reputation due to abuse. Instead, from the beginning, I used my ISP's (big ISP in Canada) SMTP forwarding host, configuring my SMTP server to log into that server with my credentials.
(I had a couple of hiccups along the way with the ISP's SMTP service, and they wouldn't help me unless I reproduced the issue with a supported e-mail client. Naturally, an Exim server running on Debian isn't a supported e-mail client, because it's name doesn't sound like "Microsoft Outlook" or "Mozilla Thunderbird").
Anyway, the main advantage of running your own mail server is not the ability to send SMTP directly to someone's MX server, but rather that you have your own MX domain for receiving mail, via a machine you control. Your setup isn't "lesser" in any way just because you're sending through a more reputable SMTP forwarding host.
I run a mail server for a few thousand users that has been going for ~20 years, and have regularly had to spend significant time figuring out adjustments the big mail providers make along the way. Spending a day roughly every year figuring out and implementing countermeasures isn't that bad, when you get paid for it. But I really don't have the time to do it for my personal e-mail.
Your answer reminds me of something I heard a greenskeeper say about the big garden he maintains, I think in the UK: Tourists come to me all the time and ask "How can I get my lawn to look like this?" I reply: "The secret is to roll the dew off the lawn every morning." "That's it?" "Just do that for 300 years and your lawn will look like this."
> "Just do that for 300 years and your lawn will look like this."
My point is that I've never had problems in that decade, not that it took a decade to fix. I think on two or three occasions, mail to a gmail user mysteriously bounced, but it went away on re-try.
I understood the reputation problem from the beginning instead of banging my head against it. Why I understood that is because I did some research into running mail servers before diving into it.
More to the point, I discovered this by reading Google's postmaster/bulk mail guidelines. All the other major email providers have similar guidelines, so definitely consult those as a first reference if you are having problems.
There is no mail conspiracy. As always, the problem is DNS.
What I have had an issue with is the network (the whole ####ing network, those guys are less than helpful) I’m on getting added to spamhause(I think?) and people setting up their (smaller) mail severs to blindly reject mails from networks like that. That’s really dumb and I’m glad for things like dkim because of it.
I used to run a mail server in the past, and initially had problems with reverse DNS resolution not setup correctly, it's an easy oversight depending on where you host.
Stack: OpenBSD VM (on 1984.is) running OpenSMTPd + Dovecot + a DKIM proxy + ClamAV + spamd.
The more relevant pain point is that the VM hangs every couple months and I have to hard-reboot it from the VPS web console. Also, I've been pretty lazy about staying on top of new OpenBSD releases. One of these days I'd like to go redundant (whether with both mailhosts on 1984 or putting one on a different provider), which would make it less stressful to do OS upgrades (I could keep one host running while doing an offline upgrade of the other, as opposed to hoping the online upgrade process doesn't break anything).
Google is a different beast. Last time I remember I had to do strange things like disabling IPv6 support in my MTA (which is a good idea anyway as I'm not an expert in IPv6) in addition to the usual SPF setup etc. E-mail is delivered in general, but once in a while some letters go into spam for unknown reason. But this happens rarely, maybe a couple a times a year.
Whenever I set up a new server, I have to start from scratch though.
Right when I started with the VPS, rejections from Comcast started showing up in my logs, and I traced it back to the IP I got being in some blacklist. Requested a new IP and it has been smooth sailing ever since.
As it wasn't possible to pre-check IP addresses (it wasn't blacklisted, and in any case the email was being served from a different IP to the one that was apparently previously an issue) for any particular hosting company - and I could only afford cheap hosting - then I decided to relent and made an Outlook online account and sent the mail from that.
It seemed totally crazy to me to reject mail from a 15 year old domain that sent at most 30 emails to Outlook per month, _always_ in replay to an email; SPF/DMARC were set AFAIR and whitelisting the email address from within my own 20+yo hotmail account didn't make any difference, MS still wouldn't let _me_ receive the emails. Like if your user says the email address is fine, and sends an email to that address, .. then perhaps you should allow the user to receive that one email??
Mine goes through a DigitalOcean droplet and my mail usually gets through (based on the assumption that if I received a reply, the other person must have received it!)
By contrast a volunteer group I'm involved with was using OVH "because it's the cheapest". Suppliers and customers were routinely telling us the emails were going to spam. Moved to another provider (no idea who, the infrastructure team does that) and the complaints fell to a trickle.
Good IP block reputation (check RBLs) + valid SPF + valid DKIM is usually enough to get mail through. Except occasionally to Hotmail... but that's Hotmail...
I added my domain and have never had it marked as spam at any major email provider, only a few small, self-hosted servers and that was probably due to misconfiguration or high spam sensitivity. See if this might help you out.
Since mailinabox configures everything for you maybe the issue is that when you set it up yourself you don't quite get it exactly right to what gmail and microsoft demand.
I redirected my gmail account to forward all emails to this new domain, and changed all my account emails to firstname.lastname@example.org e.g. for github it’s email@example.com. Once I’m done, Gmail won’t be receiving any new mail.
It has SPF which has captured most spam. I haven’t implemented sending yet. I thought this would be a problem initially, but after a year I’ve realized I rarely send personal email out. But I’ll do it one day just for completeness.
I’ve found two bugs of my server, which were easy to debug because mail sending is very robust. I fixed the bug, and the sender server tried again the next day automatically.
I did it for exactly the same reasons as the author, to control my own data. I wrote my own because existing open source offferings are silly complicated, but receiving mail is not.
Duta is easy to deploy with docker machine and DigitalOcean. My current setup has been deployed like this. It connects to a managed DO Postgres database, which runs separately, has monitoring and backups, so it’s easy to redeploy the mail server without worrying about losing my data.
Hosting email is a pain! This is why everyone seems to outsource their email hosting.
Read the comments in the 2017 discussion. Favorite quote: "I run my own mail infrastructure. To say the least I wouldn't recommend it even to my worst enemies. It's horrible."
So far in the past year the only manual intervention after setting it up was updating it from ubuntu 14 to 18
It's sort of a managed server that lives in your home. I'm not sure whether that's actually better than having your data out in the cloud or whether it's more on the security theater end of the spectrum, but it is interesting.
I think Debian also has a GUI for setting one up.
Then EVERYONE stopped because it's awful. Modern ISPs don't like SMTP floating around, (DKIM, DMARC, SPF) are a pain to maintain over time, exploits will happen, and your free off-the-shelf virus and spam filters suck compared to the big companies seeing billions of messages per day.
FWIW, i used mail cow , which was a delight to setup and use. And it comes bundled with a decent-ish material design webclient.
I would love to go back to hosting my own mail server though. As of now, i shut it down, and use gsuite.
This is the type of nonsense I expect from HN. Well done.
It is entirely reasonable to show how you've handed your mail to gmail and they refused it without actionable explanation, so it is a problem between the recipient and gmail.
Assigning blame is done after the fact to make up for a mistake.
Just avoid the mistake.
If I get an explanation from the server I will fix it.
I get dmarc reports and I make sure all pass. That's all I can do.
gmail spam filtering is quite bad, in both directions. Legit email goes to spam (even when sent from gmail itself) and spam does get through.
The basic open source tools are actually very, very good at it. I get about 0-2 spams a month, everything else is caught by either my postfix configuration or by spamprobe. And I never get legit email in my spam spool.
This is a much better success rate than what I observe at my gmail account.
The latter will catch new spam tricks easier. But the former will be trained by you. For you. For your niche, using your lingo and so on.
To take an extreme example: let's imagine you are the ITperson for a doctors' practice aimed at people with sexual disfunctionality. One thing is for certain: using Google or Outlook for your mail is a disaster waiting to happen.
Those "specialized tools" make email viable. Without it, everyone would be spoofing everything and you wouldn't use email anymore.
from what i understand, the gmails, yahoos, outlooks, whatevers of the world basically make it hard on purpose to make their own jobs easier.
Hosting your own mail server is not rocket science, but you need to have solid sysadmin skills and a good understanding of email as a whole.
If anyone is interested in doing this: Start simple with only Postfix and Dovecot, don't use a database for username/mailbox configuration as most tutorials suggest (start with text files instead). You can also start with OpenSMTPD and Dovecot if you think that Postfix is too complicated.
And if your setup is finally running, make sure to setup proper monitoring (e.g. make sure your mail server is running and answering SMTP connections). You can use free tools like uptimerobot.com for that and get notified before you loose mail.
Not really. I had neither and got it up and running. Sure I had some issues, but as long as you have some competence, most things can be sorted out / figured out.
This is exactly the problem people are talking about!
I'm running a personal mailserver (opensmptd, dovecot, dkim, spf, dmarc, spamassassin) for some years now and although I initially had problems with deliverability to google there aren't any (apparent) issues so far.
Also I don't understand why people keep emphasizing google's spam filter being so much better than anything else. For my personal server SpamAssassin has proved itself to be more than sufficient, its spam filtering performance is on par with Gmail's (I have a Gmail account aswell), at least for me.
Of course, Gmails spam filter works better for the billions of accounts they manage, but in order to handle the spam of a tiny mail server I'm probably not the only person who is satisfied with SpamAssassin.
Details of my current setup are here:
Though this will be out of date soon since I'm moving everything over to Illumos...I have a fondness for dying operating systems I guess!
For example, gandi.net provides web mail on your own domain. Even, better, it has support for wildcard email just like google does.
Earlier this year, I had to move a number of email accounts (my own, family, friends, clients).
Based on a fairly extensive comparison of email hosts - with brief stints trying self-hosting as well as Zoho - I migrated to Migadu and have been very happy with their service.
Their pricing is clear, structured well to suit my needs, and the service has been reliable.
I have run my own company email for around 20 years and other people's for over 30. I'm in the UK.
No matter how technically competent your setup, if your IP is blacklisted by one of the big lists eg Spamhaus then you are screwed. So you need to avoid that. Avoidance tactics involve properly configured MX, A and PTR DNS records. Then you'll need a proper SPF TXT record. Can you do DKIM? DMARC?
Oh and please avoid sending spam to people - it ticks them off and get's you blacklisted.
The only thing I've ever failed to setup was a functioning mail server using Postfix and Dovecot (it was like ~2007/8). It was a circle of configuration hell I would wish on no one and since then I've never understood why anyone would want to run their own mail server. Pure, unadulterated, hell... I honestly don't even know why we have email at all it's so shit (obviously I do, but hopefully the sentiment I'm expressing is clear).
Granted, if you know how to do it, once it's "running" things mostly work (I've known plenty of people who didn't fail as miserably as I did)... but as others have mentioned actually sending emails and not being labeled as SPAM is almost impossible. Plus, making sure your service is literally ALWAYS available, is really quite tricky. It's pretty damn easy to miss some emails.
I keep hoping some other protocol will take off so we can free ourselves from email, but it looks like the chance of that ever happening is probably zero.
>actually sending emails and not being labeled as SPAM is almost impossible
Anecdotal, but I really didn't have any issues with either of the above. Just don't use a tainted IP (protip: basically every cheap VPS provider's IP space is tainted) and set up SPF/DKIM properly. Following a tutorial is probably the way to go if you're not familiar with Postfix/Dovecot. And as you mentioned, once you have it up and running it's basically zero maintenance.
>making sure your service is literally ALWAYS available, is really quite tricky. It's pretty damn easy to miss some emails.
Mail standards actually make it really hard to miss emails. Every mail service will, by default, retry delivering mail for 4 days (!). This is the default in MTAs and the big boys (Gmail, etc) do the same. If you want to be more HA you can set up backup MXes but that's overkill for a personal server.
I don't know that I like some of the deskilling I see. It seems like many people would rather learn a proprietary cloud api or use a prebuilt container than learn the fundamentals of setting up their own services.
A personal mail server, tested and refined over decades serves as a template that can be applied to other projects. If I have a web server backend that needs to send emails I have a pre-built and tested low maintenance solution I can deploy very quickly.
The main issue people will encounter is that you are at the mercy of a much bigger ecosystem where high volume senders have all the power and your good work implementing best practices is rarely rewarded. In the end your mail delivery is at the mercy of some shody unmaintained commercial abandonware spam solution maintained by someone who failed up and doesn't give a shit and has never read an RFC.
Making sure your service is always available isn't even necessary. Queuing and retries are built into the SMTP protocol. I run my servers off a cable modem and I easily have 99.9% availability.
Does anyone know if there are MTAs that can pickup mail from a local directory to send out and MUAs that don't need to use SMTP to send out mail, but have the support to rather just write it to a directory?
I was wondering if the sending of email could also be handled by a standalone program separate from the MUA like it can be done with the receiving of mail.
Your mail server must not use the original from address in the envelope from, as that would very likely trigger SPF record checks at the receiving end. When forwarding mails, it is therefore strictly necessary to rewrite the envelope from address with SRS.
For this postfix setup, postsrsd  can be used to implement SRS with only a few more configuration options.
I would like this to be true (really) and it can be true only if only you are the only mail system user.
As soon as you give an email account to a non techie and non email politeness aware user you are doomed. Like your windowsxp user mum with a compromised outlook express sending crap to full addressbook. Your friend is sending last penis graphic joke to their (gmail/msn) friends. Dad has used email to register to many dark sites and now all *@yourdomain.com receive viagra offers and they ask you to stop receiving that. Girlfriend is trying to send a 1GB video to her workmates.
But then, one user mail system does worth the effort?
Alot and xapian are awesome.
Anyone from github: please check #439658 and let me gen the cookie via ssh. I didnt enable 2FA.
It depends on why you want to run an email server, I suppose. I just didn't want google collecting, analyzing, and indefinitely storing my incoming mail (left gmail).
I have been thinking about this for a while , there should be a way to decouple email server and storage into 2 different services, where I could authorize email server to grab the data from storage. The storage service itself should have zero knowledge encryption. This way, I could just switch between email services.
Main developer from the OpenSMTPD project here.
I also wrote an article a few weeks ago about running your own mail server which is located here:
I've often thought of running my own IMAP server (I like syncing, but I want to retain all my e-mails and not worry about quotas).
As for SMTP - I'm happy for my ISP to handle that.
My 2 cents.
From then on, MX'd my shit to aspmx.l.google.com. and called it a day.
Any hosted solution is probably better than this.
Is running your own mail server one of the best ways to get off GMail?
Would Google still suspect my mail of being spam If I bring my own domain to Gsuite or rackspace (for instance) ?
If you send too few messages, you're untrusted.
I'll let Ricardo Signes do the talking: https://www.youtube.com/watch?v=JENdgiAPD6c
Mind you, I think PINE may have been the greatest email program ever written, but Crispin was not the easiest person to get along with.
That leaves you with either using some protocol that already exists (IMAP or now JMAP as another persion mentioned in the thread) or coming up with my own.
- Use server-local users, and have the webmail prompt for those credentials and use them to browse that user's Maildir via SFTP. "Good enough" for small-scale operations. Probably not the best choice for large-scale operations, but likely "good enough" for small-scale.
- Store the emails in a SQL database (e.g. Postgres), with row-level permissions to SQL users for each address, and have the webmail prompt for credentials for those SQL users and use those to connect to the DB and query messages. Probably the ideal choice for large-scale operations.
Both of these options seem more reasonable to me than trying to do anything with IMAP.
The second is likely the better thing to do (But likely not in postgres for large-scale, if anything due to the SPOF. Unless someone really enjoys maintaining postgres clusters). However, you still need some IMAP/JMAP somewhere for normal mail client access, and in this case you'd likely have to implement your own translation/access layer. I would probably come up with something that wouldn't have users directly access a database, and instead provide some sort of identity-aware access layer. Basically reimplementing IMAP/JMAP, again.
Don't do it.
Step 2) Dude, seriously.
Don't do this. It not only will drive you crazy, it's getting worse.
Minimal mail system involves just postfix with config in a bunch of files, delivering mail to a folder on the server, and pretty much everything on top, like SPF,DKIM,DMARC,... is optional.
You can ssh to your server from anywhere and run mutt there, or install a webmail if you're into web stuff. That's pretty much all that's needed for a basic thing. Security wise, there's not much to do wrong in this setup. Mail server is open for reception by default as it should be and submission is only allowed from localhost.
Webmail can be protected via HTTP auth and ssl. As long as your password is secure, noone will get there that way.
Rolling your own crypto is a much bigger can of worms.
Minimal mail system involves just OpenSMTPD with a few lines of config in a single file.
You'll likely experience security breaches rolling your own crypto unless you are an expert in cryptology.
You'll also experience security breaches running your own email server if you also don't know what you're doing, but it's far easier to learn what it takes to configure an email server correctly from a security perspective than rolling your own crypto.
The bigger problems with running your own email server is NAT/CGNAT, ISP restrictions, and the fact that the big players will still ignore you due to only caring about the other big players.
It's too much effort to run your own email server well.
GMail's de-facto monopoly on email (and especially spam filtering) is a threat to the Internet.
I tried registering this domain through G Suite and Zoho first, but they both said my domain had a TLD that's commonly used by spammers, and refused to bind it. Zoho eventually made an exception but took over a week for them to get back to me.
>> Getting off GMail is one of the best ways to take back your data in the face of dragnet surveillance.
In that case, Fastmail is a good alternative. It’s not quite as good as Gmail on security and anti-spam, but it’s much better on privacy.
Spam filtering - I have both Gmail and Fastmail. I'd score Gmail 10/10 on spam preventing, and Fastmail at 8/10.
Seriously though, we have been making as much effort as possible to push the account recovery away from being an "agent decides" to following an automated process. We famously got this wrong once many years ago, and have learned from that!
So the fact that our lovely support people are very helpful once they have identified a person does not mean they are pushovers for an attacker.
I remember on one occasion needing to extract billing info from a number of different accounts that were under one master account. The support explained there was no native solution, but helped me come up with a workaround. That kind of support is sadly missing from a lot of vendors.
We are expecting people to pay money for a service which others provide "for free", so we need to differentiate ourselves, and having real humans who not only provide great service, but are located close to the technical teams and can feed quickly back to improving our service is a key differentiator for us.
Also I run things over my mail database as I have direct access to it.
I'm sure there are some people for whom google is an acceptable option. But it isn't for everyone.
Search, Mail, Photos, Translate, YouTube, Maps, Drive, Calendar, Docs, News etc. etc.
What do you replace them with? In experience Google is usually the best or not far from the best.
I know people talk about Apple having a “walled garden” but really for me it’s google that has one, now with a shitty web based interface.
Basically at this point my options are so much better that the privacy is a bonus.