mailbox_command = /usr/bin/spamc
--no-safe-fallback
--max-size 100000000
--connect-retries 5
--retry-sleep 5
--pipe-to /usr/libexec/dovecot/deliver
|| exit 75
but it seems like maybe the proper way is:
mailbox_command = /usr/libexec/dovecot/deliver
smtpd_milters = unix:/var/run/spamass-milter/postfix/sock
non_smtpd_milters = $smtpd_milters
milter_default_action = accept
however, the former runs the final recipient's $HOME/
The former way won't work with every mail delivery agent, and so is somewhat dependent on Dovecot (or UW, or Panda). But since that's what you use, go for it.
The latter method doesn't fork off a shell, mind, but who's going to find a network-exposed security exploit in a frigging shell, right?
TL;DR: check spamass-milter is being run with "-u" to pass the "username"; it's not a complete fix, but it's better than without.
The Milter version will run the spamassassin check before accepting the mail, whereas I suspect the mailbox version will result in queueing the mail and then attempting to put it in the mailbox (not sure, I've not used the Postfix/Dovecot/mailbox_command version you list). Not accepting spam at SMTP time is definitely better than accepting it then trying to deliver it, if that's what the mailbox_command version is doing (especially if repeated delivery failure eventually results in a bounce being generated).
Unfortunately spamass-milter is a bit of a kludge. Firstly it doesn't pass the username to spamassassin at all unless spamass-milter is run with "-u", so AFAIK user preferences won't be used with out that. Secondly, spamass-milter's idea of "username" is "the bit before the @ in the destination email address" so... it's somewhat approximate (and particularly poor for outgoing mail). Thirdly, spamd needs to be run with permissions to access the user preferences in either case (eg, group/group ownership, or as root :-( ); you've presumably got that sorted, but just mentioning FTR.
(There is a "-x" flag to spamass-milter which apparently tries to use "sendmail -bv" to expand the destination address into a mailbox, but I'm not sure if that option is compatible with postfix's "sendmail -bv". Plus IIRC postfix's "sendmail -bv" generates an email to the destination address each time it is used, which is almost certainly undesirable for routine use by spamass-milter.... I've certainly not used the "-x" flag on spamass-milter with postfix.)
So the mailbox_command version almost certainly has a better idea of the actual user name (due to being run as that unix user), and hence is more reliably going to find $HOME/.spamassassin/user_prefs. But maybe "-u" to spamass-milter will get you close enough you can live with it (it did for my mostly-one-user mail server).
Ewen
That's what I was afraid of. So basically, if "jwz" is the recipient but "mailing-list-of-which-jwz-is-a-member" is in the To line, then jwz's SA rules don't get run. That is so amazing that it makes me want to ask "what year is this?" but as with all things Linux, that's a foolish question, because the answer is "1993".
September is not the only thing that never ended that year.
At least I'm not typing teco-esque line noise into sendmail.cf any more. Hooray?
FWIW, there is one special case which may help: after "-u" in the spamass-milter command line you can list a user, which will be the default user if the lame "guess the user from the literal local part" bit doesn't turn into, you know, an actual user. For a mostly-single-user-MTAs that sorta, kinda, makes it semi-okay. YMMV.
Ewen
Still nursing the PTSD of moving to RHEL7, with all its Systemd and grub2 second-system kitchen-sinkery, I dearly wish it still were 1993.
S.
I have this in master.cf:
dovecot unix - n n - - pipe flags=DRhu user=vmail:mail argv=/usr/local/bin/spamc -u ${recipient} -e /usr/local/libexec/dovecot/deliver -d ${recipient}My dovecot accounts are "virtual" as in non-system accounts; SA prefs are stored in MySQL and can be manipulated through RoundCube. Mail is always accepted but filtered into a spam folder.
I've been running spamassassin through procmail for some time. I had to put in a size restriction to prevent spamassassin from hanging itself, but other than that it runs fine.