amavis-user October 2010 archive
Main Archive Page > Month Archives  > amavis-user archives
amavis-user: Re: [AMaViS-user] Feat req. policy inheritance

Re: [AMaViS-user] Feat req. policy inheritance

From: Mark Martinec <Mark.Martinec+amavis_at_nospam>
Date: Fri Oct 22 2010 - 18:42:15 GMT
To: amavis-user@lists.sourceforge.net, miha.vrhovnik@domenca.si

Miha,

> as per docs the 1st match (row) that it is returned from sql wins.
> I'll be guessing, when lookup is made with %k, more than one row is
> returned but only 1st one is actually fetched. Would it be possible to
> combine those rows ascending to the priority e.g 0 is highest priority 7
> lowest, to get the final ruleset.
>
> Now you are probably wondering why. You could set the defaults and then
> override them in deeper levels. NULL value would mean leave value as is,
> every other would simply override the previous one.
>
> Having inheritance you could set up a general rule for whole domain and
> override some settings with per-email rules. There would be no need to
> copy the values from domain rule to the e-mail rule when such rule is
> created by user. End users can usually change just some parts of the
> policy (quar level, spam subject and spam points). I'm guessing here but,
> the number of policies that match is probably a lot smaller than 8. Well
> even if all 8 are returned combining them should be extremely fast.

Sorry for delay - I thought the idea is very good, wondered why it
hasn't been implemented yet, and intended to do so and report back.

Now that I finally set out to implement it, it turns out that
it already works this way and that documentation is wrong.
Versions up to 2.2.1 (no longer in 2.3.0) had some field names
that did provide a default value for nonexisting fields and stop
the search, but even then the NULL/undef value did not stop
further scanning of matching records. There could have been
an earlier version behaving as it was documented, memory on
that is fading me.

I'm updating the README.lookups with the following paragraph:

 A field value NULL is translated to a Perl undef, and is treated the same
 as a nonexistent field of the specified name. For any field (apart from
 the only exception field 'local') a record with a NULL/undef/nonexistent
 field is skipped and search continues with the next, more general,
 matching record until a defined value is found or all matching records are
 checked. The only exception is a field named 'local', where a nonexistent
 field on an otherwise matching record implies a value true - see section
 "Special handling of optional SQL field 'users.local'" further down.

> when lookup is made with %k, more than one row is
> returned but only 1st one is actually fetched

Not true with current versions. The lookup_sql_field() calls
the lookup_sql() with a get_all argument true, resulting in
all matching records being returned as a list.

> Would it be possible to
> combine those rows ascending to the priority e.g 0 is
> highest priority 7 lowest, to get the final ruleset.

The lookup_sql_field() already works this way as far as I can tell.

Thanks for pointing out the documentation problem. If you find
that current implementations do not meet your expectations,
please let me know.

(sorry for responding in English, I expect others too might be
interested in a reply)

  Mark

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
 Please visit http://www.ijs.si/software/amavisd/ regularly
 For administrativa requests please send email to rainer at openantivirus dot org