Spamassassin unintentionally honoring user_prefs

Postfix is configured to use Spamassassin as a milter, and spamd runs as user debian_spamd (homedir: /var/lib/spamassassin) with no per-user configuration. All mail is forwarded to a remote server. Every time spamd encounters a message for an existing username (e.g. [email protected]), it does this:

Jan 30 07:00:22 eden spamd[385091]: spamd: creating default_prefs: /home/existinguser/.spamassassin/user_prefs
Jan 30 07:00:22 eden spamd[385091]: spamd: failed to create readable default_prefs: /home/existinguser/.spamassassin/user_prefs

Stranger even, when a message arrives without a corresponding local user (e.g. for [email protected]), spamd tries to access the existing user's home dir to read/write the bayes files:

Jan 30 07:00:59 eden spamd[385091]: spamd: handle_user (userdir) unable to find user: 'nonexistinguser'
Jan 30 07:00:59 eden spamd[385091]: spamd: processing message <220130080050QP.30506@msbatch05> for nonexistinguser:111
Jan 30 07:01:00 eden spamd[385091]: plugin: eval failed: bayes: (in learn) locker: safe_lock: cannot create tmp lockfile /home/existinguser/.spamassassin/bayes.lock.localhost.385091 for /home/existinguser/.spamassassin/bayes.lock: Permission denied

I realized that I had to add --nouser-config to the Spamassassin options in /etc/default/spamassassin, although allow_user_rules defaults to 0/off (as per the documentation and this thread).

So the problem is solved, but I still wonder why

• I had to add an option to achieve the default behavior
• spamd tried to use an existing user's .spamassassin subdirectory for non-existing users

I am grateful for any hints.

Thanks, Jan