In http://wiki.centos.org/HowTos/Amavisd
there is a recommendation to NOT use the version that comes with Centos 6.3, but to get the more current version from RPMForge.
Is this the 'correct' thing to do on a Centos-based mail server?
On 04/01/13 15:59, Robert Moskowitz wrote:
In http://wiki.centos.org/HowTos/Amavisd
there is a recommendation to NOT use the version that comes with Centos 6.3, but to get the more current version from RPMForge.
Is this the 'correct' thing to do on a Centos-based mail server?
There is no "correct" thing to do or not to do - it's simply a recommendation (BTW, I wrote the guide).
It's a recommendation based on the fact that Red Hat can be slow to update the SpamAssassin package so the version in rpmforge is invariably more likely to be current.
Take now as an example, the distro version is 3.3.1 and rpmforge has the current 3.3.2 version in their extras repository. The changelog shows SA was updated to 3.2.2 on Wed Jun 22 2011 by rpmforge so at this point in time upstream (Red Hat) is at least 18 months behind.
Based on the above information, hopefully you can make an informed choice that is right for you.
Hope that helps.
On 01/04/2013 11:53 AM, Ned Slider wrote:
On 04/01/13 15:59, Robert Moskowitz wrote:
In http://wiki.centos.org/HowTos/Amavisd
there is a recommendation to NOT use the version that comes with Centos 6.3, but to get the more current version from RPMForge.
Is this the 'correct' thing to do on a Centos-based mail server?
There is no "correct" thing to do or not to do - it's simply a recommendation (BTW, I wrote the guide).
It's a recommendation based on the fact that Red Hat can be slow to update the SpamAssassin package so the version in rpmforge is invariably more likely to be current.
Take now as an example, the distro version is 3.3.1 and rpmforge has the current 3.3.2 version in their extras repository. The changelog shows SA was updated to 3.2.2 on Wed Jun 22 2011 by rpmforge so at this point in time upstream (Red Hat) is at least 18 months behind.
Based on the above information, hopefully you can make an informed choice that is right for you.
Hope that helps.
I have been looking at the same issue WRT Postfix. There the differences are probably greater between what is available in source and what is in 6.3. But I need to resist going with source building, as then I have to spend more time than I have staying up with fixes. I want an RPM repo to fit into the YUM process.
I guess I need some good information on what is reasonable to replace and how to initially build a system via kickstart with the 'best' rpms.
BTW, I have started this effort following:
http://www.campworld.net/thewiki/pmwiki.php/LinuxServersCentOS/Cent6VirtMail...
Correcting things as I go.
On 04.01.2013 17:12, Robert Moskowitz wrote:
I have been looking at the same issue WRT Postfix. There the differences are probably greater between what is available in source and what is in 6.3. But I need to resist going with source building, as then I have to spend more time than I have staying up with fixes. I want an RPM repo to fit into the YUM process.
Very good. Newest != best. :) It's likely that if you have a problem or you're getting too much spam is not primarily because the package is slightly old. In my case the secret was to "train" it, feed it new spam regularly. Currently my stock SpamAssassin protected Inbox gets less spam than my gmail account and they're both getting similar levels of traffic.
BTW, I have started this effort following:
http://www.campworld.net/thewiki/pmwiki.php/LinuxServersCentOS/Cent6VirtMail...
I would have loved that some years ago. Nowadays I just use system users and webmin to manage them (or just some scripts).
On Fri, Jan 4, 2013 at 12:05 PM, Nux! nux@li.nux.ro wrote:
what is in 6.3. But I need to resist going with source building, as
then I have to spend more time than I have staying up with fixes. I want an RPM repo to fit into the YUM process.
BTW, I have started this effort following:
http://www.campworld.net/thewiki/pmwiki.php/LinuxServersCentOS/Cent6VirtMail...
I would have loved that some years ago. Nowadays I just use system users and webmin to manage them (or just some scripts).
If you only have system users you could probably get by with ClearOS or SMEserver and never have to deal directly with anything but the web interface.
On 01/04/2013 11:53 AM, Ned Slider wrote:
On 04/01/13 15:59, Robert Moskowitz wrote:
In http://wiki.centos.org/HowTos/Amavisd
there is a recommendation to NOT use the version that comes with Centos 6.3, but to get the more current version from RPMForge.
Is this the 'correct' thing to do on a Centos-based mail server?
There is no "correct" thing to do or not to do - it's simply a recommendation (BTW, I wrote the guide).
I am working some more off your guide.
What is clamav-devel need for?
In the userid check:
# cat /etc/passwd | grep "amavis|clamav"
I get the clamav userid as clam, not clamav. Same way with the group being clam, not clamav and neither are added to the amavis group. So what to do? Am I doing something wrong or has clamav changed so that your howto needs updating?
On 01/10/2013 03:10 PM, Robert Moskowitz wrote:
On 01/04/2013 11:53 AM, Ned Slider wrote:
On 04/01/13 15:59, Robert Moskowitz wrote:
In http://wiki.centos.org/HowTos/Amavisd
there is a recommendation to NOT use the version that comes with Centos 6.3, but to get the more current version from RPMForge.
Is this the 'correct' thing to do on a Centos-based mail server?
There is no "correct" thing to do or not to do - it's simply a recommendation (BTW, I wrote the guide).
I am working some more off your guide.
What is clamav-devel need for?
In the userid check:
# cat /etc/passwd | grep "amavis|clamav"
I get the clamav userid as clam, not clamav. Same way with the group being clam, not clamav and neither are added to the amavis group. So what to do? Am I doing something wrong or has clamav changed so that your howto needs updating?
The clamd and amavisd services are installed off, and have to be enabled with chkconfig ... on.
Oh, also, there is a clamd.amavisd service. Should that be set to on?