Andy,
> >> If I write
> >> $sa_spam_subject_tag = '***SPAM***(_SCORE_(00)_)*** ';
> >> I get a literal "***SPAM***(_SCORE(00)_)***".
> >
> > I think this feature only works in *maps
Should work on old-style individual settings like $sa_spam_subject_tag
just fine. After all, the default @*_maps just contains references
to these variables for backwards compatibility.
> Interesting. I can't seem to find good documentation on what these *maps
> variables are and how to use them properly.
There is no big deal to these @*_maps lists. Instead of passing multiple
lookup tables to a lookup subroutine like before:
lookup($sender, \%local_domains, [EMAIL PROTECTED], \$local_domains_re)
the list of lookups tables is now collected in an array variable,
and passed as a single argument:
default setting:
@local_domains_maps = (
\%local_domains, [EMAIL PROTECTED], \$local_domains_re);
a lookup call:
lookup($sender, @local_domains_maps);
As an added flexibility, the @*_maps variable can be assigned-to directly
in a configurations file - or the @*_maps variable can be left at its
default and individual variables like %local_domains assigned to.
amavisd-new-2.0 release notes:
- new configuration variables make it more flexible to specify arbitrary
list of lookup tables. Legacy configuration variables are still available
and are referenced from the default values of @*_maps lists. If these lists
are redefined, legacy variables are not used.
[...]
- simplify and unify calls to lookup() by collecting arguments (references
to lookup tables) in lists, e.g. @local_domains_maps, @virus_lovers_maps,
@virus_admin_maps. These array variables default to lists of legacy
variables, which are now never directly used by the program. Either
the individual legacy variables may be assigned to, or the entire list
replaced, in which case the legacy variables no longer have any effect.
Available lookups table types are described in README.lookups,
i.e. a constant, hash, list, a regexp list.
> >> But what I'd like to have is:
> >> ***SPAM***(05.76)***
The zero-padding is only available when _SCORE(pad)_ is expanded as a true
macro call (e.g. in notification and log templates). Unfortunately the
pad argument is not understood in a simple string sunstitution like
used in the Subject template, which currently is not implemented as
a true macro call - for speed.
> @spam_subject_tag_maps = ('***SPAM***(_SCORE_)*** ');
> And what's worse ALL mails are tagged, not just SPAMs. Ooooeee.
@spam_subject_tag_maps applies to score above tag_level.
Use the @spam_subject_tag2_maps instead, which applies at tag2_level.
For completeness, here are the default associations of a mail content type
with a subject modification template, for each content category:
%subject_tag_maps_by_ccat = (
CC_VIRUS, [ '***INFECTED*** ' ],
CC_BANNED, undef,
CC_UNCHECKED, sub { [ c('undecipherable_subject_tag') ] },
CC_SPAM, undef, # kill_level
CC_SPAMMY.',1', sub { ca('spam_subject_tag3_maps') }, # tag3_level
CC_SPAMMY, sub { ca('spam_subject_tag2_maps') }, # tag2_level
CC_CLEAN.',1', sub { ca('spam_subject_tag_maps') }, # tag_level
);
Mark
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
