Assume the following setup;
- A shared hosting server, sharing a single IP with many small websites.
- A subset of the set of websites is sending e-mails. Some of those e-mails may be to their own domain.
- Another subset of the set of websites is hosting their mail on another platform.
- A third subset who host is vulnerable to a remote code execution vunerability.
- In the Venn diagram for subsets (2), (3), (4), assume any part can be nonempty.
There are issues with spammers becoming more and more competent at circumventing the installed security measures. With full code execution access, a hacker can circumvent the usual Linux mailing stack and instead implement their own E-mail server, directly communicating via socket code to external mail servers and sending a massive amount of spam.
A server is a pretty powerful machine, so such free-roaming code can send significant enough amounts of spam to get on the radar of the Big Boys, such as Microsoft and Google. These companies have their own home-rolled obfuscated proprietary systems which tend to block based on IP. I know that this is a stupid thing to do: IP does not equal a unique machine. Obviously a small hosting provider can do little about these Big corporate policies, and you cannot ignore them either; lots of consumers (e.g. users of the websites on the platform) will have e-mail addresses on the platforms of the big providers.
There's also an element of secrecy involved; the big companies are actively trying to fight the spammer botnets, so they provide no or minimal further information about any blocking so the spammers can't use this information. By sending spam that's 'signatured' they may have identified the particular botnet and marked the hosting server as a suspected cybercriminal tool. It's not entirely unreasonable, because truthfully that's what the server is being used for at that point.
IPv4 address exhaustion means that non-shared hosting is just a non-option for these small websites. It's financially just not achievable.
Note; assume there will always be some vulnerable sites, that's an intrinsic weakness of a shared platform, not every customer will have their code equally secure.
Upon being hacked, the customer is of course notified. Standard procedure is to take the site offline and reinstate a clean version, requiring the developers to fix the security issues before that.
Still, there remains a pretty big problem; One tiny mistake for one out of many websites will effectively shut down the e-mail for the entire server, and getting everything back up again can take days by curing rather than preventing this kind of issue. As sites get older, more sites start using the same IP, and spammers get ever more competent, the situation will get worse and worse over time.
While I can think of some partial solutions, so far they've all been unable to keep the full feature set we're providing. For example, I've tried blocking outgoing traffic over the standard E-mail port (25) through the server's firewall for all users except root and a trusted e-mail user. This will fully prevent our spam problems, because this means the websites are required to use the standard stack, and it's simple to configure things like rate limiting and spam filters for outgoing mail on this standard stack.
The tiny amount of spam that can still get through would not put us on these secret ip-blocking lists.
This works for most of the websites; but not all. Subset (3) is throwing a wrench into the works if combined with (2). Let's illustrate:
Our host (IP = H) is supposed to send a message to a microsoft host (IP = M), through its mail server. Say we send from 'firstname.lastname@example.org' to 'email@example.com'. If this message is sent directly, everything works. However, when sent via the mail server, it needs DNS records. But then it tries to send to localhost (H), this fails, because (H) does not have the mailbox 'contact', that should only exist on the microsoft host...
Furthermore, plain blocking everything like that may not work for all the websites; some may have their own built-in mail engine, although if with some fiddling we can overcome the problem above I'm not impartial to telling these people to fix their software to use the correct mail program.
I'm interested in opinions about smart(er) ways of going about this conundrum.