Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 4716 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
    Welcome back to the User BB, Colin.  I disable greylisting at my customer sites.  I figure that a connection that passes RNDS/HELO and RBL checks also will get past greylisting.  If it also doesn't fail SPF, then I agree with you that greylisting, if selected, should be skipped, but I think it's the first thing done.

    Again, I think in today's world with the UTM, greylisting is a blunt instrument that's a waste of time.  Others here like to use it, so this is just one man's opinion.

    Greylist entries are triplets of sendingIP-sender-recipient, so your #3 doesn't have enough info to be inserted into a greylist database. 

    Cheers - Bob
    PS You could create an Exception for greylisting for known senders including gmail.com, hotmail.com, etc., but rather than maintaining such an Exception, I'd prefer to make the exception global. [;)]
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0
    Welcome back to the User BB, Colin.  I disable greylisting at my customer sites.  I figure that a connection that passes RNDS/HELO and RBL checks also will get past greylisting.  If it also doesn't fail SPF, then I agree with you that greylisting, if selected, should be skipped, but I think it's the first thing done.

    Again, I think in today's world with the UTM, greylisting is a blunt instrument that's a waste of time.  Others here like to use it, so this is just one man's opinion.

    Greylist entries are triplets of sendingIP-sender-recipient, so your #3 doesn't have enough info to be inserted into a greylist database. 

    Cheers - Bob
    PS You could create an Exception for greylisting for known senders including gmail.com, hotmail.com, etc., but rather than maintaining such an Exception, I'd prefer to make the exception global. [;)]
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
No Data
Unfiltered HTML