I am debugging a problem in which the virtual mail folder hierarchy
is being created with the wrong user rights (root/root, rather than
vmail/vmail). I have found the culprit to be spamd.

spamd is running with options

  --create-prefs --max-children 5 --helper-home-dir --allow-tell
  --paranoid --virtual-config-dir=/srv/vmail/%d/%l/.spamassassin -x
  -D --pidfile=/var/run/spamd.pid

postfix delivers to spamc:

  spamc -x -u ${recipient} -e /usr/lib/dovecot/deliver -d ${recipient}

and this causes spamd to print the following debug info:

[4319] info: spamd: using default config for test@madduck.net:
/srv/vmail/madduck.net/test/.spamassassin/user_prefs
[4319] dbg: info: user has changed
[4319] dbg: config: using "/srv/vmail/madduck.net/test/.spamassassin" for user
state dir

note how it uses the default config (which actually means that it
installs the default config) before changing the user. As a result,
/srv/vmail/madduck.net/test will be owned by root and mode 0700 (die
to the restrictive umask I use). When later the deliver process
tries to write the mail to the directory as the vmail user, it
fails.

I think spamd should install the configuration for new users (when
it does not yet exist) only *after* dropping root rights.