Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 4717 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Greylist performance

cmacdonald
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


This thread was automatically locked due to age.
Parents
  • 0


    More and more sites consider the immediate resend that greylisting generates to be abusive and so you may not get a timely resend...I leave it disabled


    This is not true. Apart of the email protocol, email servers are required to resend and attempt to retry.  Greylisting does not give them a unique grey listing error, it just gives the originating email server a temporary unavailable error.

    Greylisting is pertectly fine and we run one of the biggest car dealerships for Toyota in Australia and deal with 100s of email servers weekly and not once has an email not been recived because of greylisting. Sure it can take 5 to 30 minutes to receive it(usually only 5 minutes) but once iy resends it. The email server is excluded from greylisting for 72hours or if we send an email to them.

    Greylisting works well and should be used.
Reply
  • 0


    More and more sites consider the immediate resend that greylisting generates to be abusive and so you may not get a timely resend...I leave it disabled


    This is not true. Apart of the email protocol, email servers are required to resend and attempt to retry.  Greylisting does not give them a unique grey listing error, it just gives the originating email server a temporary unavailable error.

    Greylisting is pertectly fine and we run one of the biggest car dealerships for Toyota in Australia and deal with 100s of email servers weekly and not once has an email not been recived because of greylisting. Sure it can take 5 to 30 minutes to receive it(usually only 5 minutes) but once iy resends it. The email server is excluded from greylisting for 72hours or if we send an email to them.

    Greylisting works well and should be used.
Children
No Data
Unfiltered HTML