Gary,
> Did you unintentionally leave both $final_destiny and ccat entries
> uncommented in amavisd.conf-sample?
Indeed, (half) unintentionally, sorry for the confusion.
> I am aware you discourage use
> of amavisd.conf-sample as a method of configuring amavisd-new.
Hear, hear! It's just a bunch of examples.
> I assume only the last example will actually be used?:
> $final_destiny_by_ccat{CC_BADH.',2'} = D_PASS; # BadHdr8bit
Well, like with all assignments, the last assigned value stays in a variable.
For arrays (associative or plain arrays), an assignment can replace the whole
array in one statement, or can replace just individual elements.
In case of an assignment like:
%final_destiny_by_ccat = (
CC_VIRUS, D_DISCARD,
CC_UNCHECKED, D_PASS,
CC_BADH.',4', D_BOUNCE, # BadHdrSpace
CC_BADH.',3', D_BOUNCE, # BadHdrChar
CC_BADH, D_PASS, # sub-catchall for CC_BADH
CC_CLEAN, D_PASS,
CC_CATCHALL, D_BOUNCE,
);
the _whole_ array gets replaced by a new array.
Note the use of % before final_destiny_by_ccat, which is a Perl
syntax implying a whole hash, not an individual element.
An assignment like:
$final_destiny_by_ccat{CC_BADH.',2'} = D_PASS;
replaces just ONE ELEMENT of an associative array, and leaves
remaining elements unchanged. Note the use of a $ in front of
$final_destiny_by_ccat, which is a Perl syntax implying a scalar,
i.e. a plain variable or one element of an array.
So what currently stands in amavisd.conf regarding assignments
to %final_destiny_by_ccat is to be taken one piece at a time.
Leaving there all assignments to %final_destiny_by_ccat or to its
individual elements does not make much sense.
> This last example looks reasonable (not that I understand at this
> point what is really happening), so if it is the the only setting that
> will be used I guess it would not matter much one way or the other.
Don't know what to suggest, it is all rather a matter of personal preference.
Some folks prefer to explicitly configure all possibilities, others prefer to
leave most settings to their defaults and just change one or two specific
items. For the first, assigning the whole new replacement value to the
entire associative array may be best and cleanest. For the later,
small changes to specific elements like
$final_destiny_by_ccat{CC_SPAM} = D_PASS;
may be the best.
Also, some will prefer to keep using old config variables
to which we became accustomed, so should leave %*_by_ccat
at default. Others may want to completely forget old variables
(including most @*_maps), and specify settings and lists of
lookup tables directly in %*_by_ccat associative arrays.
Both approaches are valid.
For further reading, search the file amavisd for a comment:
# build backwards-compatible settings hashes
and see what default assignments to %*_by_ccat are.
Lets look at one (the first) assignment there:
%final_destiny_by_ccat = (
CC_VIRUS, sub { c('final_virus_destiny') },
CC_BANNED, sub { c('final_banned_destiny') },
CC_SPAM, sub { c('final_spam_destiny') },
CC_BADH, sub { c('final_bad_header_destiny') },
CC_OVERSIZED, D_BOUNCE,
CC_CATCHALL, D_PASS,
);
This ensures that for all legacy config variables
($final_virus_destiny, $final_banned_destiny, ...) they will get consulted
when mail contents is virus/banned/... respectively. The complication
with sub { c('...') } is there because config variables $final_virus_destiny,
$final_banned_destiny etc. are not necessarily global, but may be members
of a policy bank, and at the initialization time it is not yet known which
policy bank will be in effect at the time of mail processing, so evaluation
must be delayed until mail checking time.
The complication with sub { c() } is unnecessary when administrator
makes his own assignment to %final_destiny_by_ccat in amavisd.conf.
He already knows what his setting needs to be, so it can just as well be
specified directly. And %*_by_ccat hashes can themselves be members
of policy banks, so the c() evaluation becomes unnecessary.
Btw, note the last two keys: CC_OVERSIZED and CC_CATCHALL.
There never existed a config variable $final_oversized_destiny, so there
is no need to preserve compatibility, which is why a D_BOUNCE can be
directly specified in this initialization step (which is compatible with
previous behaviour, which wasn't configurable, but hard-wired).
Mark
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
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/
