♦ Password
♦ Mailsetup
♦ Info
♦ Workstations
  ♣ Linux
  ♣ MacOS
♦ E-Mail
♦ Chat
♦ Files
♦ Backups
♦ Printers
♦ Network
♦ Statistics
♦ Downloads
♦ Links
♦ Newsletter
♦ Submit
♦ Search
♦ Linux

  Greylisting Effective Against Spams
Experiences Posted by Elmar Heeb on Monday October 22, @10:51AM
from the clean-mailbox dept.
As has been announced in August we are using greylisting to fend off spam. As it turns out greylisting is very effective.

How does it work? If a receiving mail server is too busy it can refuse to accept new mail with a temporary error. The sending mail server will try to send the mail again later. Greylisting uses this standard feature to refuse any first attempt to send mail. Many spammers will never get around to send the mail a second time as they are busy trying to reach millions of other addresses.

Why didn't we use it before? About two years ago when greylisting was in fashion we suspected that spammers will soon adjust to greylisting making it effectively useless. Indeed many spammers did adjust but there are still mass spammers who are working on mailing lists so large that they never get around (or just don't bother) to send their mail a second time. While the reduction in spam mail used to be about 10 to 20 times two years ago it is still a factor of 3 to 10 now. Additionally, many infected home computers that are used as spam gateways are not online long enough to be able to send their spam a second time.

Why do we use it now? Even a reduction by a factor of 3 in incoming spam mail would be a worthwhile goal and in our first two month of using greylisting it even looks like we get a reduction by a factor of 10. Of course, our spam filter finds quite a few spams already while missing some, so it is not clear what kind of reduction in spam mail each user will see. More important however is the fact that all mail which is blocked by greylisting does not need any resources in filtering or storage. The mail server is therefore more responsive for regular use.

Are there drawbacks? By design, greylisting will delay some mail delivery. Unfortunately, it is the sending host that decides how long this delay will be. On the other hand, mail servers get whitelisted when they are successful in dealing with greylisting (thus proving they are following mail standards), so most mail will be delivered fast. Occasionally, some mail systems — mailing lists in particluar — try to track each delivery individually which makes each connection appear to be the first. Greylisting knows about most of these schemes and handles them properly. Should there still be a case left that has problems with greylisting, we can always whitelist that particular sending mail server. In our first two months we had to deal with two such cases.

spam statistic

Our mail statistics shows the reduction in recognized spam by a factor of 10 from between 40 and 60 messages per minute before greylisting to between 4 and 6 msg/min after (note the logarithmic scales). At the same time the number of good mails (so called "ham") remained the same indicating that the filtering is working well. The noticable increase of rejected messages are due to the initial connection attempts denied by greylisting.

<  |  >


  Related Links
  • Articles on Experiences
  • Also by Elmar Heeb
  • Contact author
  •   File Attachment

    The Fine Print: The following comments are owned by whoever posted them.
    ( Reply )

    Re: Greylisting Effective Against Spams
    by Guido Elia on Friday November 16, @05:25PM
    How can we check if the our Exchange server retries correctly ?
    [ Reply to this ]
    • Re: Greylisting Effective Against Spams
      by Elmar Heeb on Saturday February 23, @11:55AM
      This is done as usual: look in the log files. Temporary delivery failures are a standard occurrence with SMTP mail delivery and greylisting uses just that standard. You should see lots of greylisting entries in the log files these days.

      As an aside: ETH internal networks are of course in our list of accepted IP addresses and should never see a greylisting log entry from us for inside mail delivery. The same goes for authenticated connections (user/password with a D-PHYS account over SMTP/TLS) from anywhere else.

      [ Reply to this ]

    The Fine Print: The following comments are owned by whoever posted them.
    ( Reply )

    © 2003 ISG, Departement Physik, ETH Zürich, <>