Why set greylist to more then 1 minute?
In my opinion more will cause unnecessary delay for real mail.
1 minute should be enough to stop spammers who use non-retrying software.
If they retry, greylisting will not help anyway.

We do not use SPF 30. We have clients who forward mail to our server. Not all senders use SRS and SPF 30 will send such forwarded mail to junk. We set SPF to 29, then we need one more test to fail before sending mail to junk.

I use 1 minute as well for grey listing. In this era such as you're on the phone with someone and they send you some needed verification, 4 minutes is an eternity when gmail is nearly instant. 

The IP addresses such as in spamrats doesn't align with what SM is using and our recent discussion in my anti-spam thread with SM17. The IP addresses do not look correct.

While I appreciate a document like this it doesn't seem like something I can trust and will rely on ST to get their settings perfected with each release and advise us maybe in a specific thread of web site area of the latest settings, corrections, etc. 

We do see a lot less spam using greylisting. (Strange so many spammers dont catch the greylisting reply and retry later). Its possible it would be caught by later spam check but it save us from the trouble.
But yes depending on what retry delay the sender servers use it can slow delivery down.
We use 2 minutes retry for the same reason.

Ronald, you see 0ms response time because once ST has done a lookup on the IP using another RBL lookup, it uses that response to test against other RBL entries. So if you have ZEN, ZEN2, ZEN3 and they all lookup against the same hostname, SmarterMail simply uses the response from ZEN to test on the ZEN2 and ZEN3 lists, no need to query the server 3 times to get the same response.

Guys, I noticed that I made an error on the document. There is no ZEN RBL which goes to 127.0.0.8. I removed it from the doc. 

Also... as you guys probably know, were previously allows to use a * to cover all zones that the Zen RBL offers. Now that we are no longer allowed to use a *, I broke the Zen RBLs down into individual return codes using the same hostname to query. If you do not want to use them this way, you can use them individually as follows...

SBL - sbl.spamhaus.org - 127.0.0.2-3,9 - Static UBE sources, verified spam services (hosting or support) and ROKSO spammers 

XBL - xbl.spamhaus.org - 127.0.0.4-7 - Illegal 3rd party exploits, including proxies, worms and trojan exploits 

PBL - pbl.spamhaus.org - 127.0.0.10-11 - IP ranges which should not be delivering unauthenticated SMTP email.

Thanks for the updated list. Any chance of hi lighting the new changes/additions esp if there are just a few items? I know I'm being lazy....

HI Ben. Please check out the following link which will show you the doc before I updated it. This will help you to compare... https://web.archive.org/web/20180622003043/http://know.mailsbestfriend.com/papers/SmarterMail-Antispam-Settings.shtml

Thanks, Linda. What do we do with Bayesian filter? Why does it still appear in the instructions?

Hey guys. Disregard the Bayes stuff in the doc. I will update it tomorrow as I am feeling very much under the weather today. Thanks for your patience.