Today, for the second time, I found my BlueVM VPS inexplicably offline.
After logging into the Feathur host manager, I was greeted with a suspension notice, telling me that my host had been taken offline and that if I wanted to know why, I should contact support.
The BlueVM ticket number is #677829.
BlueVM responded quickly (which is good) with the following reason:
"Your VPS was suspended by our Spam detection script. We allow a maximum of 8 concurrent SMTP connections, and your VPS exceeded this threshold, tripping the script."
It's true, I have a mail server on this host. It's being used as a legit small mail server by a small business (oncology practitioner) for which I am a consultant. No spam, marketing mails, mailing lists, or anything like that. In fact, there are only two local users at this time.
I am the legit kind of customer tiny VPS companies desperately want.
This VPS was just set up on May 21st, a little over two weeks ago.
So, how many emails were really being sent by this host since then?
[/var/log] user@hostname: egrep "courierd: started,.*,from=" mail.log mail.log.1 | wc -l 17
Seventeen. There were seventeen emails sent from this host since then. Most of them are from me, sending test emails to make sure everything was working right. About five of them were real emails being sent between persons. There is no way at any point there was more than a single outbound SMTP session taking place on this host.
So, this means BlueVM was counting inbound SMTP sessions, for which my logs are full of denied relay attempts.
So, because my mail server was being attacked by spammers, and rejecting their attempts as fast as it could, my host was shut down.
I have a problem with that.
Now, I understand the market in which BlueVM and other tiny VPS hosting companies work in. They are constantly under attack by scammers, crackers, spammers, and the worst goons the internet has to offer. People are constantly trying to set up spam relays, snowshoeing, and other such problems. Monitoring customer activity to detect, stop, and event prevent abuse is a requirement to stay in business.
However, in this case, it failed, and I am going to charging my client the time to takes to resolve this issue. This is a tiny oncology doctor's office that can't afford crap like this.
BlueVM, review your procedures and stop this from happening to someone else.
When new customers sign up, let them know right on the VPS manager panel that they need to register their host to send outbound email. You can do it with a checkbox, or tell them to open a ticket to get their hosts whitelisted.
Now that I think of it, this might be a great way to get any BlueVM host shut down by an outside party. Just initiate a bunch of SMTP sessions towards it and BlueVM might suspend. They may not even need a mail server on TCP 25 to trigger it. Hopefully, BlueVM will review their practices in this matter and make sure it's not open for abuse.
It's not like you can't tell the difference between an new outbound SMTP session and am SMTP reply (SYN vs SYN,ACK).
In addition to the above complaint, this host was taken down on the first day after it was set up, because I had requested from BlueVM that they rename the user on my Feathur account. When they did this, they shut down the VPS without notice and reset my main account password (which I had not requested be done). I didn't get any of their emails because their support mails triggered Spamassassin to dump them (not bayes, it was a Razor listing and multiple other format problems).
The host performance has been good for me, and the price/value for what I got is great. I will also say that they have been pretty good about getting to my support requests. Their account and host manager systems are great, and Feathur includes a means to set your rDNS PTR without a ticket, which is great.
If it wasn't for these two incidents, I would highly recommend BlueVM, but they have f-ed up here.
--
UPDATE: I am mostly satisfied with the outcome here.
I am not happy this happened, and I'm not sure this won't happen to another customer, but BlueVM handled this pretty well.