Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run spamassassin with vmail user #200

Merged
merged 1 commit into from
May 7, 2017
Merged

Conversation

Udera
Copy link
Collaborator

@Udera Udera commented Aug 17, 2016

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?

@Udera Udera added this to the Version 2.3.1 milestone Aug 17, 2016
@rimas-kudelis
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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.

@@ -31,14 +31,14 @@
# Reject mails with more than 15 spam-points. This is a system-wide setting and does not respect
# individual user settings!
#deny message = This message has been rejected due to spam.
# spam = maildeliver:true
# spam = vmail:true
# condition = ${if >{$spam_score_int}{150}{true}{false}}

# Always add X-Spam-Score and X-Spam-Report headers, using SA system-wide settings
# (user "nobody"), no matter if over threshold or not.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interestingly, this line mentions 'nobody', this must be a mistake.
But we may want to use 'nobody' in non-packaged vexim versions.

@Udera
Copy link
Collaborator Author

Udera commented Aug 18, 2016

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
Copy link
Collaborator

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
Copy link
Collaborator Author

Udera commented Aug 18, 2016

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
Copy link
Collaborator

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
Copy link
Collaborator Author

Udera commented Aug 18, 2016

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
Copy link
Collaborator

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 Udera self-assigned this Sep 17, 2016
@Udera Udera force-pushed the sauser branch 2 times, most recently from 5c81bbf to 4860339 Compare April 15, 2017 23:17
@Udera
Copy link
Collaborator Author

Udera commented Apr 15, 2017

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
Copy link
Collaborator

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

@Udera
Copy link
Collaborator Author

Udera commented Apr 17, 2017

What do you mean with macro?

@rimas-kudelis
Copy link
Collaborator

rimas-kudelis commented Apr 17, 2017

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
Copy link
Collaborator Author

Udera commented Apr 17, 2017

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
Copy link
Collaborator Author

Udera commented May 1, 2017

done :D

@rimas-kudelis rimas-kudelis merged commit c5697c2 into vexim:master May 7, 2017
@Udera Udera deleted the sauser branch June 30, 2017 22:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants