On Thu, 2013-01-10 at 11:51 -0500, Kevin A. McGrail wrote: > Overall, what we almost need is "Usage scenarios" and appropriate > parameters. Then we can identify scenarios with missing parameters to > support. > Its been a while since I had to go near my spamc configuration, so I've just had a look and here's what I've found. Consider the following to be my "Usage scenario"
As a low volume user, I get incoming mail from my ISP's mail server with getmail, which pipes it through spamc and then spamkiller, a locally written program. Spamkiller looks at the X-Spam-Flag header and quarantines messages with "YES" in this header. All other messages are passed to postfix.sendmail for delivery to the Postfix MTA. Outbound mail is sent via the local Postfix, which delivers it to my ISP's MTA via SMTP. It also sends a copy to my mail archive, which acts as a whitelisting database (any address I've sent mail to gets whitelisted). I've been running spamc with all options defaulted. I notice that when spamc is run this way all messages passed to it are always written out on stdout regardless of the exit status. The MDA script used by getmail ignores the spamc exit codes: as a result all non-spam messages are sent to Postfix, even those that exceed the size limit or are received when the whitelisting DB is offline to be backed up. This is exactly what I need. Nonetheless, I've just added the --exitcode option to spamc. I don't expect it to have any effect: rather, its a reminder to me to look at spamc exit code handling if I ever need to change the MDA script. > Or perhaps spamc needs a configuration file to set any and all of the > possible exit levels which would alleviate the need for all these > switches perhaps? > It already has a config file, though this is just another place to put the various option settings. > Unfortunately, the current way spamc exits meets all of my needs so I'm > not sure of the scenarios otherwise needed. > Same here. Martin
