Highlighting notes and some comments related to amavisd-new:
> - versions of amavisd-new between 2.5.2 and 2.6.1 (inclusive) are
> incompatible with SpamAssassin 3.3; please upgrade amavisd to 2.6.2 or
> later, or apply a workaround
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6257
Other versions of amavisd should be alright. Recommended version is 2.6.4.
> Rules are normally installed by running a sa-update command.
> The version of sa-update program should match the version of SpamAssassin
> modules, so invoking sa-update should be performed only after installing
> or upgrading SpamAssassin code, not before.
>
> Installing rules from network is done with a single command,
> normally run as root:
> sa-update
amavisd reload is needed after refreshing rules, as usual.
> - added a configuration option 'time_limit', defaulting to 300 seconds
> or whatever the caller (like spamd) provides; attempting to gracefully
> terminate the checking when a time limit is reached, reporting the score
> and test hits that were collected so far, along with an added hit on
> a rule TIME_LIMIT_EXCEEDED;
> - added option 'master_deadline' to the suppl_attrib argument of a
> Mail::SpamAssassin::parse method, allowing the caller to override a
> time_limit configuration setting;
The 'time_limit' setting should be set safely below $child_timeout setting,
which itself should be below Postfix' option smtp_data_done_timeout.
This is especially important when setting these limits low, such as
in a pre-queue content filtering setups.
With the next version of amavisd-new it will no longer be necessary
to adjust the time_limit setting in local.cf, thanks to the following new
feature of SpamAssassin, which will allow amavisd to pass its deadline
time directly to SpamAssassin, overriding its 'time_limit' setting:
> - more expensive code sections are now instrumented with timing
> measurements; timing report is logged as a debug message by the end of
> processing, and made available to a caller and to 'add_header' directives
> through a TIMING tag;
> - let the timing breakdown information be accessible to a caller through
> the existing get_tag mechanism (tag TIMING);
Current version of amavisd (since 2.6.0) already take benefit of this,
the timing report is logged at log level 2, e.g.:
Jan 26 18:05:23 dorothy amavis[80918]: (80918-07) TIMING-SA total 1502 ms -
parse: 3 (0.2%), extract_message_metadata: 28 (1.9%), get_uri_detail_list:
5 (0.3%), tests_pri_-1000: 24 (1.6%), tests_pri_-950: 1.79 (0.1%),
tests_pri_-900: 2 (0.1%), tests_pri_-400: 21 (1.4%), check_bayes: 19 (1.3%),
tests_pri_0: 961 (63.9%), check_dkim_adsp: 5 (0.3%), check_spf: 12 (0.8%),
poll_dns_idle: 274 (18.2%), check_dcc: 157 (10.4%), check_razor2: 541 (36.0%),
check_pyzor: 85 (5.6%), tests_pri_500: 283 (18.8%), tests_pri_899: 64 (4.3%),
check_crm114: 62 (4.1%), tests_pri_1000: 14 (0.9%), total_awl: 12 (0.8%),
check_awl: 4 (0.3%), update_awl: 2.00 (0.1%), learn: 35 (2.3%), get_report:
3 (0.2%)
amavisd-new-2.6.0 release notes:
- fetch additional information (tag) 'TIMING' from SpamAssassin, making it
available through macro 'supplementary_info' (if a version of SpamAssassin
in use provides it - available since 3.3.0);
- a SpamAssassin TIMING-SA report (timing breakdown by sections) is now
collected and logged at log level 2 when available; the information is
available since version 3.3.0 of SpamAssassin (currently in development
and available through SVN);
> - allowed debug areas to be excluded from debugging,
> e.g.: -D all,norules,noconfig,nodcc
Also available through amavisd command line options since 2.6.0:
# amavisd -d noall,dcc,rules debug-sa
> - adding one optional argument to Mail::SpamAssassin::parse allows caller
> to pass additional out-of-band information to SpamAssassin (such as a
> deadline time, DKIM verification results, information about a SMTP
> session, or dynamic rule hits); this information is made available to
> plugins and the rest of the code through a 'suppl_attrib' hash;
> - Plugin::Check - pick up 'rule_hits' from caller via the new mechanism
> and call got_hit() on them;
> - this plugin can now re-use Mail::DKIM verification results if made
> available by a caller, which saves resources and makes it possible
> for SpamAssassin to work on a truncated large mail without breaking
> DKIM signatures;
This ability is taken advantage of since 2.6.3:
amavisd-new-2.6.3 release notes:
- large messages beyond $sa_mail_body_size_limit are now partially passed
to SpamAssassin and other spam scanners for checking: a copy passed to
a spam scanner is truncated near or slightly past the indicated limit.
Large messages are no longer given an almost free passage through spam
checks.
Note that message truncation can invalidate a DKIM or DK signature.
If using (non-default) SpamAssassin rules to assign score points to mail
with no valid signatures from authors which are expected to always provide
a valid signature, the message truncation can cause false positives on
these rules. As a workaround, to a truncated message passed to spam
scanners, amavisd inserts a header field:
X-Amavis-MessageSize: mmmmm, TRUNCATED to nnnnn
which can be captured by SpamAssassin rules, e.g.:
header __TRUNCATED X-Amavis-MessageSize =~ m{\A[^\n]*TRUNCATED}m
and used in rules like NOTVALID_EBAY to prevent them from triggering.
Starting with version 3.3.0 of SpamAssassin, its DKIM plugin understands
the issue and receives undamaged DKIM signature objects directly from
amavisd, so the above workaround is not needed. Also, a hit on a __TRUNCATED
rule is automatically generated (explicit header rule is not necessary),
just in case it might be useful for some purpose.
- supports passing an extra argument suppl_attrib to $spamassassin->parse,
as recognized by SpamAssassin 3.3.0, passing a set of DKIM signature
objects to a SpamAssassin's plugin DKIM, which saves having to do the
same signature verification operation again within a plugin, and provides
uncrippled signatures to SpamAssassin even when a large message is
truncated by amavisd and only partially submitted to spam analysis;
> - let the generated header fields ('add_header' configuration options)
> be accessible to a caller through the existing get_tag mechanism
> (tags ADDEDHEADER, ADDEDHEADERHAM, ADDEDHEADERSPAM);
This will be used by the next release of amavisd:
- added macros 'ADDEDHEADERHAM' and 'ADDEDHEADERSPAM', which expand to newly
generated header fields which SpamAssassin prepared for insertion into a
header section, in case the message is eventually declared to be nonspam
or spam respectively; this information is available from SpamAssassin
since version 3.3.0;
- recognize and insert header fields as prepared by SpamAssassin 3.3.0
or later through its 'add_header' configuration option; some of the
standard X-Spam-* header fields are still overruled by equivalent ones
generated by amavisd itself, primarily to provide true per-recipient
handling; header field names must still be listed in the associative
array %allowed_added_header_fields in order to be inserted;
overrides are configurable through %prefer_our_added_header_fields;
> - reworked the M::S::Timeout module to deal with nested timers as one would
> expect: an inner timer shouldn't be able to extend an outer timer's
> limit; account for time elapsed in the submitted subroutine when
> restarting an outer timer; reset() should have accounted for time already
> spent; deal with nested timed runs where alarm(0) does not provide
> remaining time;
This also allows for tighter controls on the master_deadline feature,
which will be put to good use with the next release of amavisd
as one of the key components for better behaviour of pre-queue
content filtering setups.
Mark
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
