Let MUA and MTA talk

Let MUA and MTA talk

At least one good property of this approach is that you don't have to wait for large scale adoption before it works for you. You change it and you benefit. The problem, it seems, would hit large ISPs who would run out of TCP ports. Perhaps they could get started with a good black-list. There is still a problem with myDoom-type viruses if their spread rate is too fast for the black list to be effective, but that may not be a problem in practice.

This sounds like a Very Good Idea to me, particularly if it includes parts of the variable viscosity tarpit commented on above by "Baylink". Whitelisted email sails through, email from an unknown sender gets slowed a bit (this alone could slow the initial expansion of the next MyDoom), unknown email with spammy characteristics gets slowed by the maximum RFC 2821 allows, and blacklisted senders get rejected. Large ISPs willing to invest some CPU time might take the average of all user whitelists/blacklists into account when deciding how viscous to make the tarpit (but never completely blocking a message the individual recipient hasn't included in his personal blacklist).

I like that it's a decentralized solution; there's no centralized authority beyond the ISP to decide what's good and what's bad email.

I imaging mailing list software such as MailMan would quickly add some features to cope with clowns who subscribe to a mailing list but fail to whitelist messages from it. The mailer could keep track of which addresses accepted mail slowly and on the next run and would not try to send to them until after the fast ones. Not all mailing lists would benefit, but ones sending biweekly newsletters could get the majority of the emails out quickly, leaving a few days to deal with those MTAs deliberately slowing the connection.

One drawback I see is it gives your whitelist to your ISP, creating another collection of info John Ashcroft and friends can demand.