Not having to rely on big providers like Google for your email can be a nice thing as it gives you more control and hands less data to them. Sadly it also is pretty annoying to set up and keep running. Especially if you try to do it from scratch. I did this the first time and I also setup a database for the server as well as roundcube as a web client. Since this was such a tedious process and my mail was rejected by some providers I left it at that for a while. There’s probably alternatives to dovecot and postfix, but I’m too lazy to look into them so when I setup my email server for the second time I just went with emailwiz which is a short script that will configure both dovecot, postfix, SpamAssassin and OpenDKIM.
The whole setup worked well and I can still use something like SquirrelMail if I need a webclient. As I only have a hand full of accounts a database is overkill. However here I am writing this and noting down two things that I learned the hard way. First off some provider will require that you set a PTR record for your domain. This is basically the opposite of DNS, it allows someone to search for a domain via an IP address. The problem is that not every VPS provider allows you to do this. The first host I used did not, but other two I’ve been using allow it, but this wasn’t the real problem. After a couple of months with no problems I got a notification from my provider telling me that there was a spam report with my domain and that I have to look into this otherwise they’d have to lock my VPS. That was obviously pretty surprising considering that I have a very simple setup that shouldn’t allow anyone to get into my server.
The first thing I did was frantically checking logs to see what was happening.
After realizing that the logs were pretty long it was clear that someone was
sending a lot of mail. So I stopped the postfix service and tried to figure out
what the problem was. The email was sent from an account that I set up for an
account that was only used for one of the services that I hosted on the VPS.
The first mistake was that that account even existed. The service that I hosted
doesn’t even have the ability to send mail and there’s no reason for it do that
anyway as it was basically just a web client for playing music. I didn’t know
that at the time so I also stopped that service thinking that maybe it had a
vulnerability that allowed attackers to use it to send mail, but that wasn’t
the case. So I then assumed that someone had found out the password for that
user so I checked what the password was and as it turns out I never gave the
user a password. Running test NP 10/09/2022 0 99999 7 -1 showed the following:
test NP 10/09/2022 0 99999 7 -1
If I had to guess ‘NP’ stands for No Password, which makes sense as the user doesn’t have one. This confused me quite a bit. Then I checked the status of another user and got
test L 10/09/2022 0 99999 7 -1
So there was a difference between the two accounts. The account which was used for spam didn’t have a password, which I achieved by deleting it. Looking at the manpage for passwd we see that deleting the password does the following: “Delete a user’s password (make it empty). This is a quick way to disable a password for an account.” That sounds all fine and dandy, except for that part in the parenthesis. By that point I already had an assumption and when I logged into the account via a mail client it was confirmed: Dovecot will happily accept logins for accounts with deleted passwords and the password is just empty. I don’t know why that is the case and why anyone would ever want this and why this is default behavior that obviously does not mirror the behavior of the actual system account that the mail account belongs to, but that was it. In hindsight it’s surprising it took this long for spammers to realize that this account existed.
That was the first lesson I learned. The second one was that contrary to what Luke says in his tutorial for emailwiz, the dmarc account is not something you should ignore. The dmarc@yourdomain.com account is where spam reports get sent and if I had frequently monitored that account I would’ve found out about this issue a lot sooner and could’ve probably fixed the issue after the first few spam mails were sent out. After fixing the issue I constantly monitored the mail logs to make sure everything was fine just to find out that it was not. There were still spam mails sent out. None of them arrived obviously because at that point the rating of my domain was so bad, but that’s besides the point. Once again the problem was configuration. For some unknown reason postfix will queue up thousands of emails from a single account without asking any questions, even thought the account that was sending them did not exist anymore as I had already deleted the corresponding user. After I cleared the postfix queue the problem was finally dealt with, but the damage had obviously already been done. I ended up adding a setting that limits postfix to a maximum of two outgoing mails per account every two minutes. I do not send email often so this is more than enough and it would deter most spammers. I also made sure to never add users to the mail group unless they absolutely have to be in it. Additionally I configured fail2ban to very aggressively ban IPs that fail to login.
So those are the things I learned here. While I won’t be able to send emails to Google et al. for a while I will still keep my own email server. Anyone that tries to contact me from those providers won’t get an answer, but I don’t really care. The reputation of domains apparently improves over time so eventually I might be able to send mails properly again.
TLDR:
- Do not add users to the mail group unless absolutely necessary, also check what users are already in it via /etc/group
- Do not delete passwords for users in the mail group, otherwise dovecot will allow logins with empty passwords
- Set an outgoing limit for postfix to prevent large amounts of mails being sent
- Regularly check the dmarc account or forward it to your main account
- Use fail2ban to ban IPs that attempt to login and ban the IPs for longer than the default
- Check your logs frequently
For the limit in postfix you can add the following to /etc/postfix/main.cf:
smtpd_client_message_rate_limit = 2
anvil_rate_time_unit = 120s
That’s it. Maybe it’ll save others from having their VPS abused for spam.