Okay... didn't expect that much discussion, glad for it though. Turns out most of this comes down to your philosophy of what dbmail should do.
Christian Warden suggested using the -m flag of dbmail-smtp to deliver it to a seperate mailbox. I wasn't actually aware of that option as it's not mentioned in the man page, and it does the job pretty well (although it'll hurt my head to figure out the sendmail config...). However, as Michael Häusler pointed out, it does have the limitation of being hard-coded in the MTA, whereas I believe it would be better to allow it to be optionally set by the end user. The potential for end-user configuration is one of the core strengths of dbmail in my eyes. Additionally, for those who have separate servers dedicated to scanning incoming mail, they may not with for the MTA on the dbmail host to spawn additional filtering mechanisms, and prefer to use a lightweight MTA to hand it on to dbmail. It certainly is a good alternative for people who are doing the scanning on the same server, and who don't care for end-user configurability, so I will add it to my 'things to document' list. What didn't get discussed however, and I thought this would generate more controversy, was the idea of sending a summary to the user as part of the maintenance run. Do people think this should be part of dbmail-maintenance, or should it be a separate run? Finally, as I mentioned, I have no experience with IMAP, so should a spam mailbox be called 'Spam', '/Spam', or something else? -- Feargal Reilly, Codeshifter, Chrysalink Systems.
pgp6UOcOPQrN7.pgp
Description: PGP signature
