Rob McEwen wrote: > Adam Katz wrote: >> Does anybody here know anything about the legitimacy of Constant >> Contact <http://www.constantcontact.com/anti_spam.jsp> ? > > Sometimes abused, but too legit to outright block based on sending IP, imo.
So in Marc's HostKarma context, that probably means pushing them from white to NOBL or yellow. >> The biggest problem is that they're well seeded in the DNS whitelists, > > Many of those whitelists are better used as "don't check the sending IP > against RBLs, but do all other content spam filtering"... and should not > be used as a "skip filtering and send to inbox". > > Complaints liks this keep coming up for various whitelists. The usage > alternative I just suggested may solve this problem for many people. Without category-based checking or variables in SA, this is very hard. I'd love to be able to write a rule that says "if it hits rbl A, undo all points assigned by all other rbls." The only way to do this (and I'm close to the motivation needed to implement this) would be to rewrite *all* RBL rules as metas. I made a (buried) proposal for this on 2009-10-11 at 5:19a UTC (see my second pet peeve at the bottom). Example: header RCVD_IN_A eval:check_rbl('A-lastexternal','a.example.com') score RCVD_IN_A 0.001 # adds to RCVD_IN_BL_HIGH below header RCVD_IN_B eval:check_rbl('B-lastexternal','b.example.net') score RCVD_IN_B 0.5 # adds to RCVD_IN_BL_MED below header RCVD_IN_C eval:check_rbl('C-lastexternal','c.example.info') score RCVD_IN_C 0.001 # adds to RCVD_IN_BL_MED below header RCVD_IN_W eval:check_rbl('W-lastexternal','w.example.org') score RCVD_IN_W -0.001 # adds to RCVD_IN_WL_HIGH below header __RCVD_IN_Y eval:check_rbl('Y-lastexternal','y.example.org') meta __RCVD_IN_YELLOW __RCVD_IN_Y meta RCVD_IN_BL_HIGH RCVD_IN_A && !__RCVD_IN_YELLOW describe RCVD_IN_BL_HIGH Received in highly trusted DNS BL score RCVD_IN_BL_HIGH 2 meta RCVD_IN_BL_MED (__RCVD_IN_B || __RCVD_IN_C) && !__RCVD_IN_YELLOW describe RCVD_IN_BL_MED Received in moderately trusted DNS BL score RCVD_IN_BL_MED 1 meta RCVD_IN_WL_HIGH RCVD_IN_W && !__RCVD_IN_YELLOW describe RCVD_IN_WL_HIGH Received in highly trusted DNS WL score RCVD_IN_WL_HIGH -4 Here you can see that A is a highly trusted DNSBL, B & C are moderately trusted DNSBLs, W is a highly trusted DNSWL, and Y is a listing of things that should avoid other DNS RBL lookups. These are grouped (even when not necessary) to highlight the expandability of the system. Individual rules should be scored at 0.001 or -0.001 unless they need more weight than the others in its group, which is why RCVD_IN_B has a slightly higher score. These weights should be small and used sparingly, as they side-step things like Y. (Yes, the example is missing tflags and some descriptions. It's an example.)