Comment 2 for bug 158136

Both the "dspam" and "dspamc" binaries perform the same function : Check a message for being spam or not, and either one or the other is used by MTA or MDA (or any user on the system).

"dspam" can be run either one-shot or as a daemon. "dspamc" is actually just a lighter, stripped-down version of dspam (which means logically, more secure), that can only act as a client to "dspam" running in daemon mode.

Which means that one processes a message either with one-shot dspam (slow startup and databases opening), or with a dspam running as a daemon, sending messages to the lighter "dspamc" which is the client to the daemon.

"dspam" comes sgid dspam, "dspamc" should as well. There's no reason why the first would be and not the 2nd. With the current package, calling "dspam" will work for any user, where calling "dspamc" won't, which is abnormal (for dspamc will be unable to read its config file). Here' calling dspamc will work only for the users dspam or root, or for a user which is part of the dspam group. This is unfortunate as several users need to be able to call it (MTA, MDA, Apache from the dspam web interface), plus any system user whot may need to retrain messages or learn spam/ham corpus manually.

I don't see no issue putting "dspamc" sgid dspam where "dspam" already is. We're not talking of "suid root" here, and the dspam user has no specific overall rights on the system, just the right to access its own files..

I've used dspam for years now, so I believe I know quite well how it works ;-)