I’ll delurk again for this one…
I know that at least some of the code for panel-based SPF implementation is done; it’s a project that I was part of when I was working at DH. I don’t know if they have plans to implement it still, but it’s definitely something that was under consideration. Any such implementation would include a way to add custom records, include records from another domain name, etc., in addition to generating the correct SPF records based on services configured in the panel. It does seem that SPF adoption seems to be slowing a lot; still hard to tell whether it’s going to be a “success”.
In terms of the mail server hostname in greeting thing… dnsreport is awfully pedantic. I read through the applicable RFCs a while back, and I’m not sure that this is actually a violation… in any event, because of the way things are setup (with the mxN.xxx.dreamhost.com being a virtual IP), machines will always send their actual hostname as the HELO string. In any event, the server isn’t really claiming to be a host it really isn’t - it’s just claiming to be a server which isn’t directly named as the object of the MX record. I guess it’s subject to interpretation, but I have /never/ heard of this causing any actual problems for anyone.
DH does do some blocking of mail based on blocklists, however they are pretty conservative, blocking open proxies and some really bad spammers. cbl.abuseat.org is the main one that’s used, as well as an internal blocklist I created, and which appears to still be in use on at least some machines. I don’t know if they will continue to maintain it. The Spamhaus SBL might be a good choice, but there is some occasional collateral damage with that one (however, the Spamhaus folks do a good job of keeping on top of stuff and removing stale entries).
Implementing per-domain or per-user blocklists causes a lot of problems (both social and technical). Messages that are rejected are rejected with a hard (5xx) error code, though there’s currently no way to get a report of mail that was rejected. A system like the one you describe in your message is a little kludgy (basically just grepping through the logs), and wouldn’t really work well in such a large scale environment.
There are some other Postfix checks to block mail based on obvious spam signs (trying to send mail with HELO of the mail server’s IP or hostname, etc.). So some of what you’re describing is already happening “behind the scenes”.
Rejecting 90% of spam requires settings that are way too conservative for a large and heterogenous user base (IMHO). I think last I checked, probably 40-60% of mail was being blocked (outright) as spam.
I know it’s a pain to look through the archives, but a lot of this stuff (almost all of it) has actually been discussed, and addressed, in the past.