Well, there are many non-standard or unspoken rules that aren’t part of any RFC, that certain email providers may check, like that you should have an A record for the main domain name (second level domain) that at least points to something, usually a website, which I guess is one of the reasons why MaiB provides a simple HTTP server for static websites.
Or for example, Deutsche Telekom, a large German ISP, will block your emails if you don’t publish at least a minimal contact note with your last name and a mailto link to the postmaster mailbox, for which the HTTP server can come in handy.
And of course there’s your case, where Proofpoint apparently wants you to use a descriptive subdomain that clearly states your server’s role as an email server, although I’m still not a 100% convinced that this is the actual problem that led to your IP being blocked. Either way, it certainly doesn’t mean you can’t run other services or host multiple domains on the same server.
Also, such additional and non-standard “rules”, whether they seem reasonable or not, are of course a consequence of the fact that the email system still cannot effectively prevent spam, even though a whole bunch of RFCs have been added to it over the years, making what was originally a very simple, decentralised messaging system very complicated.
This is all very unfortunate, of course, and makes it difficult for individuals or small businesses hosting their own email server to send email reliably, but I don’t see any way for a project like Mail-in-a-Box to track and account for all these non-standard things that email providers or security companies like Proofpoint may implement, which also can vary from provider to provider and change at any time.
However, Mail-in-a-Box does a very good job of implementing all the actual standards relevant to email deliverability that are defined in the various RFCs around the email system 