10

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?

Dennis Williamson
  • 60,515
  • 14
  • 113
  • 148
Whisk
  • 1,883
  • 1
  • 16
  • 21
  • 1
    For an updated version of this question, see: http://serverfault.com/questions/436327/is-greylisting-still-an-efficient-method-for-preventing-spam?rq=1 – james.garriss Jan 14 '13 at 21:34

7 Answers7

9

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.

Greg Hewgill
  • 6,749
  • 3
  • 29
  • 26
  • 6
    Generally greylisting doesn't delay every new incoming email. It only delays ip-sender-recipient patterns that haven't been seen before. This is far from all incoming email. – Tony Meyer May 01 '09 at 03:03
  • 2
    I understand, that's why I said "new" incoming email. I guess I didn't explain it well enough, but presumably anybody who understands what greylisting does would recognise the problem. Regardless, it was still annoying. – Greg Hewgill May 01 '09 at 03:42
  • 1
    I started using greylisting 5 years ago and like most anti-spam techniques it was fantastic when it first came out. However I agree that the benefits are minimal anymore. I've been seriously thinking of turn it off. – Aaron May 01 '09 at 13:22
  • I found grey listing as implemented in SmarterMail to block more legitimate email (I assume, senders giving up after being denied) than I was comfortable with. It was especially annoying when doing things like attempting to reset a password, etc. I turn it off on all my domains, which are more or less low-traffic, but still attacked by spammers. I don't have specific details of logs and stats, etc – qxotk May 04 '09 at 14:47
  • 5
    The secret to effective greylisting is to (a) set the threshold low enough that first-time senders get through the first 2-3 days and (b) expiring the database of really old entries. Spammers *will* notice greylisters, and *will* retry again at some point. Expiration of their entry after a week or so will cause them to go through the process again, increasing its effectiveness. Before that, we trapped 95%; after I added expiration, we trapped more like 99.99%. Highly recommended. – Avery Payne May 21 '09 at 18:39
5

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.

james.garriss
  • 360
  • 6
  • 17
Avery Payne
  • 14,326
  • 1
  • 48
  • 87
  • I'm accepting this answer now, because we've been using greylisting for some time now, and it seems to be very effective. I'm sure partly down to the suggestions here, we haven't had any real problems with failed mails or excessive delays either. – Whisk Jun 15 '10 at 08:15
3

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.

Luke404
  • 5,708
  • 3
  • 44
  • 58
  • 1
    Good post, but please fix the line "it cannot, by definition, introduce any false positive". This is not true, greylisting can (and will) cause loss of legitimate mail if the sending server is misconfigured. While this would not happen in an ideal world, it needs to be taken into account. – sleske Jun 14 '10 at 10:13
  • Still, +1 for a good post, especially the "learning mode". – sleske Jun 14 '10 at 10:14
  • @sleske, thanks for your comment, but I have to disagree. I don't call "legitimate mail" data coming from a "misconfigured sending server" - that's not what is defined as an email, just something similar to it. OTOH, it's true that you need to take that into account as I explain in my answer. – Luke404 Jun 14 '10 at 10:29
  • 3
    Well, I firmly believe the needs of users should always come first (after all, that's what we get paid for). Thus it's *users* who define whether or not a mail is legitimate, and they don't care about misconfigured servers. If a users wants to receive the mail, it's legitimate, it's that simple. – sleske Jun 14 '10 at 11:17
2

To add to the other answers:

One thing you should consider when deploying greylisting is that it will increase delays for (certain) legitimate mails. You must find out first if this is a problem for your users.

For example, if your organization mostly has internal mails and mails with a few longstanding business partners, the impact will be negligible.

OTOH, if you frequently exchange mail with new customers, it might well be painful. One situation in particular could be a problem: If you talk to someone on the phone and want to exchange documents relevant to the discussion via email (something I regularly do in support-type telephone calls), even a dealy of a few minutes can be unacceptable.

So, as always, take users' specific needs into account.

sleske
  • 9,851
  • 4
  • 33
  • 44
2

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.

Tony Meyer
  • 889
  • 1
  • 13
  • 25
2

One possible problem with greylisting is that users will not get mails immediatly. This is most frustrating for password reset mails. These mails usually get caught in greylist because the sender/receipient/ip will be new.

raj

Rajkumar S
  • 463
  • 1
  • 7
  • 12
1

I've had excellent luck with greylisting. Personally, I'd never use it as my only anti-spam measure, but when included as part of a layered anti-spam system (including SpamAssassing, amavisd, clamav, RBLs, SPF/DKIM, etc), it provides a lot of benefit.

One important note, there are a few ISP's out there (major ones) that don't handle a greylisted destination gracefully (yahoo mailing lists have been a well known example). I'd advise looking at some of the whitelists that people have put together to make sure that you don't end up blocking real e-mail.

In my experience, the vast majority of e-mail that you get person-to-person (from a real person/user) flows through one of the major mail servers (postfix, qmail, exchange, sendmail), all of which handle greylisting properly. Occasionally you might come across some mailing list software or automated e-mail program that doesn't handle it correctly, but my experience suggests this is very rare.

Christopher Cashell
  • 8,999
  • 2
  • 31
  • 43