Email greylisting problems and how to monitor them

See also: Email greylisting: what, why, and how

Email greylisting: problems and inefficiencies

Greylisting is very effective at reducing spam, but it also causes major problems for legitimate email senders and recipients alike, including:

Mysterious email delays

Delays of 15-30 minutes are typically introduced for all mail that matches the greylisting policy (RFC5321 recommends “at least 30 minutes”). Practically this means that the first message from an unknown mailserver (e.g. one that has not been in communication before) will be stuck for some time, with no notice to either sender or recipient of what’s going on. Even 15 minutes wait can cause frustrating disruption to legitimate messaging (sending a video link five minutes before a meeting, for example).

Less efficient, more expensive email

Greylisting disincentivises spammers by requiring ‘proof-of-work’ (see above) from all mailservers. Just as with Bitcoin, this results in a huge arbitrary increase in the cost of standard day-to-day operations; in this case delivering email. By default most mailservers will retry delivery over and over again, prioritising success over efficiency. This can result in millions of unnecessary redelivery attempts each day, per mailserver, due to the greylisting policy of the recipient server – even though all senders and recipients are legitimate. Considering the millions of mailservers in operation worldwide, the inefficiency greylisting introduces has a major impact on the monetary and environmental cost of email messaging.

Problems for larger networks

Greylisting policies usually rely on the sending mailserver IP address as the primary identifier and data point for determination of whether and how long to delay. However it’s increasingly common practice for senders to use multiple IP addresses for their mail network, which can result in the same “known” sender being greylisted many times – at least once for each IP they send from. In some cases greylisting policies drop IPs from their “known” / allow-list after a fixed time interval, which, when applied to networks with multiple sending IPs, can result in a legitimate sender being continuously greylisted, as their IPs pop in and out of trusted status.

Problems with incompatible configuration

The problem here is twofold. On one hand, the sending mailserver might misinterpret the greylist delay, and give up after receiving an initial soft bounce. On the other, if the receiving server has more than 1 MX record set (which is almost a certainty), the sender might retry delivery to another server within the recipient’s network – and if the greylisting policies of the receiving MTAs aren’t identically configured, the greylisting will continue (as each of the unfamiliar IPs identified by the MX are tried in turn).

Monitor greylisting problems with Lightmeter

Lightmeter monitors these delays in the form of deferred email, and provides an easy way for admins and mailbox users to check the status of any email via the Message Detective.