3
Simplified Greylisting
Idea shared by Douglas Foster - 12/19/2023 at 12:46 PM
Proposed
As implemented in SmarterMail, greylist filtering exceptions require knowledge of the entire IP structure of the remote organization, even though those details are difficult to determine and are likely to change frequently.   This is so unsustainable that I have never enable greylisting, even though it is widely recognized as effective.   
There is a simpler approach:   do greylist filtering exceptions based on domains with forward-confirmed host names.   Servers for most major organizations pass fcDNS on the HELO name.  Outlook.com is an exception which passes fcDNS only on the ReverseDNS name.  So both names should be tested, with success when either one matches and passes.  This approach will provide clarity to which servers are being excepted while also allowing the list to be easily supplemented with my favorite business partners.

4 Replies

Reply to Thread
0
Zach Sylvester Replied
Employee Post
Hey Douglas, 

Thanks for reaching out to the community. Have you looked at the Greylist Weight Threshold setting?
With this, it will only greylist senders who are over a certain weight. 

This is located in Settings->Antispam

To use this you can just turn on your spamchecks for inbound SMTP checking in the Spam Checks section. 

Please let me know if this helps at all. 

Thank you, 

Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com
0
Different issue.  I am looking to eliminate a list of 1500+ grey list IP rage exemptions that we currently need to exempt mega server farms like Outlook com and google.com.  All we need is a domain name for the server farm, verified by fcDNS.  This will eliminate the need for reverse-emgineeting of the IP lists for those domains.   A configuration with a list of 100 exempted domains is a lot easier to understand than a list of thousands of CIDR ranges.

You could even el
1
Matt Petty Replied
Employee Post
On boot and every night we now also update the IP's automatically for a hardcoded set of addresses using SPF to populate the IP lists, outlook.com and google.com should be automatically updating. This list is hardcoded though so I can see some value in surfacing it in the web interface somewhere to be changed. This was something we added not in this Beta but in our last major release we had earlier in the year.
Matt Petty Software Developer SmarterTools Inc. www.smartertools.com
2
After excluding known-bad senders, my recent history includes a lot of organizations that send to me using multiple IP addresses.   I evaluated based on server domain (removing only the first label from the host name) and server organization (using a PSL lookup on the host name).   Either way, I get a little less than 1000 server groups covering about one third of all incoming messages.   

Then there is the local override problem.   For example, "GovDelivery.com" is an important sender for me, with 360 unique IP addresses used.   Is it in your list?   Even dominos.com (the pizza people) use 23 different addresses, and walgreens.com is close behind with 19 addresses.   Should they be exempted?   Are they exempted?   I have no practical way of knowing if your exemption list includes the sending organizations that are important to me.   Even then, If an organization is missing, how much effort will it take for me to reverse engineer the IP address list for that server farm?

Maybe the real point here is that greylisting based on source IP is inherently flawed.   It would make more sense to greylist based on the server organization, so that a retry from a different server would not cause a secondary deferral.  If that approach is implemented, the need for exemptions would mostly be eliminated.  I would only need exemptions for server farms that are so important to me that even a one-time deferral is unacceptable to my organization.

Greylisting based on server name requires server name verification to be trustworthy, so it raises the question of  whether fcDNS verification works.   The answer is YES.  My data shows successful server name verification for 84% of all messages.  The percentage jumps to 91% verification if I exclude known-bad senders, because two thirds of all unverifiable servers are associated with known-bad senders.

Reply to Thread