On 5/2/2014 6:07 AM, Wietse Venema wrote: > Stan Hoeppner: >>> swl.spamhaus.org*-4 >>> list.dnswl.org=127.[0..255].[0..255].0*-2 >>> list.dnswl.org=127.[0..255].[0..255].1*-3 >>> list.dnswl.org=127.[0..255].[0..255].[2..255]*-4 >> >> Consolidate these last 3 to something like: >> list.dnswl.org=127.0.[2..14].[2..3]*-4 > > These three will result in one list.dnswl.org query, just like the > consolidated one. There is no performance difference.
Correct. The reason for consolidating these is not to reduce queries. > However, there is a correctness difference. The consolidated form > has the same weight 4 for all results, while the original form > has different weights. The consolidated form gives no score to a 4th octet value of [0..1], but gives -4 to [2..3]. This is the key difference. Alex' form and weights are not correct. And that is why I posted the link to the return codes. The second 'octet' is always zero, not a range. The 3rd octet has a range of 2-15, and the 4th octet a range of 0-3. Specifying a range of 0-255 or 2-255 to cover "the future" may have the opposite effect, resulting in potential disaster, depending on how/if/when dnswl changes things. Such wildcards should not be used. A value of 15 in the 3rd octet means the sender is an Email Marketing Provider. Most people would never whitelist such senders. Alex currently does. Most people would give no preference to a 4th octet score of 0 which means "no trust". Alex is giving -2. And he is giving -3 to a 4th octet score of 1, "low trust". The recommended scale is -0.1, -1.0, -10, -100, and this is how SpamAssassin handles dnswl scoring. Using a 4 point scale instead of 100, a 4th octet value of 0 or 1 should be given NO whitelisting preference at all, which is what my consolidated example does. Cheers, Stan
