Greylisting glitch
Problem reported by Sean Middlemore - 5/19/2016 at 7:41 AM
We have an email address setup and when I email to it, it greylists as per usual but doesn't let the email go through after it tries again. I'm a bit stumped. Here is the log and the settings used:
[2016.05.19] 14:45:18 [][20805362] rsp: 220 XLVets Mail Server
[2016.05.19] 14:45:18 [][20805362] connected at 5/19/2016 2:45:18 PM
[2016.05.19] 14:45:18 [][20805362] cmd: EHLO mail-io0-f199.google.com
[2016.05.19] 14:45:18 [][20805362] rsp: 250-mail.xlvets.co.uk Hello []250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250 OK
[2016.05.19] 14:45:18 [][20805362] cmd: STARTTLS
[2016.05.19] 14:45:18 [][20805362] rsp: 220 Start TLS negotiation
[2016.05.19] 14:45:19 [][20805362] cmd: EHLO mail-io0-f199.google.com
[2016.05.19] 14:45:19 [][20805362] rsp: 250-mail.xlvets.co.uk Hello []250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
[2016.05.19] 14:45:19 [][20805362] cmd: MAIL FROM:<sean.middlemore@xlvets.co.uk> SIZE=7060
[2016.05.19] 14:45:22 [][20805362] rsp: 250 OK <sean.middlemore@xlvets.co.uk> Sender ok
[2016.05.19] 14:45:22 [][20805362] cmd: RCPT TO:<rebates@xlvets.co.uk>
[2016.05.19] 14:45:22 [][20805362] rsp: 451 Greylisted, please try again in 60 seconds
[2016.05.19] 14:45:22 [][20805362] cmd: QUIT
[2016.05.19] 14:45:22 [][20805362] rsp: 221 Service closing transmission channel
[2016.05.19] 14:45:22 [][20805362] disconnected at 5/19/2016 2:45:22 PM
[2016.05.19] 14:53:05 [][50383278] rsp: 220 XLVets Mail Server
[2016.05.19] 14:53:05 [][50383278] connected at 5/19/2016 2:53:05 PM
[2016.05.19] 14:53:05 [][50383278] cmd: EHLO mail-oi0-f69.google.com
[2016.05.19] 14:53:05 [][50383278] rsp: 250-mail.xlvets.co.uk Hello []250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250 OK
[2016.05.19] 14:53:05 [][50383278] cmd: STARTTLS
[2016.05.19] 14:53:05 [][50383278] rsp: 220 Start TLS negotiation
[2016.05.19] 14:53:06 [][50383278] cmd: EHLO mail-oi0-f69.google.com
[2016.05.19] 14:53:06 [][50383278] rsp: 250-mail.xlvets.co.uk Hello []250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
[2016.05.19] 14:53:06 [][50383278] cmd: MAIL FROM:<sean.middlemore@xlvets.co.uk> SIZE=7060
[2016.05.19] 14:53:10 [][50383278] rsp: 250 OK <sean.middlemore@xlvets.co.uk> Sender ok
[2016.05.19] 14:53:10 [][50383278] cmd: RCPT TO:<rebates@xlvets.co.uk>
[2016.05.19] 14:53:10 [][50383278] rsp: 451 Greylisted, please try again in 60 seconds
[2016.05.19] 14:53:10 [][50383278] cmd: QUIT
[2016.05.19] 14:53:10 [][50383278] rsp: 221 Service closing transmission channel
[2016.05.19] 14:53:10 [][50383278] disconnected at 5/19/2016 2:53:10 PM
[2016.05.19] 15:13:52 [][17422152] rsp: 220 XLVets Mail Server
[2016.05.19] 15:13:52 [][17422152] connected at 5/19/2016 3:13:52 PM
[2016.05.19] 15:13:52 [][17422152] cmd: EHLO mail-ig0-f198.google.com
[2016.05.19] 15:13:52 [][17422152] rsp: 250-mail.xlvets.co.uk Hello []250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250 OK
[2016.05.19] 15:13:52 [][17422152] cmd: STARTTLS
[2016.05.19] 15:13:52 [][17422152] rsp: 220 Start TLS negotiation
[2016.05.19] 15:13:53 [][17422152] cmd: EHLO mail-ig0-f198.google.com
[2016.05.19] 15:13:53 [][17422152] rsp: 250-mail.xlvets.co.uk Hello []250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
[2016.05.19] 15:13:53 [][17422152] cmd: MAIL FROM:<sean.middlemore@xlvets.co.uk> SIZE=7063
[2016.05.19] 15:14:02 [][17422152] rsp: 250 OK <sean.middlemore@xlvets.co.uk> Sender ok
[2016.05.19] 15:14:02 [][17422152] cmd: RCPT TO:<rebates@xlvets.co.uk>
[2016.05.19] 15:14:02 [][17422152] rsp: 451 Greylisted, please try again in 60 seconds
[2016.05.19] 15:14:02 [][17422152] cmd: QUIT
[2016.05.19] 15:14:02 [][17422152] rsp: 221 Service closing transmission channel
[2016.05.19] 15:14:02 [][17422152] disconnected at 5/19/2016 3:14:02 PM

