Relax greylisting IP rules to reduce false positives.
When legitimate emails come from large organisations the retry attempts can come from different IP addresses and thus never make it through the greylist. The greylist is great and very effective but many organisations cannot tolerate any legitimate mails bouncing as rejected. Alllow the facility to relax the IP matching to a subnet, or turn it off altogether doing the filtering just based on sender and recipient, this should be nearly as effective.
Frank Chiappetta commented
I was going to create a new request, but I'll just add to this as it is similar enough. I think we all agree that Greylisting is a very important and effective filter. However, due to GFI MEs strict adherence to the triplet test, many emails are either exceedingly delayed, or unnecessarily lost as they are sent from large email systems that have more than one single mail server IP address. (This would include most medium/large, even small businesses in some cases.) I found one single legitimate message bounced by the Greylist roughly every 10-15 minutes for over 3 days. We simply cannot have this. The main idea of the Greylist is to temporarily delay messages sent on the first attempt from spammers who will never send the same message twice, thus effectively blocking a majority of the inbound junk email, allowing the message to pass the filter after a proper retry. It should not be blocking these same messages for hours/days on end. I understand why the triplet should be a good test, but in the real world, experience suggests otherwise.
I'd like to suggest that a switch be introduced to allow GFI MailEssentials customers the ability to run the Greylist filter in a 'Relaxed mode.' That way the filter will only keep track of sender, recipient(s) (& maybe even include the message subject), disregarding the IP address that introduces the potential for massive delays and loss of email. That way email messages will have a better chance of being delivered on the second attempt passing the Greylist filter and then be subject to the further testing by the remaining designated filters. This will allow customers the ability to still utilize the very useful Greylist filter while avoiding the potential problems introduced by using it in strict mode (strict triplet test - Sender/Recipient/Sending IP)
FWIW - I've used another Spam filtering system that utilized the Greylist, and I never had this much trouble using it. Emails sent in a second time passed the filter, period. Happy medium.
Also, we unfortunately had to disable using the Greylist filter. It's simply too strict to use in a production business environment where emails are required to be delivered in a timely manner.
Please everyone, it looks nice that you comment on these appearing to agree with the request, but you need to vote these up! GFI doesn't seem to care about any customer requests that don't have high enough votes!
Warren Huisman commented
[Comment date: 2011-02-17]
Legitimate mail might not get delivered if the retry does not arrive within the time window the greylisting software uses, or if the retry comes from a different IP address from the original attempt. When the source of an email is a server farm or goes out through an anti-spam mail relay service, it is likely that on the retry a server other than the original server will make the next attempt. Since the IP addresses will be different, the recipient's server will fail to recognize that the two attempts are related and refuse the latest connection as well. This can continue until the message ages out of the queue if the number of servers is large enough. Such server farming techniques can be construed as breaking RFCs detailed above since the original sending machine has absolved itself of the responsibility of mail delivery by tossing it back into the pool, which breaks the state of the mail delivery process. This problem can partially be bypassed by identifying and whitelisting such server farms in advance. However, it is not possible on a distributed network the size of the Internet to maintain a complete list of all such server farms
[Comment date: 2013-02-22]
We are experiencing this problem more and more frequently from sources such as Google Mail, Facebook, Twitter, Aol, etc. Clearly this is becoming more of an issue so there needs to be a way to handle it. Perhaps an option to allow a message through after two or three failed triplets where the sender and recipient address remain constant?