So many replies so quickly! 😮
Thank you, it seems pretty clear that this is a bad idea, the replies seem to be unanimous!
I'd heard staying off blocklists, filters etc was difficult, wasn't sure if this was exaggerated, but this totally confirms it.
Okay, guess I won't be recommending people start their own email service then!
Would using your own domain on an existing email provider be the next best thing for non-technical people?
No experience, looks daunting as a relatively technical user.
There seem to be a few projects aimed at lowering the bar, but there just seems to be a higher "background knowledge" bar to maintain it.
If I understand the user needs to set up:
An SMTP server
An IMAP/POP server
Run a webmail or setup a client
Configure additional DNS
Then work on spam filtering / making sure you're not blocked as spam
@gabriel @homegrown I set up my email using a script called emailwiz.sh. It allows you to set up a mail server on Debian and Ubuntu using local Unix accounts. It's pretty easy to set up, just run the script and enter the domain of your server (without the mail subdomain). Then you can put in the details for SPF, DKIM and DMARC.
Only problem is that you have to ask your hosting provider to get Port 25 opened, and that can be a big pain. On Vultr, you have to wait many months to be able to even ask them if you can activate Port 25 on any server, so I don't recommend them.
i would advise against it
running a mail server means it will be attacked, so you'll have to spend time looking at logs, installing updates, reading alerts ...
and your server still may get compromised
did i mention backups?
@homegrown This is a very in-depth guide: https://arstechnica.com/information-technology/2014/02/how-to-run-your-own-e-mail-server-with-your-own-domain-part-1/
I would, however, think twice about setting up your own email server. Mainly because of spam, specifically preventing your email from being marked as spam.
Professional email providers have ‘delivery teams’ that do nothing but work on staying (or getting) off blocklists, pass overzealous filters (Gmail!) etc.
@homegrown You’ll need to understand SPF and DMARC. You’ll need to learn how to “warm up” IP addresses so spam filters expect email to come from that IP. You may want to develop a system that warns if Gmail, Outlook or another big one has silently started dropping your email.
It can all be done but it’s probably a lot more work (and ongoing work) than, let’s say, setting up a small Mastodon instance.
@homegrown I'd recommend against it. Even if you know enough to do the ops and security work you'll end up going straight to spam when DKIM or SPF is slightly wrong, or when your IP gets block listed by gmail after the first time your server gets hijacked for spam, etc. Start a co-op instead so that you've got a few people with expertise to handle the different complex parts.
@homegrown No, non-technical person should not run e-mail service himself/herself since it's a huge challenge: warming up IPs, setting DNS PTR, adding SPF, DKIM, DANE, proper TLS, then constantly adjusting filtering and fighting spam bots, dealing with denylists, etc. I'd say managing mail server is a full-time job 🤔 And double these efforts if you're aiming to send mass mails (newsletters, automatic replies) 🔧
@homegrown Not trying to discourage people from running own mail servers, but it's far more complicayed than 10 years ago - if you don't implement all trending features, there is little chance mails will reach recipients at all or end up in spam folders 🧐 Gmail and Yahoo might not be too aggressive, but Outlook is pretty strict when receiving 😔
@homegrown Then, when you’ve got it working over IPv4, getting it to also work over IPv6 is another challenge.
Because the IPv6 address space is so much bigger, traditional IP based blocklists don’t work the same. Apparently Gmail is even stricter on receiving email over IPv6 than over IPv4. And that is saying something.
I created a business plan for a commercial email provider once. Then decided not to go ahead because of some of these challenges.
@homegrown Imho, I would not say so. Mails are something that most people really rely on. Downtime for a few hours only is already unacceptable for them. And your service will have unexpected downtime. Mail is a complex eco system that is not easy to understand even as a being in the field. From running low on memory to being blocked by major providers up to dns issues there are a lot of things that can go wrong. Finally there are great mail providers out there wich offer good service for a few bucks. mailbox.org is what I use personally for instance.
A simple and scalable solution: Each domain you buy from Gandi.net comes with 2 free private mailboxes hosted in France. You can later buy more or bigger from them or switch your domain to another provider.
@homegrown I don't think that makes very much of a difference. If you use your own domain instead of a provider-provided one, the only change from a non-technical perspective is that you don't advertise the email provider.
From a technical perspective, you should also add an SPF record to improve the chances that Google & Co. don't immediately give your email a positive spam score, —i.e., don't immediately categorize it as spam. However, non-technical users might not know how to do that (or even get their own domain, for that matter).
In general, my personal recommendation is to use a mail service that you pay for (and that has a good track record in terms of privacy, like https://mailbox.org). By paying for the service, your data is less likely to be what you pay with. Naturally, paying for a service does not necessarily mean you don't also pay with your data, but it's less likely than with (especially big) free email providers.
Yes, I strongly encourage people to pay for their services on GYOS articles! Paying for labour is far more sustainable and fair 👍
However, even pay-for services can be bought up, Whatsapp used to be a paid service but then Facebook bought them, removed fee, eroded security etc and people couldn't get out due to network effect.
So, even with paid services it would be nice to have some way out if needed. Custom domain at least avoids others having to update their contacts?
> However, even pay-for services can be bought up.
Correct, but so can the server hoster you put your “self-hosted” services on Or the ISP, in case you host the hardware at home—but, in all seriousness, would a non-technical person really do that?
> Custom domain at least avoids others having to update their contacts?
I suppose, provided that you have the possibility to set up your custom email domain with the new provider as well. And don't forget to update your SPF record, of course.
Sure, I agree there are dangers in all these!
I guess I'm trying to reduce the number of eggs in each basket?
For example, if you buy domain from one company and email account from another, hopefully they wouldn't both go bad at once 🤞
I did actually look into home hosting 😁 and there are promising developments, but (apart from the complexity) the hardware is currently too expensive due to stock shortages. 30 euro Raspberry Pis are currently selling for 100+ euros 😞
> I guess I'm trying to reduce the number of eggs in each basket? For example, if you buy domain from one company and email account from another, hopefully they wouldn't both go bad at once
Hm. I suppose I can see where you're coming from. I'm not sure how much a custom domain would help with that, though Sure, it makes moving easier because you don't have to tell everyone that you're using a different email address now, but as for actual privacy and security benefits…
> [...] the hardware is currently too expensive due to stock shortages.
Short aside: You don't even need something like a Raspberry Pi (or comparable SBC) to host your services at home. While it's probably less energy efficient, you can also make do with old or defective hardware that is (a) reasonably likely to exist in a household and (b) still powerful enough for pretty much all self-hosting services. For example, @vib is running their services on a T520 that's missing its screen.
Also, off-topic note: I find Mastodon's lack of support for markup annoying.
Not having to change your address in a million different places would be a big help, at least for me!
But yeah, not a panacea for privacy or security (and email itself isn't exactly private).
I'm just going for improvements where I can get them, even if they are partial ("move slowly and improve things" rather than "move quickly and break things").
Thanks for suggestions about hosting hardware, will look into it!
> Not having to change your address in a million different places would be a big help, at least for me!
> I'm just going for improvements where I can get them, even if they are partial
Ah, in that case, that makes sense, yes. I was more focused on the privacy and independence part.
> Thanks for suggestions about hosting hardware, will look into it!
Many paid email providers offer the option of using your own domain name and have built in tools for setting it up. It is very much "follow the bouncing ball".
So, at that point it really comes down to which features are most important to pay for outside of just using a domain name.
@homegrown I'm currently using a service called https://mxroute.com/ that I have all of my personal and project domains pointed to and use MailPlus on my Synology NAS as the frontend (both web GUI and mobile app). It's not as fast as public services (delivery takes a minute or 2) but I have full control over my e-mails and data so I can maintain my own backups and easily move if ever needed (the frontend stays the same, I just change what servers it's pointed to).
Hope this helps! 👍
@homegrown That's what I do (with Fastmail), but I'd also recommend smaller services run cooperatively such as MayFirst in the US/Mexico (http://mayfirst.coop/) or Disroot in the EU (https://disroot.org/). They're a good balance between self hosting and having the expertise of a giant corporation. I'm unsure if they support custom domains, but it couldn't hurt to ask!
1. Yes, for >20 years.
3. Even the easiest packages to run your own mail require more knowledge than a non-technical person has, and they're not hands-off.
After I hit enter, I looked at the other people who responded- yes to basically everything.
Heck, even large email providers have problems. Gandi basically told me they have no control over spam mitigation blocks against their servers!
If you want to run your own mail server, it's something you'll do out of some ethical reason and you'll invest a lot of time.
It's almost like home schooling your children.
What about having your own custom domain with an existing independent email provider such as Tutanota etc?
Would this avoid most of the headaches?
(I realise it's not quite as indepdendent, but at least you could change providers without changing addresses.)
What about having your own custom domain with an existing independent email provider such as Tutanota etc?
Would this avoid most of the headaches?
I don't feel super strongly about this, but I think it's the optimal effort/reward balance for most people.
Encryption is still an option for those who want/need it, and you get many (clearly not all) of the benefits as long as you're not using webmail.
I'd need to think that through, but some initial thoughts:
I don't know of any straightforward migration mechanism. You'd have to migrate each account's mail contents. AFAIK there's no easy way to simply hand over administrative control and get all the account list.
I don't know a simple way to migrate authentication.
I don't know a way to migrate rules such as mail aliases, vacation policies, etc. That's not even something you can always ask for through a remote call.
Maybe it would be possible to do some of this. Someone will jump and say "You can just ___" but this depends a great deal on the implementation and providers involved.
I know of specific ways to probe specific systems, but in terms of a universal mechanism to migrate all mailboxes, all authentication, all aliases, all mail filtering rules, I don't know of any one universal way to address that.
One more thought on using 3rd parties....
A big part of the complexity in running a mail service for the first time is setting up DNS.
So then a non-technical person will need to go to their registrar and maybe the absolute easiest thing to do would be to set a "mail subdomain" and set the DNS server for that subdomain to the mail provider- that's not super easy.
OR they'd need to set a bunch of DNS settings themselves. That's even harder!
What if it was just email for an individual, or a small group such as family, friends or colleagues?
Would that make it more feasible?
It would be easier only in the sense that moving a single person living in a studio apartment is easier than moving a large family living in a six bedroom house.
The scope is smaller, but the problems of migration would be fundamentally the same.
What about forwarding, would that be least worst option for a non-techy person?
Someone buys a domain name and forwards mail to their standard account, but puts the domain name version on their contact forms etc.
It should be easy to just change which address it forwards to when they change providers?
I'm basically trying to avoid making someone totally dependent on a particular provider, in case the provider goes rogue or (more likely) gets bought up by someone nasty.
Let's work this through together.
Let's imagine I buy a new domain, say, example.org (lucky me that I got it somehow).
I use the registrar's UI and they offer mail (yay, not all do), and they let me make a forwarding address.
First, none of this is going to be uniform. If I do it on Registrar A, it won't be the same workflow as Registrar B. But let's ignore that.
I set up a forwarding address. I'll be email@example.com and it will forward to my real address.
I get an email from my aunt Sally to firstname.lastname@example.org - huzzah!
I hit reply and the return address is my old email address.
What if I override the email address on my From? Well if I do that, I'll get caught in a bunch of spam filters because I didn't have the right to send on behalf of the example.org domain- unless I specifically set all that up, which is what we were trying to avoid in the first place.
In short, there's no simple way to do this, except maybe one:
If you could convince someone to make a whole new registrar, a registrar we can fully, 100% trust, and that registrar was meant for this purpose, then they could maybe maybe make all of this easy.
But then you're still beholden to the registrar.
So no. There's no way to make email migration and self hosting easy do this with current technologies, period, end stop.
Right, okay, so, if someone bought their own domain name, pointed it at a normal address from a respected indie provider, advertised the custom domain address etc...
...AND they are okay with their indie provider's address (not the custom domain) being visible in the replyto section when replying to mails...
...would this be least worst way of having some kind of partial escape route if the indie provider goes bad?
At least they don't have to change contact details etc?
I think this is an important topic, and one we can't take lightly. It involves both technology and human interactions, much of which are set from people's intrinsic understanding of email going back decades.
Maybe I'm wrong and it's simpler than all that- this is common with someone too focused on the inside, unable to see new perspectives, but I think the best thing is to understand the technologies and then working out a new way.
I am trying to act as a bridge between experienced experts like you and people who aren't techy.
Deeply appreciate the time you have given with these replies, they help an awful lot 👍 🙏
Subscribing to a domain name from a registrar who doubles as an email forwarder is an option. Here’s the pitfall:
Registrars go rogue. I’ve seen several times a registrar put their website on Cloudflare (so your otherwise protected whois info becomes surreptitiously exposed to Cloudflare Inc). You can no longer login to maintain your forwarding addresses, unless you’re willing to expose your account creds and details to Cloudflare. The registar holds your domain hostage.
And worse, the registrar will ignore written requests for domain transfers to another registrar. They force you to authorize the transfer via Cloudflare. You can wait for your domain name to expire, but one of their sneaky tricks is to auction your domain off without telling you, then the registrar itself buys the domain name for 1 dollar, just to block you from going to another registrar.
@emacsen @homegrown I don't wanna minimize the difficulty here, particularly with migration, but some existing independent email providers explicitly support using their service with a custom domain, and the ones I've looked at make an effort to explain exactly how you set it up. I think it's within the range of stuff that a non-technical person could wrestle with for a day and then it works as long as they don't need to switch providers.
@homegrown In general, I think it's too difficult for non-technical folks, and it can be tricky even for technical folks.
Decent spam filtering can be hard. It's a lot better with rspamd than it used to be, but it's not simple.
Reputation is also tricky to navigate, since you need to make sure your machine gets an IP that has a good reputation. Hosting from a residential IP is almost certainly a non-starter.
Downtime (v possible if you don't set up monitoring) can result in unrecoverable mails, which for some folks can have serious consequences.
I do host my own mail, I enjoy it and it's fairly reliable, but I wouldn't recommend it for a lot of folks.
@homegrown Advice for folks that do want to do it:
- end to end mail tests
- individual service test
- don't rely on your mail server for sending alerts
- reputation monitoring like mxtoolbox
- Get a fixed IP, check the reputation on various blocklists and squat on it for awhile before turning it live
- Find a VPS that other folks host mail on and that block port 25 by default (I've used Vultr and currently use Hetzner)
- don't forget PTR records
- absolutely don't forget PTR records
- set up SPF, DMARC, DKIM (report-uri, dmarcian and DMARC analyzer can be useful tools)
- validate the syntax of these records using the tools on dmarcian
- did I mention PTR records
- SMTP: I've used and liked postfix and opensmtpd
- Spam: use rspamd, avoid spam assassin
- IMAP: just use Dovecot
- dkim signing: rspamd or dkimproxy
Have two servers ideally, in different regions. Dovecot can sync mail over ssh. Spin up one mail server first, then slowly shift mail to the new one by shifting the MX weight more and more to the new one.
Tbh, I'd avoid grey listing? Some folks swear by it, but since many major providers use large numbers of different servers as MXes, and just using smtpwalk or whatever on a growing number of domains doesn't really scale, and the cost is heavily delayed mail or undelivered mail, I wouldn't recommend it.
Single-user Mastodon instance for the Grow Your Own Services site