8 Replies

Reply to Thread
Scarab Replied
This isn't a glitch. It's W.A.I. (Working As Intended). Greylisting is not just based upon the Sender Address but also on the Server IP that is attempting delivery. If a Mail Service is using Round-Robin or Elastic IPs to deliver an email then it won't pass Greylisting UNTIL delivery is reattempted from the same IP Address.
Fortunately there aren't many services that use Round-Robin or Elastic IPs for email delivery. Google Mail and AmazonSES are two of the biggest exceptions. In these cases you would want to add their IP Ranges to your SECURITY > GREYLISTING > FILTERS. Over time you'll discover other rare occurrences where you may have to setup a service's IP Range in the Greylisting Filters but thankfully it doesn't happen very often.

On another note Google, despite using Round-Robin will eventually pass Greylisting successfully without being added to the Greylisting Filters. It just takes a larger number of retries before delivery from the original IP Address is retried.
Sean Middlemore Replied

Many thanks for the explanation. I realise now how it completely makes sense to greylist both email addresses and IP addresses.

Tim DeMeza Replied
I am having the exact same problem with senders from office 365 accounts.  There has to be a better way than finding IP ranges.  I have really MAD not frustrated users.  Can we do anything about this? 
By the way, I found this as well.  I hate to admit that I don't even know how to add some of these ranges.
Nathan Y Replied
A couple of useful additions to the greylisting implementation would be the following (although they should be optional):
1) Once an IP address/sender has passed through greylisting any further emails from the same IP address should be accepted regardless of the sender as we have established it will retry so there is no point in delaying.
2) Have the option during the deferal to switch from a /32 match to a /24 so where a provider round robins in the same /24 it passes. This won't address where they are in different networks but would be a help.
John Reid Replied
I am in the middle of adding the Exchange Online Protection IPs myself right now. It appears that there are close to 400,000 IP addresses in about 27 different CDIR ranges. After that I need to track down the Google IPs. Then possibly Yahoo and AOL, etc.
This brings up two points:
1) this should have been a prepopulation option from SmarterTools. I should at least have the ability to say, for example, allow Exchange Online Protection somewhere and not have to track all this down and enter it manually as this completely breaks Greylisting. How long do you think it will take for the mail server to pass a message when it could come from 400,000 different IPs? Longer than 4 days I would suspect.
2) Once you have added exceptions for all the big providers, where has the value of Greylisting gone? Practically into the toilet. You have now excluded the vast majority of locations you will receive mail from.
This needs to be rewritten as this seems to be a very poor implementation, and it is not described by SmarterTools as working in this way. It is described as being done via the From: address, so that is how it should work. Don't say one thing and do another.
Just my two cents.
John Reid Replied
FYI - As of today (9/23/2016) here are all of Microsoft's Exchange Online Protection IP addresses converted from the published CDIR to IP Ranges for easy entry into SmarterMail. I used this tool to do it quickly, in bulk. The tool can export to CSV, if there was a way to import it (HINT - HINT) [  w w w . ipconvertertools . com / cidr2ipranges ] I can't post hyperlinks, so remove the spaces.
ID CIDR Network address First IP Last IP Subnet mask Broadcast Total IP's
1 1022
2 2046
3 4094
4 510
5 2046
6 262142
7 65534
8 254
9 254
10 62
11 32766
12 254
13 254
14 254
15 126
16 62
17 510
18 254
19 126
20 126
21 62
22 254
23 126
24 254
25 254
26 62
27 510
              TOTAL: 374218
Matthew Leyda Replied
We use the Whitelist from SPF records. This is a free tool from Mighty Blue software.
SmarterMail Whitelist from SPF (free) - We have written a free tool for the community that will whitelist the major providers from being Greylisted, and update SmarterMail.

Download the tool from:

Kendra Support
Junk Email filtered ISP
John Reid Replied
Thank you Matthew. This helps with the labor, and certainly is a great tool filling a current need. However, it should not be needed.

The requirement to whitelist major providers at all is a fundamental flaw. Without the IP check, at least the greylisting function is there doing its job on the from address. Now that you are whitelisting the vast majority of IP addresses E-mail will realistically be coming from, greylisting is not even being performed on the majority of your inbound mail anymore. You have exempted it by creating an exception.

Adding the IP check element breaks greylisting. I can't put a finer point on it. This is a classic case of adding checks decreasing security rather than enchanting it.

Reply to Thread