Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 4715 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.
  • 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
  • 0
    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


    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

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 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.
  • 0
    Thanks for the comments.
    In general, yes I agree that greylisting is a useful and desirable approach, but there are some nuances with implementation.

    On a side note, when working with the new wave15 for Office 365 and EOP, I noticed that Microsoft has an option to use their white-list for common known-good trusted senders. Just a thought...
Unfiltered HTML