Benedict,
> many thanks for including my suggestion, however I seem to have a problem
> in that all spam is being sent for [EMAIL PROTECTED] rather than just that
> at or above kill level.
Adding address extensions is done at tag2 level in 2.4.1 (more precisely:
at CC_SPAMMY contents category), just like in 2.3.3. The 2.4.0 was
unintentionally different and was adding extensions at kill level (CC_SPAM),
like amavisd-new-2.0 and earlier.
amavisd-new-2.4.1 release notes:
- revert a change introduced with 2.4.0, which was adding address extensions
at CC_SPAM, i.e. when score exceeds kill level. Previously (2.3.3) address
extensions were inserted at tag2 level. Implemented by a new mechanism:
a new major contents category CC_SPAMMY is inserted just below the CC_SPAM,
where CC_SPAMMY is controlled by tag2_level and CC_SPAM continues to be
selected at kill_level. Also spam defanging (if enabled) is now activated
at CC_SPAMMY and no longer at CC_SPAM (which was on a TODO list for some
time); undesired change in 2.4.0 reported and changes tested by Mario Liehr;
amavisd-new-20040701 / amavisd-new-2.0 release notes:
- add address extension at tag2 level, not at kill level as before;
suggested by Jacob Elder and others;
It is now possible to change that behaviour in amavisd.conf,
thanks to new contents category associative arrays.
The default %addr_extension_maps_by_ccat is:
%addr_extension_maps_by_ccat = (
CC_VIRUS, sub { ca('addr_extension_virus_maps') },
CC_BANNED, sub { ca('addr_extension_banned_maps') },
CC_SPAM, sub { ca('addr_extension_spam_maps') },
CC_SPAMMY, sub { ca('addr_extension_spam_maps') },
CC_BADH, sub { ca('addr_extension_bad_header_maps') },
);
To turn off adding address extensions at CC_SPAMMY (=tag2 level),
you can either just remove the offending entry in the hash
by putting:
delete $addr_extension_maps_by_ccat{&CC_SPAMMY};
in amavisd.conf, or by reassigning the whole hash explicitly, e.g.:
%addr_extension_maps_by_ccat = (
CC_VIRUS, sub { ca('addr_extension_virus_maps') },
CC_BANNED, sub { ca('addr_extension_banned_maps') },
CC_SPAM, sub { ca('addr_extension_spam_maps') },
CC_BADH, sub { ca('addr_extension_bad_header_maps') },
);
> Further more, not all is getting its address rewritten correctly by
> postfix.
You will have to be more precise.
> $sa_kill_level_deflt = 10.0; # triggers spam evasive actions
> $sa_dsn_cutoff_level = 10; # spam level beyond which a DSN is not sent
Having dsn_cutoff_level the same as (or lower then) kill level
is equivalent to setting spam destiny to D_DISCARD (instead of bounce).
This would be equivalent but more obvious:
$sa_kill_level_deflt = 10.0;
$final_spam_destiny = D_DISCARD;
> $sa_tag2_level_deflt = 6.31;
> @spam_tag2_level_maps = (5);
Assigning a new list directly to @spam_tag2_level_maps
makes the $sa_tag2_level_deflt redundant, it is never used
because the new list in @spam_tag2_level_maps (i.e. a (5) )
no longer contains a reference to $sa_tag2_level_deflt.
Not a problem, just want to point it out.
Mark
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&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/
