ClamAV and SpamAssassin

[EnglishDude]

Hello all,

Do I need ClamAV and SpamAssassin installed on the server for Zimbra to use, or is it already included in the package so I can remove ClamAV and SpamAssassin safely?

Thanks very much for your help in advance!

[Klug]

Originally Posted by EnglishDude

Do I need ClamAV and SpamAssassin installed on the server for Zimbra to use, or is it already included in the package so I can remove ClamAV and SpamAssassin safely?

It's included in the Zimbra package and was installed if you installed the "MTA" part on the server.

But you'll need to activate them in the admin webUI.
Check here : Anti-Spam Protection

[EnglishDude]

Thanks very much for your prompt reply!

It's just that I'm putting Zimbra on a server with ClamAV and Spamassassin already installed - so the obvious answer here is to remove ClamAV and SpamAssassin as it's already part of the Zimbra package.

Thanks very much for your help again.

[uxbod]

Hmmm, so can you install just the Zimbra server and web client without all the MTA pieces ? I would prefer to handle Postfix etc myself so that I can perform upgrades etc of SpamAssassin.

I see from the trunk that Postfix 2.2.9 is used where the latest is 2.3.4 so how does Zimbra handle upgrades to the MTA and associated packages? Are these performed independently of the Zimbra server?

Thanks,

[Klug]

Originally Posted by uxbod

Hmmm, so can you install just the Zimbra server and web client without all the MTA pieces ? I would prefer to handle Postfix etc myself so that I can perform upgrades etc of SpamAssassin.

You can setup the whole Zimbra and still upgrade SA by hand...

But if you do this, you loose the whole idea of "all in one" package, with spam/ham learning and co.

[uxbod]

I do agree with the concept of an all in one, as long as each package is regularly kept up to date. As I have said, Postfix is already a couple of revisions behind, and I like to ensure that I have the most upto date with any security fixes.

[martinfst]

I wonder whether there exists a roadmap to stay tuned with "package" upgrades. It's nice, Zimbra has all packages bundled together, but continuous improvements are regularly done to e.g. Postfix, SpamAssassin, etc. Specifically the spam war between those who sent spam versus the ones receiving (and not wanting spam) requires an active update policy.

Now, with 4.0.4 SpamAssassin is at 3.1.5 but 2.1.7 is already released 2006-10-10. That's almost two months ago.

And if you upgrade, where do you store/need top store the package? Use CPAN? Use the .deb, .rpm or whatever? My bet would be start from source and modify Makefiles accordingly. Zimbra stores the packages at non-standard locations (e.g. /opt/zimbra/zimbramon/lib/Mail/SpamAssassin.pm). How do we find out where to store what? Another observation I had, is that (on clean Ubuntu server install), SpamAssassin does not give an error, but it does miss the Digest::SHA1 package (and some others as well). Bundled suites like Zimbra do take a lot of effort to stay in sync with the upstream developers. Being behind a 1-2 releases is to be expected.

[uxbod]

Then Zimbra should be more modular. As long as the configuration ie. paths is consistent with where Zimbra expects them to be then there should be no reason why SA, DSPAM, Postfix etc need to be bundled with the package. By all means release a one stop package, but also allow the flexibility. I would imagine more people taking it up if this was the case. That way more emphasis can be put on releasing a 64bit version of Zimbra, and let others worry about building the MTA side of things.