Dear community,
A new version of the SpamAssassin plugin has just be released
Version compatible with i-MSCP Serie ≥ 1.4.x
CHANGELOG
- Added: Plugin configuration parameters for the `DKIM' SA plugin (disabled by default)
- Added: Plugin configuration parameters for the `SPF' SA plugin (disabled by default)
- Added: Plugin configuration parameters for the `Rule2XSBody' SA plugin (enabled by default)
- Backported: Changes from https://github.com/smfreegard/DecodeShortURLs/pull/2 (DecodeShortURLs.cf file only)
- Changed: DKIM and SPF SA plugins are now disabled by default
- Changed: MILTER default action from `accept' to `tempfail'
- Changed: Usage of UDS instead of TCP for SPAMD(8p) -- Performance boost
- Enhancement: Automatically install distribution packages
- Fixed: Bad ownership set on DecodeShortURLs and iXash2 SpamAssassin plugin files
- Fixed: Cronjobs are not registered when the plugin get re-activated
- Fixed: Delay restart of SA services on i-MSCP upgrade/reconfiguration
- Fixed: Discard any user preference that belongs to a disabled plugins in user scores and preferences SQL query
- Fixed: Give SpamAssassin a higher priority by adding it at begin of the smtpd_milters list
- Fixed: Guess the SPAMD(8p) unix user/group instead of hard-coding them
- Fixed: Make sure that configuration files are created with expected UMASK(2)
- Fixed: Make use of iMSCP::Crypt library to generate SA SQL user password
- Fixed: On plugin reconfiguration, current user preference must be preserved whenever possible (see UPDATE.md file)
- Fixed: SA bayesian data and user preferences which belong to an i-MSCP email account being deleted are not removed
- Fixed: SA database must be dropped on plugin uninstallation
- Fixed: Stop and disable SA services on plugin deactivation
- Fixed: Synchronize the database and the journal once per training session (sa-learn)
- Removed: i-MSCP 00_imscp.pre SA configuration file; SA Plugins are now loaded from distribution package files
- Removed: `use_auto_whitelist' preference from the `userpref' database table as this preference is not settable
- Removed: Blacklist score preference (-6) from the `userpref' database table; Default (-100.00) fits better
- Removed: Whitelist score preference (10) from the `userpref' database table; Default (100.000) fits better
- Review: Early exits if the storage server is not running (cronjobs)
- Review: Make use of an all-in-one SQL query instead of 6 queries to delete user bayesian data stored in database
- Rewritten: Plugin configuration file
- Updated: Roundcube MarkAsJunk2 plugin from version 1.9 to version 1.10
- Updated: Roundcube SAUserPrefs plugin from version 1.15 to version 1.16
Update notes
## New default configuration values
This new version comes with new default configuration values which better fit
with common usage of SpamAssassin in shared hosting environments and cover the
case where other i-MSCP plugin providing identical features could be
concurrently installed.
### Default policy for SPAM rejection
In previous versions, the default policy for SPAM messages was to reject them.
Doing this in shared hosting environments is really a bad practice as there can
always have false-positive results. A message could be seen as a SPAM when it
is not.
The common rule that dictate how SPAM must be handled by ISPs is that the
decision must be left to end-users. Therefore, the new default policy is to
reject SPAM which score is higher than 15. That is a good compromise and
greatly mitigates case of false-positive results.
### DKIM, SPF SpamAssassin plugins and RBL checks
Both DKIM and SPF SpamAssassin plugins and the SpamAssassin RBL checks are now
disabled by default, covering case where administrator already make usage of
other i-MSCP plugins:
- i-MSCP PolicydSPF plugin: Same as the SPF SpamAssassin plugin
- i-MSCP OpenDKIM plugin: Same as the DKIM SpamAssassin plugin
- i-MSCP Postscreen plugin: Same as the RBL checks provided by SpamAssassin
- i-MSCP PolicydWeight plugin: Same as the RBL checks provided by SpamAssassin
Excepted the i-MSCP Postscreen plugin usage case, best would be to de-install
the i-MSCP plugins listed above and enable their SpamAssassin counterparts.
## Scores for blacklist and whitelist
Scores for both blacklist and whitelist where resetted to SpamAssassin default
values which fit better for the purpose of that feature.
## SpamAssassin user preferences -- Implementation details
In previous versions, the user preferences were been reset each time the plugin
was being reconfigured, which was a bad implementation. User preferences should
not be resetted when that is not explicitly requested by the administrator.
To solve this problem, the plugin configuration file has been fully rewritten,
now providing the administrator with an additional enforce configuration
parameter that allows to force usage of a specific plugin.
In enforced mode, end-users won't be able to act on the plugin through their
user preferences and existing user preferences for that plugin are deleted.
Note that the enforce configuration parameter is only provided for some
plugins.
To resume, the new policy is as follows:
- When a plugin is being enabled, never reset user preferences, excepted if in enforced mode.
- When a plugin is being disabled, never reset user preferences. This don't pose any problem because the SpamAssassin plugin will be fully disabled.
## SPAMD connection mode
In previous versions, connection to SPAMD(8p) was established through TCP.
Starting with this new version, connection is now established through UDS
(Unix Domain Socket).
This is a boost-performance change as the network stack is no longer involved.
Thank you for using our plugins.
