SpamAssassin plugin v2.0.0 RELEASED

  • Dear community,

    A new version of the SpamAssassin plugin has just be released

    Version compatible with i-MSCP Serie ≥ 1.4.x


    • 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 ( 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 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

    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.