I think Step 7 is a good idea. Initially, I asked some contacts to send me an email from Gmail and Protonmail, to which I replied. From then on, my emails work fine with them (negative spam score).
I'm in your reverse situation, a long time free-email user. Given the latest news, I decided to self-host my email address and not have a 3rd party filter my Inbox.
I'm surprised how easy it is, and having fun with sieve scripts :)
Long time self-hosted email user, then long time Gmail user. Playing with your own server is fun, and I really enjoyed it. But things do go wrong, and they go wrong at the least convenient times. I've lost a whole day of a holiday trying to find a place with internet so I could log in and fix some small thing that had broken (I also hosted for a handful of other people, not all of whom were on holiday). And I've had that sinking feeling when you realise that that important email you've been waiting for has been sitting for a day and a half behind a crashed/misconfigured service somewhere.
Good luck with your endeavour, it is if nothing else a learning experience. But it's important to keep in mind that if email is a critical tool for you (it is for many people, ymmv), toying with it may not be the best idea.
I'm just now experiencing the direct opposite with Fastmail. Used it to avoid setting up my own mail server for a ~50 user gitlab instance. Went from trial user to paying for a full year and one day later my account is now blocked. Found this message in the first rejected email: "We couldn't figure out what the email is for. Please create your issue or comment through the web interface.". Can't send mail through webmail interface. Can't access IMAP nor SMTP. Support emails from their own support doesn't go through.
So, without any means to control it myself I'm now in the mercy of fastmail support unless I set up my own postfix/dovecot in the meantime. I guess it goes both ways.
… hang on, what plan did you ask for for this, and what kind of mail were you actually sending/receiving? As far as I'm aware, Fastmail charges per-user, and isn't advertised as suitable for sending automated mail through. It sounds very strange to use it as a replacement for “setting up a mail server for a GitLab instance”.
What ToS am I violating exactly? I’m _well_ within limits for both incoming and outgoing and all recipients sign up for receiving the emails. The gitlab wiki even uses fastmail as an example for smtp.
I try to find a balance - I run my own mail server on a digital ocean droplet, but I use gmail to fetch email from it, and I use gmail as my sender.
I get the best of both worlds; I don't have to worry about being blocked when I send things, and if I ever have issue with gmail, I can stop using them without losing my email address.
I vaguely suspect that GP may refer to the fact that certain corporations block access to the Gmail web interface (and the other big providers) from their network, typically for auditing purposes, in a way to a personally run mail server might evade. In those cases, actually accessing your personal mail server would typically be a gross breach of conduct and lead to immediate termination for cause if caught. This, of course, has nothing at all to do with the deliverability of email from those services, even to these same organisations (they can audit what goes through their own servers, so that's fine).
But, that's a guess, and I obviously can speak on GPs behalf.
Yes and also they block receiving emails from GMail domain for security purposes. So if you want to email someone internal in big co, you have to do it from your own domain. I suppose it is not only for GMail. Probably Yahoo, Microsoft also but I only had one guy trying to use GMail sending mail to corporate users.
Before you said "spamhole", now it's security. In both cases it makes literally no sense to block Gmail and allow random personal domains. I suppose the setup could be based on whitelisting domains, and because Gmail is so big, they won't whitelist it, and it also won't receive emails from anything random, but from specific personal domains. But such a setup specifically isn't for communicating with the world at large, and not any kind of widespread practice.
Also, you should be using your own domain with Gmail (or any other provider) so you aren't tied to anyone, anyway.
Any sane corporate security? You can setup gmail account in 5 mins and start phishing people in corporate env. That is why receiving emails from generic domains is no go. I also had actual requirement where we did not allow people to register with gmail account, only non generic domain emails allowed. So that you use your company email for B2B product.
I don't remember the details, but it probably didn't become misconfigured, it would always have been misconfigured, just one particular combination of factors that hadn't been seen before suddenly got caught. I remember at one point that an org I did email for couldn't receive email from a particular other organisation. Turned out that I had configured our MTA to accept TLS, and theirs presented an invalid cert, so the connection was rejected. This wasn't the situation I referred to, because this caused email to bounce hard, so people just routed around (yay for having people have professional contacts send to their hotmail instead).
Or whatever. I remember the feeling, not the mistake that caused it.
When renting a dedicated box, a VNC-like interface is required to enter disk encryption password, which could be intercepted by the host. Moreover, this has to be done on each restart. I look at dedicated box more as an upgrade from VPS.
For privacy, I think user encrypted email messages provide the best option.
At home self-hosting through VPN is a good idea. It would involve maintaining hardware, which I traded for low cost VPS. With a replica backup MX, I am not married to any hosting provider, and can hop without downtime.
" a VNC-like interface is required to enter disk encryption password, which could be intercepted by the host. "
There's a rule in security that anyone in physical possession of your device should be assumed to have access to it. The host has the server whether physical or virtual. You're not safe from them. Trusting them is the tradeoff made for the cheap, hosted server.
" I look at dedicated box more as an upgrade from VPS."
Multiple VPS's share a physical box. A malicious VPS can look for secrets in another VPS using side channels. This isn't possible on bare metal: they have to compromise an app or get a shell first. The next concern would be endpoint security. OpenBSD covers that well. Then, there's host or peripheral firmware which is almost always a risk if a 3rd party is hosting things. Your attack surface does go down, though, when you're not sharing a box with an attacker. There's also the performance benefits.
Privacy from host is not possible, and you make a very good point about hardware access.
Virtual machine are secured by the shared host. I don't really expect top security from this end. A replica backup MX enables me to safely change hosts, if they behave badly.
OpenBSD defaults are what I base my endpoint security on, and keeping this updated is super easy.
"Virtual machine are secured by the shared host. "
Virtual machines are not secure in mainstream implementations. The tech they use has had a lot of vulnerabilities in the past. Google and Amazon even have their own custom versions for improving security. There's also no covert/side channel analysis done on those to even know what information leaks will be found in the future. Finally, hardware-level attacks are possible if you have malicious code running that bypass VM protection. Most popular recently is Meltdown/Spectre.
There's only been a few VMM's designed for security (two examples below). Most of them probably cost five to six digits to license. The FOSS ones are alpha or beta quality without the tools a big host would want for management. The VMM's focused on rapid development of features in unsafe languages don't look anything like the ones that passed pentesting. They also have highest marketshare due to those features. So, your host serving cheap VPS's is almost certainly not using a secure VMM: they're saving money using an insecure one on insecure hardware that they're patching as vulnerabilities are publicized. Like almost everyone does with their OS's for their beneficial features. ;)
There's no need for a visual desktop just to enter the passphrase. You can also do it by logging into a minimal setup that is inside the initrd via SSH (dropbear).
It is a standard debian feature.
The last time i rented a new server I checked the IP in the various blacklists. There was one blacklist that had listed the entire subnet the server was in. I asked them to whitelist my IP address in that subnet which they did. It took only a few minutes to write an email.
I had this sort of thing happen yesterday. Two IP addresses in my email server's /24 were flagged for spam so the whole range was blacklisted. I wasn't able to send email for about 8 hours until it was cleared for me. But this was 8 hours of outgoing email downtime in two years of running my own server.
It's the private lists that will get you. What do you do if Google has your IP address on an internal blacklist? Or your health insurance company? Or some random Barracuda-style e-mail filtering appliance? Nothing. You're screwed.
In that case, the IP is screwed. I plan change IP, or hop hosts if/when this happens. I opened 6 accounts on 6 different hosts, and only two are active for this reasons. So far so good :)
