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.)
