There are many sending MTAs that need to be whitelisted before greylisting works reliably. That's the big problem with it, IMO -- it's actually pretty labour-intensive to operate, and false positives are hard to rescue.

I implemented greylisting a few weeks ago and it had a dramatic decrease on my spam volume. Any MTA that can't impelement RFC 821 properly (it's relatively new at 24 years old) is going to lose a lot of mail.

Greylisting captchas

"In order to continue using LiveJournal we need to be sure that you're a human and not a robot. Please type in the text in this image below. [Image scraped from Earthlink]" Followed by backending the answer into Earthlink.

A lot of problems are solved by the Chinese Television/Lottery approach. And here you don't even have to promise anything new since you've got a captive user base that'd probably (mostly) silently accept it.

But more generally I've almost given up on email being reliable for any use these days. Greylisting just seems like a last ditch attempt to escalate the war, and seems to be resulting in spammers preferring to gain control of webmail, etc, services which feed into real MTAs to do their dirty work. I know people say "it seems to work" at present, but that's been true of every other escalation step on the anti-spam side... for a while. And unlike some of these steps, greylisting makes things worse for non-spammers too, in a way that it seems we'll never be able to undo. Sigh.

Parsing the greylisting messages and retrying exactly on time sounds like a good work around, though.

I find it funny (unless you have to work with it like you do, I guess) that all these servers return human readable text to indicate how long you should wait. What, they think everyone types their mail directly in a connection to the smtp host (whose address we got from the mx records manually)??

I wonder if they can even just process their own text replies, let alone what others reply...

and then when Alice opens a trouble ticket because she sent Bob mail and it never arrived, I can look at the logs and tell her why. If I find the mail still hasn't delivered after a few attempts over the course of an hour, then the "five minutes" part tells me I should probably give the postmaster at example.com a shout to see what's up.

Evil, filthy spammers. They're like Hobbits but more filthy.

You hit the nail on the head when you said the people who write and use this just don't care. I've met a few of the folks who think SORBS is a really great idea and yes, this is exactly the case because of how they think -- collateral damage is completely acceptable in their world. Breaking known process/RFC? Too bad, they're stopping spam! Dumping mail that other people are expecting, based entirely on faulty and arbitrary information? Too bad, they're stopping spam! Violating the basic Internet precept of "be conservative in what you send and generous in what you receive?" Too bad, they're stopping spam! I think this may be because they're in control of their own mail system and don't actually have paying users who expect mail to work. My users, who know only that their mail did not get delivered to a particular site, don't care that our mail relay got tagged as a spamfeed (even though it isn't... it's just relaying mail to/from an enterprise of >2,000 people). They just know it's broke and that it should be fixed, and what do I mean it's out of my hands?

So yeah, in my world these things are great in theory but in practice they cause as much damage as they prevent.

You are so incredibly correct. I was testing out a blacklist on a personal server to ensure it wasn't overly restrictive. Well, at one point it had blacklisted yahoo, hotmail, and gmail. Better yet all the mail from those hosts that hit my server was all legitimate email from friends and family. I followed that up by never using that blacklist again.