One of the reasons I can see spammers continually trying to connect to a server, is because they get rejected quickly, and have more than one bot to go and retry.
I think the better solution to this issue (and issues related to SMTP auth attacks, and 550 errors), are having an error counter in the mail server software, and if they hit a number of errors, the connection is then blocked and the IP is firewalled (denied a connection) any further.
This is rather easy to implement, because most servers can choose whether they accept or deny a connection, and in the case I am thinking, it should be a matter of looking in an array, seeing if the address is firewalled, if it is, then the connection attempt simply isn’t allowed and the server doesn’t open it at all.
That, will in turn make spam attempts like the 550 ‘guess’ ineffective, and ultimately destroy the spam attempts, getting closer to eliminating the needless waste of bandwidth the attacks on mail servers.
Spammers who try methods such as address guessing will find themselves unable to connect to many servers, and could perhaps consider a new career, perhaps as garbage collection, to repay for all the garbage they spit out.
As it stands, it is possible to analyse an army of logs I have now, and calculate the spammer IPs and place those in a database, which will be loaded by the server on startup and stored in an array.
The server then on connect attempt, will search that array for the address, and if it finds that it is in that list, then connections are denied.
Adminstrators of the server can then go and check a list of addresses and see if any are of interest or not, and if necessary remove them.
Most good configured mail servers which find they are disconnected will retry for days after, so reviewing a list of addresses (sorted by date added) should be a painless task to do.
This feature would be used in conjunction with greylisting for example, which already tells senders to try again later.
The IPs banned would be those which score 5 errors in a single connection, as these are typically the problem connections, from 221 and 89 IP ranges (but I’m not racist, or is it ‘IP-ist’ ?), so won’t block full countries of IPs.
This isn’t a complete solution to the identified issue, but, it’s a start at making it even less effective.
Enjoy!