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/