| Summary: | incorrect runlevel order for spamd and mta | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bo Majewski <bo> |
| Component: | Current packages | Assignee: | Net-Mail Packages <net-mail+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
fixed in CVS. |
Currently, the spamd script placed in the /etc/init.d directory depends on net only. However this may lead to spam sneaking in, right after a reboot. The following explanation uses fetchmail, postfix, procmail and courier-imap, but it works the same for any other software. In my setup I use fetchmail to get mail from a POP3 server, forward it to MTA (postfix), which uses procmail to distribute it to IMAP maildir mail boxes (courier-imap). Procmail calls spamassassins' spamc to do filtering and messages marked as spam go to .SPAM. That works very well, except right after the system reboot. I use spamc, rather than spamassassin to filter e-mail, due to performance advantages. The order in which the default runlevel arranged fetchmail, postfix and spamd (needed by spamc) is postfix, fetchmail, ... and spamd. By "..." I mean other scripts. For me there is a hotplug started between fetchmail and spamd. This gives enough time for fetchmail to fetch, well, mail, give it to postfix, which forwards it to procmail, which tries to run spamc. But it fails, as spamd has not yet been fully started. Procmail's respose to the failure of one of the rules is to just dump e-mail in my Inbox. The actual content of the procmail log reporting this issue was: procmail: Program failure (69) of "spamc" procmail: Rescue of unfiltered data succeeded Reproducible: Always Steps to Reproduce: 1. Create a setup POP3 -> fetchmail -> MTA -> procmail using spamc -> maildir 2. Stop your mail server for long enough to receive spam mail 3. Start the computer and watch, in procmail logs, reports about spamc failing Actual Results: Mail, that is usually classified as SPAM ended in my mailbox rather than SPAM mail box Expected Results: Mail should be filtered through by spamc and marked as spam. As a consequence filters in .procmailrc would be given a chance to correctly classify the message. I suspect that all is needed is a corrected depends section in the /etc/init.d/spamd script. At the moment the depend section looks like this: depend() { need net } Possibly, by adding "before mta" one could make sure that spamd is always started before MTA has a chance to start distributing e-mail via procmail. Alternatively, maybe one could use "use fetchmail", but this will not work well in systems that do not use fetchmail. However use, being a weak dependency, might work.