Spamassassin username for bayes and txrep is amavis.

[Dusan Obradovic]

> On May 31, 2018, at 06:43, Philip <philip at 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 = (
      { 'user1 at example.com' =>
          '/etc/mail/spamassassin/special_user_config',
        '.example.org' => 'sql:',
      }
    );

@sa_username_maps = (
      { 'user1 at example.com' => 'user1',
        'user2 at 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 = (
      { 'user1 at 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 = (
      { 'user1 at example.com' => 'user1',
        'user2 at example.com' => 'user2',
        '.example.com'      => 'user_ex',
      }
    );