If the user wants to use a local socket then one should edit /etc/clamd.conf: LocalSocket /var/amavis/clamd.sock otherwise the following error will appear in clamd's log and the daemon will die: ERROR: Socket file /var/run/clamav/clamd.sock could not be bound: Permission denied Also, the guide says to add this to clamd.conf: PidFile /var/run/amavis/clamd.pid but it should be: PidFile /var/amavis/clamd.pid otherwise the clamd log will report: ERROR: Can't save PID in file /var/run/amavis/clamd.pid Reproducible: Always
CCing the author for some feedback on the report.
Also clamav's socket name in amavisd.conf must be like the one specified by LocalSocket in clamd.conf. So Code Listing 2.12 (Modifying /etc/amavisd.conf) should show something like: ['ClamAV-clamd', \&ask_daemon, ["CONTSCAN {}\n", "/var/amavis/clamd.sock"],
/var/amavis/virusmails doesn't seem to be used or should be specified how to(by default /var/amavis/quarantine is used instead).
I've been meaning to update the guide for long time now. In general clamd should either be running as the clamav user and place it's socket and pid file in /var/run/clamav or it should run with amavis permissions and put the files in /var/amavis/ >If the user wants to use a local socket then one should edit /etc/clamd.conf: >LocalSocket /var/amavis/clamd.sock >otherwise the following error will appear in clamd's log and the daemon will >die: >ERROR: Socket file /var/run/clamav/clamd.sock could not be bound: Permission >denied The guide already says to change the socket to: LocalSocket /var/amavis/clamd It appears that the LocalSocket option was set to /var/run/clamav/clamd.sock. >PidFile /var/run/amavis/clamd.pid >but it should be: >PidFile /var/amavis/clamd.pid Agreed. putting the clamd pid file in /var/amavis is cleaner than /var/run/amavis/ As for comment #2 I think the clamd part of amavisd.conf is fine. I'm going to build another anti spam box soon so I'll try to update most of the guide soon.
(In reply to comment #4) > The guide already says to change the socket to: > LocalSocket /var/amavis/clamd You're right. My bad. I overlooked that... So that part is fine. Also, it appears that the latest clamav releases have the following options already set by default: ScanMail ScanArchive They could be removed to make it tidier although it doesn't hurt to leave them there. While you setup a new mailfiltering box maybe you could also include RBL lookup stuff. For example, one thing I'm not really sure of is whether RBL lookups should be performed before or after graylisting. So my smtpd_recipient_restrictions looks like this: permit_mynetworks, reject_unauth_destination, reject_unknown_client_hostname, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client combined.njabl.org, reject_rhsbl_client blackhole.securitysage.com, reject_rhsbl_sender blackhole.securitysage.com, check_policy_service inet:127.0.0.1:2501 # SQLgrey On another Gentoo box I have a qmail system where greylisting is performed before RBL lookups. Maybe this is a better approach because it could save Internet bandwidth. It would be nice if you could study that too and compile it into the guide. ;-) Thanks.
Thx for the feedback. I would probably do the RBL checks with policyd-weight as mails can be rejected before being accepted by Postfix. Then I would greylist with policyd before finally running mails through amavisd-new. I don't wether running qmail give you the same range of options.
(In reply to comment #6) > do the RBL checks with policyd-weight Then greylist with policyd Sounds good. > I don't wether running qmail give you the same range of options. qmail is quite powerful but isn't that easily extensible. I'm gradually moving to postfix and/or exim but I guess I'll end up having all three on different MX hosts.
...so, what exactly should be changed? jaervosz?
We'll have to mark this as CANTFIX or LATER or some other variation if this times out any more. Any news?
(In reply to comment #9) > We'll have to mark this as CANTFIX or LATER or some other variation if this > times out any more. Any news? I don't see the need to close valid bug with a bit unclear solution as LATER.
(In reply to comment #10) > I don't see the need to close valid bug with a bit unclear solution as LATER. It's been two months since it was open, and there's no solution in sight. jaervosz, does anything *really* need to happen for this bug? Also, can we get an ETA for the other changes you said you'd be working on?
Sorry for my lack of action on this one. I still plan to clean up the guide as soon as possible, but I don't believe this to be a bug per se. So I think it can be safely closed.
(In reply to comment #12) > Sorry for my lack of action on this one. I still plan to clean up the guide as > soon as possible, but I don't believe this to be a bug per se. So I think it > can be safely closed. Okay. When you've got some patches ready for us, feel free to reopen this bug or create a new one with your improvements for the guide.
