131–140 of 209 posts
Yes?
> Do you run a mailserver/host email accounts on your domain?
g-suite free - multiple domains + simplelogin (previously used anonaddy) with a custom domain (actually a subdomain of one of my gsuite domains)
I have not had trouble sending to Gmail. On important emails to Gmail addresses I BCC my own Gmail account. If my account does not get the mail I figure there is a problem. For me it always goes through.
My setup is stable. In the past ten years I had my current setup, but also other domains hosted via Google Mail, or by my hosting providers etc. They all had migrations, discontinuations etc. I migrate them all to my mail setup. I have no such hassles with the email servers I myself set up. It does not have large changes (by servers I mean the primary and queuing mail servers).
I have a lot of experience doing this though, not sure how hard it is for others, but it is a lot easier than the old days of configuring Sendmail with m4.
I hosted my own mail for years. I stopped just due to inflation. I have been cutting every single cost that I can. I already pay for iCloud+ and it now supports custom domains and the like and has encryption, so I moved my email over. If I wasn’t trying to trim every possible cost currently, I would still selfhost. It’s trivial if you have any sysadmin/syseng experience and a little time for setup. IME, the main thin…
I did this too (migrating from Google Workspace using imapsync¹) and it works great. Most people don't realize that Apple has been hosting email for decades and is quite good at it.
¹ https://blah.cloud/miscellaneous/migrating-google-workspaces...
Disclaimer: I'm a passionate Tutanota customer.
I run my own email. I have my own physical servers, that I built and tested myself, that I'm colocating. They handle both incoming and outgoing, and I've been doing it for so long that there is no previous reputation for the IP addresses I use. In spite of how vehemently some people, Reddit's /r/sysadmin, as an example, want you to NOT host your own and use issues like deliverability as reasons, it's really not hard…
I have a spreadsheet where I compare what it would cost me to do this in a cloud or on VPSs, and though there are some squishy factors (I enjoy messing with servers occasionally, when I have to visit the colo I also visit old friends in that area, etc.) it's still cheaper for me to keep my physical servers in my colo.
If anyone has any experience with Docker-Mailserver, please share. I'm exploring exiting Gmail. https://docker-mailserver.github.io/docker-mailserver/edge/e...
I don't have a web UI for it at all (though I briefly integrated with NextCloud Mail for that) since nowadays I just use Thunderbird or a similar client for that. Personally, the aspect that I like the most is their approach to doing some common actions, in the form of their setup script, you don't even have to connect to the container to use it: https://docker-mailserver.github.io/docker-mailserver/v11.3/...
The aspect that I like the least? Well, just how mail servers are architected in general, they even have a nice page on this: https://docker-mailserver.github.io/docker-mailserver/v11.3/... (things get even more complicated once you introduce additional security solutions into the mix, like ClamAV, SpamAssassin, or others). Projects like docker-mailserver or Mail-in-a-Box abstract some of that complexity away from you which is good as someone who doesn't want to sink hundreds of hours into it...
However, it's still there in those packaged and preconfigured/integrated components, rather than as one monolithic package that does most of the stuff you want, if you would compare some of the web servers out there against how many of the mail servers work, for example. Then again, something like Apache2 has bunches of modules anyways, so maybe that comparison isn't as cut and dry. Regardless, it feels like even with the scripts and the documentation, it's just a time bomb that's waiting for X years to go off when the pieces will decide to no longer play nicely with one another, and then you'll really need to dig into it, like when your Linux distro bootloader decides to die one day.
Outside of walled gardens, that might be one of the reasons to do a double take before putting everything on your new self-hosted mail server. Test drive it first for a few months/years, gradually move stuff over (and be sure to have tested backups that you can actually restore/access when necessary), maybe look into recovery addresses in other providers where applicable or where it makes sense and so on. If your mail client backs everything up locally, the server going down shouldn't be the end of the world and technically you could just move over to a new instance if everything's FUBAR, but having to drop everything because you cannot receive any new e-mails (such as a link to confirm doing something) would be rather disruptive in certain circumstances.
Self-hosting email isn't hard if you know the basics, and there are lots of resources online. Not like, say, self-hosting asterisk, which is a bit more of a pain (and I also do, reluctantly, but I barely use it, webrtc+asterisk is useful).
Having access to mail logs has been very helpful for various things. I also have aliases that connect to various (self-hosted) Gitlab projects for work, where we use service-desk.
I know that for most companies, self-hosting does not make sense financially, but our company does not make a ton of money, my time is fairly cheap (a few hours a year), and having control on the infra means we don't have to worry about how many seats/licenses we have, we can just do whatever we want.
Quite often, working with other companies, we end up having these artificial barriers because they can't afford to create an account for me on their issue tracker. So now we have a dozen companies using our systems, because it's all setup, it just works, and no artificial barriers, just a bit of disk usage and good backups.
The server-under-the-stairs (dl380g7, Proxmox running containers with services, one of those being the mail container on which Debian/Exim/dovecot/greylistd/spam assassin/dovecot-sieve). Backup to several external locations, mail archived for about 25 years.
I used to in the late 90s early 2000s, but it became impractical. I also maintained one as part of my job in the 2000s, and it became obvious that the amount of upkeep/time was not worth it just to host it yourself. The main headache? Anti-spam. A lot of IP ranges are just outright broadly blacklisted (e.g. residential IPs, some hosting services), but also a lot of individual IPs reused by hosting providers got black…
Self-hosting email for over 20 years, I will say most of what you stated is either greatly exaggerated or grossly factually incorrect.
Plus I have as much experience between commercially and personally, and that is my take. The fact you couldn't give one single example should give people pause.