postfix and spamassassin

So I had been running spamassassin from postfix like this:

mailbox_command = /usr/bin/spamc
                 --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/.spamassassin/user_prefs and the latter does not. Is there some way to make the latter do what the former does? Or is the former actually the right way to do it?


Tags: , , , ,

7 Responses:

  1. 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?

  2. Ewen McNeill says:

    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).


    • jwz says:

      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 any more. Hooray?

      • Ewen McNeill says:

        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.


      • Soupdragon says:

        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.


  3. I have this in
    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.

  4. Jeroen says:

    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.