Postfix main.cf has:
mailbox_command = /usr/bin/procmail
/etc/procmailrc is: DROPPRIVS=yes
:0fw | /usr/bin/spamc -u $LOGNAME -x -s 100000000
/var/mail/jwz gets X-Spam-Status headers written into it. So far so good.
/etc/dovecot/dovecot.conf (for dovecot 2.0) has:
protocol lda { ... mail_plugins = sieve ... }
Dovecot is managing to read messages out of /var/mail/jwz and deliver them to me over IMAP, with SA headers intact. But it's not running sieve, possibly not even running its own lda, and everything I have googled so far is a twisty maze of illiterate wikis that may or may not be written for versions of the software that is 5+ years out of date. I thought maybe the answer was to add
| /usr/libexec/dovecot/deliver -d $LOGNAME
to the end of procmailrc, but that let me to discover that:
% cat testmsg | /usr/libexec/dovecot/deliver -d jwz
Exit 75
lda: Error: dlopen(/usr/lib64/dovecot/lda/lib90_sieve_plugin.so) failed: /usr/lib64/dovecot/lda/lib90_sieve_plugin.so: undefined symbol: tried_default_save
lda: Fatal: Couldn't load required plugins
So I guess I have the wrong version of the sieve plugin? I have: dovecot-2.0-0.18_114_rc3.el5 and dovecot-sieve-0.1.17-5.el5 on CentOS release 5.4 (Final)
Update: Ok, I seem to have figured it out. First, "dovecot-pigeonhole" is the oh-so-obviously-named package in which the proper version of sieve resides. Second, it looks like I don't actually need to let procmail darken my doorstep at all, as I can just do this in postfix's main.cf:
mailbox_command = /usr/bin/spamc -x -s 100000000 -e /usr/libexec/dovecot/deliver
Also, log_path and info_log_path have to be blank (meaning "use syslog") in the lda section of dovecot.conf, otherwise lda/sieve can't write to dovecot's log files. Hopefully this isn't doing something stupid like allowing sieve to write arbitrary files as root. With the quality of the related documentation, who can tell. But the logfile thing suggests not, I guess.
Update 2: Oh, well here's a problem: that bounces mail if spamd is down. Which it is, briefly, every night when it is restarted with -HUP after running "sa-update". Dammit. Any suggestions?
Update 3: Add "|| exit 75" to mailbox_command to have Postfix queue-and-retry on failure.
I have not solved your problem. All I wanted to say was that I have a similar mail setup and I saved myself untold grief by having procmail do the delivery itself.
For example, this would make procmail deliver everything to your IMAP inbox.
So I looked at it, and the way my setup works is that it just uses procmail. If you have a strong desire not to rewrite your sieve rules back into procmail ones, please ignore me.
This is how you would file into IMAP folders using procmail rules alone.
I don't have any sieve rules yet. I have exactly one procmail rule, "run SA".
The problem is, sieve's rule syntax is sane, and procmail's makes me think "wow, I'd rather eat glass than have to try and remember this fucking syntax every time I join a new mailing list."
Perhaps try maildrop instead of procmail? I find its syntax to be much easier.
I do this by running SpamAssassin as a Postfix mail filter through master.cf, then having Dovecote's LDA do the delivering with sieve filtering enabled. Procmail is not involved.
The relevant configuration is at work, which I can't get to until Monday. If no one else has posted details by then, I'll add a followup with my configuration.
For Dovecot 2.0, you need dovecot-pigeonhole instead of dovecot-sieve. If you want stable releases with current documentation, use Dovecot 1.2 and dovecot-sieve.
Well, that helped, but "deliver" is still doing fuck-all. If my procmailrc tries to pipe spamc into deliver, then the mail that arrives has no SA headers -- which I think means that one of those programs is exiting with an error, and procmail is falling back on the unfiltered message? I don't know what's going on and I don't see any errors in any log files.
Using spamassassin directly instead of spamd would avoid that problem. I've never noticed a sufficient performance hit (for my servers) between using it in CLI mode versus daemon mode, such that I felt it was worth running spamd.
Hmm, spamc --connect-retries=10 --retry-sleep=15 ? The defaults are 3 and 1, respectively, which I think would mean a 3-second spamd outage could bounce mail.
More options I didn't know about, thanks. I'll do that along with "exit 75".
Why do I get the impression that something about all E-Mail servers is fundamentally broken?
Why do we still have to download five different pieces of software, then spend hours trying to plug them together? Why isn't there one integrated package that Just Works yet?
It seems like configuring one requires practising an arcane form of voodoo that nobody understands. Even so, its still pretty much your most critical service, if only because its how your error reports are delivered....
Well, I think that integrated package that just works is called "gmail".
The only reason I'm running my own mail server is because I don't trust Skynet to not roll over on subpoenas for me. This is probably not something that most people, or even businesses, care about.
To avoid bouncing mail you can do one of two things:
Didn't know about the 75 trick, that's perfect. Thanks.