I use this this fake MX (a variante of the nolisting) and it works very well.
I used a postfix MX with all the usual filters and after some spambot manage to overload the server for 2 or 3 times i decided to give it a try...here is the result:
try to guess when i have implemented the fake-mx! 8)
The result is the same as postgrey, but unlike postgrey, you don't need to change your mail server
The spambots now will either try the high MX or the low MX, freeing the real MX from the load of trying to filtering then (even with DNSBL, the load was high) and real email arrives with minimal delay.
But be warned, there are risks:
Some servers might have high retry times. Most servers will retry the next MX after the first one timeouts, others will try in the few minutes next, but i already saw servers that only retry after one hour or one day. They are very rare and for the ones i could catch it was a bad config. talking with the other postmaster fixes the problem
All emails will have a delay. Actually i see no delay at all, almost all real mailservers will retry to the next MX after the the first timeout, so we are talking about 30s delay. They usually try at least 3 MX before queueing the message for a longer delay. but you might have contact with one broken mailserver that might not do this and delay every message for minutes. So this is a thing to monitor when deploying this solution.
Broken sites. Some webservers send email for passwords, notifications, etc and instead of delivering for a internal real mail server, they try to be a "fake" mail server and delivery directly. As its a webserver, they will never retry and the email is lost. Again its a bad configuration from the webmaster/web developers, as only real email servers should send email. every time i find this problems i talk with the webmaster about the problem and usually the problem is fixed.
No logs. As the fake MX poing to unconnected IPs, you have no logs of what tried to be delivered. you now that something went wrong when someone complains. but this also have a good side. you can always claim that you have no try to deliver any email, so its a remote
problem. The other side must check their logs and solve the problem. I can prove there is no connection at all, moving the pressure to resolve the problem to the other side. If the other side is unable to fix the problem it looked as untrusted, unreliable.
No whitelist. this applies to all servers via dns, so you can not whitelist one server... actually is just half-true, but is harder. the whitelist solution is that the lowest MX points to a IP where a smtp is running, but filtered by firewall for everyone. Those servers you want to whilelist needed to be permitted in the firewall. This way all servers will be rejected by the firewall and the whitelisted will be able to deliver to the mail server. It works, but only for IPs whitelist, not for email whitelist.
Unlike postgrey, where the remote sender have a log of a "rejected" delivery (and so can point at us as the problem), the fake-MX will show that the webserver could not even connect and didn't retry, giving no excuse for the remote side about the problem. A failing MX better accepted over postgrey, as we can always claim some "routing problem, but the backup MX is working fine, we get all other emails"
with that said, i get very little complains (about 1 every 3 months), so i consider it safe enough (every spam filter have risks).
Please note that i use valid ipv4 address for all the MX, but for the fake ones i use a IP that i control that is not in use (and so it gives timeout/host unreachable on any connection). this rules apply even if you don't use this. There are dns and smtp servers that require a perfectly valid dns config for the email to work. the fake-MX must also be valid, they should just not be reachable.
Do not use private IPs or IPs that you don't control for the fake MX (if you add ipv6 address, ALSO add a ipv4 one). This avoid problems with broken DNS and mailservers and surprises of other getting your email (by installing a smtp server on the IP you don't control). Also, CNAME are forbidden for MX, so don't use it also, just a plain A record
Finally, a tcp-reset should be sent for the fake MX, to improve performance (host or port unreachable) instead of a plain timeout (by dropping the packet), so it's recommended to add it to you firewall.
anyway, not only i still use it, as i recommend everyone to use it