> On May 31, 2018, at 06:43, Philip <phi...@treads.nz> wrote: > > Afternoon list, > > I've got spamassassin set up to read from a MYSQL database. It's working > nicely but it's not sending 'amavis' across as the user not the email address > (as the username) of the virtual user. I was wondering if this is the > intended result while using amavis or is there a way to pass the username as > the email address. > > Phil > > >
Short version: Example: @sa_userconf_maps = ( { 'us...@example.com' => '/etc/mail/spamassassin/special_user_config', '.example.org' => 'sql:', } ); @sa_username_maps = ( { 'us...@example.com' => 'user1', 'us...@example.com' => 'user2', '.example.com' => 'user_ex', } ); From changelog: - per-recipient (or per- policy bank, or global) SpamAssassin configuration files or SQL configuration sets are now supported (the @sa_userconf_maps setting, a policy.sa_userconf SQL field). A multi-recipient message whose recipients map to different configuration sets will be checked by calling SpamAssassin multiple times, once for each unique SpamAssassin configuration set. A configuration set is either a filename, or a set of SQL records obtained from SpamAssassin's user_scores_dsn SQL database by calling its method load_scoreonly_sql(). A lookup on a list of lookup tables @sa_userconf_maps may return undef or an empty string implying no user preferences file, or may provide a file name (absolute path, or relative to $MYHOME) of a SpamAssassin's 'user preferences' configuration file, or may start with a string 'sql:' which implies loading user preferences from a user_scores_dsn SQL database (as declared in a SpamAssassin's configuration file) for a username provided by a lookup on @sa_username_maps (see further down). SpamAssassin will be requested to load a user preferences configuration through its read_scoreonly_config() or load_scoreonly_sql() method, which otherwise (in spamd) serves to load user's .spamassassin/user_prefs file or SQL preferences when switching users. See SpamAssassin documentation file sql/README for SQL details. SpamAssassin's SQL database is only consulted if user_scores_dsn is declared in a SpamAssassin configuration file, and the @sa_userconf_maps returns a string starting with 'sql:' (case insensitive, the rest of the string is currently ignored). If a username as provided by a lookup on @sa_username_maps equals the username under which amavisd was started, SpamAssassin's SQL preferences for that username will not be loaded - it is assumed that preferences for a default username are empty, i.e. that it uses a default SpamAssassin configuration. Each time that currently loaded configuration needs to be replaced by another or restored to a systemwide default, an initial SpamAssassin configuration is restored through SpamAssassin's copy_config() method. Note that saving an original SpamAssassin configuration, loading a user configuration, and restoring to the original configuration does not come cheap: it can take 200 ms for a load and restore, and 370 ms for the initial saving of the configuration (saving is only done once per child process, and only if needed). Saved configuration can occupy additional 2 MB of virtual memory, so use the feature sparingly. No penalty occurs until a child process does its first loading of a user configuration, so rarely activated or inactive policy banks or per-recipient setting using this feature do not cause any additional processing or occupy additional memory. According to SpamAssassin documentation, a user preferences file or SQL preferences can include scoring options, scores, whitelists and blacklists, etc. If 'allow_user_rules' is enabled (local.cf), then user preferences file can also include rule definitions and privileged settings - but not administrator settings. The feature is only available since SpamAssassin 3.3.0. Example: @sa_userconf_maps = ( { 'us...@example.com' => '/etc/mail/spamassassin/special_user_config', '.example.org' => 'sql:', } ); Based on a suggestion by Alexander Wirt and initially based on his patch; - added a global configuration setting $sa_num_instances with a default value of 1, which is the only sensible setting for sites not using per-recipient SpamAssassin configuration switching (as described in the previous section). The $sa_num_instances controls the number of Mail::SpamAssassin objects (instances) created by a parent amavisd process during a startup. Each SpamAssassin instance does its own initialization (loading of rules and configuration settings) during a program startup and occupies a sizable portion of virtual memory (like 7 MB on a 64-bit platform with SA 3.4 rules). When switching SpamAssassin configurations (@sa_userconf_maps), and given more than one instance of the Mail::SpamAssassin object, amavisd has a choice of picking an instance which may already have loaded a selected user configuration file previously, and thus save some time by not having to store and reload SpamAssassin state again. This may be beneficial for example when a sizable portion of users use a default SpamAssassin configuration, while other users need a per-user or per-domain preferences settings; Note that as of SpamAssassin 3.3.2 some features (like compiled rules) are global and not a property of a SpamAssassin instance object. The problem is tracked in the SpamAssassin project as Bug 6236. Until this is resolved please consider the feature experimental. - per-recipient (or per- policy bank) SpamAssassin SQL database usernames are supported (setting @sa_username_maps, a policy.sa_username SQL field). This makes it possible to implement per-user or per-user-group or per-domain Bayes databases when SpamAssassin is configured to keep its Bayes database on an SQL server. It also makes it possible to load per-recipient SpamAssassin preferences (configurations) from an SQL database (as described in a previous section). Switching between Bayes usernames is cheap compared to switching between SpamAssassin configuration files. A multi-recipient message whose recipients map to different usernames will be checked by SpamAssassin multiple times, once for each unique username; Example: @sa_username_maps = ( { 'us...@example.com' => 'user1', 'us...@example.com' => 'user2', '.example.com' => 'user_ex', } );