Re: URIBL_BLACK

[Justin Mason <jm...@jmason.org>]

Kris Deugau writes:
> Karsten Br�ckelmann wrote:
> > Unlike regular score lines for non-existent rules (which are kind of
> > ignored), the relative score adjustment depends on the rule to be
> > defined before.
> > 
> > Given your demo rule above,
> 
> Nominally live, actually.  I've had perfectly legitimate staff email 
> hitting FORGED_MUA_OUTLOOK.  :(  (I've created a meta rule instead to 
> drop the score, and since then I've also added whitelist_from_rcvd rules 
> for all of our office firewalls as well...  but if it hits us, it could 
> hit customer mail as well.)
> 
> > you are distributing a custom channel. It
> > will work, if you rename the channel name to come after the stock
> > updates channel when sorting lexically.
> 
> *shrug*  It does;  it's called zzsarules.vianet.ca.  When I first 
> created it, I *did* run into problems simply redefining scores at fixed 
> values for rules in other rulesets which were, indeed, sorted *after* my 
> local channel originally (don't recall the details ATM;  pretty sure I 
> posted here asking about it).  Thus the "zz" prefix - but it still 
> doesn't accept a score *adjustment*.
> 
> I've isolated an example into a testable "ruleset";  try:
> 
> # sa-update --channel zzsarules.deepnet.cx --nogpg
> 
> (Single scoreadj.cf file, with the single rule
> "score FORGED_MUA_OUTLOOK	(-1)")
> 
> Note I'm running 3.2.5 on all the machines using the live ruleset, but 
> IIRC I first hit this problem with 3.2.4.

In this situation, I think the cleanest way to do it is to define a meta:

  meta FORGED_MUA_OUTLOOK_ADJUST       (FORGED_MUA_OUTLOOK)
  score FORGED_MUA_OUTLOOK_ADJUST      -1

those are not dependent on the order in which they're defined in any
way.

--j.