Does SMTP greylisting a) stop much spam and b) stop much legitimate mail?

I've just set up an SMTP server on a relatively little used domain using Postfix and enabled greylisting with SQLGrey. So far it seems to be working OK, and while there's the slight irritation of delays to emails from new senders, I can see from the logs that it's deterring a number of spam messages.

In your experience does greylisting effectively stop much spam? Is it a useful addition to e.g. SpamAssassin or is adding it on top overkill/unnecessary?

If I were to roll this out to heavier use domains (perhaps with more demanding users) would you anticipate a significant portion of poorly configured mail servers that would end up bouncing or losing messages?

In your experience does greylisting effectively stop much spam?

It is very effective. I've used it for 3+ years and it has had a definite impact on our filtration process.

Is it a useful addition to e.g. SpamAssassin or is adding it on top overkill/unnecessary?

It will actually reduce your scanning workload. I recommend adding it.

If I were to roll this out to heavier use domains (perhaps with more demanding users) would you anticipate a significant portion of poorly configured mail servers that would end up bouncing or losing messages?

I have seen this happen, although the mail servers were severely malconfigured (the postmaster had decided to immediately give up on delivery if there was a soft error, rather than retry sending). This boils down to how the sender handles a 4xx vs. a 5xx message. If they treat them the same, you'll have a few issues. If they treat them correctly, where 4xx is a soft-fail and the sender will retry, there will be no problem. Even if they have it malconfigured, the easy solution is to add the sender's domain to your greylist as "already seen", and giving it an absurd score to keep it from falling off the database.

In my experience, greylisting does not offer enough benefit to justify the drawbacks. While I had greylisting set up on my server, it was annoying enough to have every (new) incoming email delayed. I also know for certain that some incoming email was getting lost.

Spammers were persistent enough (and I think even back then they were starting to automatically do retries) that their spam got through anyway. I turned greylisting off years ago and haven't looked back.

Greylisting will effectively stop lots of spam before it even hits your content filter.

It is a really useful addiction because it will greatly reduce your scanning workload, will reduce false negatives (some of the spam that wouldn't get caught by your content filter will be blocked beforehand by greylisting), and it cannot, by definition, introduce any false positive (legitimate mail being blocked).

Mails you loose are due to not conforming smtp senders - yes there are some "bigs" still not playing nice, a short whitelist will take care of them until they fix their systems. In the end, having lots of sites with greylisting on the internet will have the nice side effect of forcing more people to use correctly configured mail servers.

With a good greylist setup (good implementation + good configuration/operations) very few mails will get delayed, and most of the time the delay will be in the order of a few minutes. Also, a good greylisting setup is mostly a "deploy and forget" system, reducing spam flow, systems load while not increasing your (sysadmin) load.

Before actually turning on greylisting on existing domains I strongly suggest to deploy it in "learning mode", where it'll watch the mail flow without delaying anything. That will give it time to learn triplets and autowhitelist good smtp senders.

Having lots of mails getting blocked before the content scanner will have a number of good side effects. I particularly like these:

1. other than the short and infrequently-changing manual whitelists, a greylisting system does not need any shared knowledge between servers, simplifying the deploy of multiple MX'es in geografically distributed locations/datacenters
2. reducing the scanning load means you can use less hardware for content scanning
3. less servers for content scanning means you can more easily centralize them, manage them, debug them (better signal/noise ratio in the logs ;)
4. less load on your systems to reject 'obvious' spam and more load on a spammer system to retry delivery both mean a better receiver load / spammer load ratio, that makes sending spam more 'expensive', and this is a good thing in the long term

All in all, greylisting boils down to:

1. forcing senders to conform to standards, this will make it easier for the whole email system to work correctly and be more easily manageable (--> more easily tracking down spammers as a side effect)
2. increasing (a little) the cost of email sending, having a little impact on legitimate senders and a bigger one on spammers (--> increasing spam sending costs is always good)

EDIT: while there is an (small, but that's IMHO) impact of legitimate mail delivery times, it could be reduced by using other means to bypass greylisting, like tarpitting and SPF. The former is interesting but I'd do some real world tests before judging its effectiveness / drawbacks, the latter isn't always available.

Yes, greylisting can stop a reasonable amount of spam, very inexpensively. Even when it doesn't stop spam, the added delay gives additional time for the message or sender to be listed on DNSBL or hash-based lists.

You should ensure that you use a good implementation (I'm not personally familiar with SQLGrey). In particular, you can generally figure out ways to trust triplets without having seen the exact triplet before (e.g. if you've seen enough good triplets from an IP, then there's probably no point greylisting any further triplets from that IP). After a small amount of time, very few legitimate messages are greylisted.