Greylist performance

Hi,

Looking for any feedback or thoughts on these suggestions. Quick search didn't find anything similar, but apologies if there already is a thread...

We use the Astaro/UTM platform extensively with our clients and have had generally good successes. However, some nuances with respect to email performance have been a constant challenge.

The greylist function generally works great, however...
1. Can we expand the CIDR subnet mask the greylist database uses, to something other than /32?
Logs show:
Successful greylist retry from xx.xx.xx.xx (original host was xx.xx.xx.xx/32)
We've seen variable delivery times from major sources such as gmail, Hotmail, Office 365, and such, where the provider has a large block of MTA's and the greylist will record each possible mta's IP individually. Expanding the greylist database entry to say /28 or /24 addresses would mitigate some of these delays. Perhaps some risk in trusting more addresses than currently, but most known sources of junkmail are already listed on RBL's

2. SPF before greylist.
if an IP passes a SPF check, why not automatically add it to the greylist database and avoid forcing the retry delay?

3. Include major ISP known MTA's in the greylist database as a part of the up2date process?

thanks for looking.
Colin

Hi,

Looking for any feedback or thoughts on these suggestions. Quick search didn't find anything similar, but apologies if there already is a thread...

We use the Astaro/UTM platform extensively with our clients and have had generally good successes. However, some nuances with respect to email performance have been a constant challenge.

The greylist function generally works great, however...
1. Can we expand the CIDR subnet mask the greylist database uses, to something other than /32?
Logs show:
Successful greylist retry from xx.xx.xx.xx (original host was xx.xx.xx.xx/32)
We've seen variable delivery times from major sources such as gmail, Hotmail, Office 365, and such, where the provider has a large block of MTA's and the greylist will record each possible mta's IP individually. Expanding the greylist database entry to say /28 or /24 addresses would mitigate some of these delays. Perhaps some risk in trusting more addresses than currently, but most known sources of junkmail are already listed on RBL's

2. SPF before greylist.
if an IP passes a SPF check, why not automatically add it to the greylist database and avoid forcing the retry delay?

3. Include major ISP known MTA's in the greylist database as a part of the up2date process?

thanks for looking.
Colin