Mailservices uses greylisting in an attempt to combat spam. By default this affects all e-mail arriving from off campus. Since its installation on mailservices many years ago, we have slowly added exceptions [1] to the list, both for individuals, and for organisations (i.e. DNS domains and IP address ranges). This is a manual process, but we always said that if it becomes burdensome we would automate it. It has reached that burdensome point now, but we have added so many exceptions for so many sites and so many people (greylisting gets the blame for all kinds of problems, and sometimes it's easiest just to agree and add another exception), that it is probably no longer worthwhile running this service.
Thus, we propose it is turned off. A net result may be more spam on our systems, but we are confident that spam will get caught by other means, and dumped into junk folders rather than being an inconvenience to users. Since the quantity of e-mail arriving on campus is steadily decreasing, from around 2 million external connections a day to mailservices a few years ago, to around 1 million today, the extra mail now will not be a problem.
It is difficult to get a grasp on how effective greylisting is, as the errors it returns are by design similar to other errors. However, currently only about one third of incoming connections results in a piece of mail being delivered. Some of that is greylisting, some is bad recipient addresses, probes, full mailboxes, and so on. We can't really differentiate.
It is a simple configuration change to turn off greylisting. Ideally we'd set a date and do this. If there are problems, we can turn it back on again.
[1] Exceptions are currently 107 domains (a text comparison to a name string), 342 users, 87 IP ranges. One of those domains is microsoft.com, commonly spoofed in spam.