Run spamassassin with vmail user

[Udera]

I always run my spamassassin with the vexim user. This way all the .spamassassin training files, special configuration, ... is within the home-folder of the vexim-user.

Does it make sense to take the exim-user?

[rimas-kudelis]

One thing I really dislike about Exim is how it's configuration files are anything but self-explanatory (unless perhaps you've graduated some Exim college or something). After I updated my Exim/Vexim setup yesterday, I just copied these ACL files verbatim and didn't change much. Now I see why I get all these messages about spamd not being able to find the maildeliver user in mail.log. Because of this! I'm not sure whom to run this under, it could be the vexim user as far as I'm concerned, I don't see why this would be a bad idea, although I'm not an expert. But unless we can be reasonably sure that the user will exist in target machine, I think we should at least document these options properly.

For the reference, Debian has a commented out block in it's default configuration, which specifies to run SA as Debian-exim, but then the comment above that block explicitly states that it's not a very good idea.

[rimas-kudelis]

Actually, I'd probably default to nobody instead. This will make SA scan as the default user. Since these ACL blocks aren't really specific to virtual domains, why should we let SA run as our virtual email owner?

[rimas-kudelis]

On the other hand, running as nobody (whose home directory does not exist, at least in Debian) prevents spamassassin from creating its settings file. It seems that in Debian, the debian-spamd user would be the correct choice: this user's home directory already contains a .spamassassin subdir, and it seems to be designed specifically for this purpose.

[Udera]

The best is probably to use a dedicated user for this, like debian uses debian-spamd. Perhaps we should create our own spamassassin user? vexim-spamd or vmail-spamd?

[rimas-kudelis]

I don't think there's point in that. We don't really care about the settings, since we're using settings from the database. I think nobody is good enough, in the absence of a better pre-existing choice (e.g. debian-spamd, although I'm not so sure about that one). The only reason why I think debian-spamd is better than nobody in Debian is that nobody clutters logs due to a non-existing homedir.

[Udera]

Only the points for each user are in the database. If you use your own rules, modify the points for some rules, add some features (more blacklists, whitelisting of know addresses, ...). All this is done in the spamassassin-folder of the system-user running spamassassin. Some of this could perhaps be moved into a database as well.

[rimas-kudelis]

This (rule and score modifications) sounds to me like somewhat more advanced usage. If someone's going this far, they probably know what they're doing and how to set up a new user for Spamassassin. At least IMO.

[Udera]

And it is needed for the bayes-filter (which must be trained). the problem is more, that we haven't well documented the installation and configuration of spamassassin (compared to http://axel.sjostedt.no/misc/dev/vexim-customizations/).

[rimas-kudelis]

Our user name per the installation manual is vexim, not vmail. Also, it would be great to edit the comments above these definitions to clearly say that vexim is the user name under which spam checks are to be performed, and maybe add a URL there pointing to more info. spam = maildeliver:true was particularly ambiguous for those who haven't read and memorised the Exim spec. Vith vexim, this will be more obvious, but a comment wouldn't hurt. Also, please rebase.

[Udera]

I rebased this PR and made some changes. You already added some more comments before. If you think this PR is not required any more, feel free to close this PR.

[rimas-kudelis]

Huh, maybe we should put that username in a macro? :)

[Udera]

What do you mean with macro?

[rimas-kudelis]

I meant

VEXIM_SA_USERNAME = vexim

in the master file and

warn  spam                     = VEXIM_SA_USERNAME:true

here. Not sure how much sense this makes, considering that it is defined in a separate file. What do you think?

[Udera]

There is only one appearance of it. One huge advantage would be that we can keep all settings at a small spot. This will make updates much easier to implement...

[Udera]

done :D