Lemon Jelly – Ramblin’ Man
I have been quite busy lately working with the Zimbra platform – trying to figure out a path to upgrade our existing infrastructure at work (OpenLDAP, Postfix, Mailman, SquirrelMail, SpamAssassin, Amavis, Mailzu etc) and the more I look at it, learn about it and work with it, the more I believe that it’s do-able. And the more excited I get about Zimbra as I learn about the capabilities that aren’t on the tin.
Our current setup has three DMZ’d MTA mail relays, which is our edge platform with SpamAssassin, Amavis, Mailzu and ClamAV. Ideally we would keep these in place, as there’s years of Antispam training there, and we’re this close to having Mailzu integrated into our Drupal intranet.
Therefore, we’d be running Zimbra in a pooled mailhosts configuration. The main issue then is integration with our existing OpenLDAP directory. There are two main schools of thought about how to do this:
1) Keep the directories seperate and map changes between the two with a cron’d script, or use filtered replication in syncrepl
2) Merge the directories, running an OpenLDAP based master with the Zimbra mailhosts running as slaves.
Personally I’m in favour of Merging the directories, however this might require some tweaks to the Zimbra LDAP configuration – and who knows what might happen as a result. This shouldn’t be overly hard though: Make sure the standard OpenLDAP schemas are the same, load in the Zimbra schemas and profit. The differences between standard OpenLDAP and Zimbra OpenLDAP are so far apart that the two could be merged into the same directory with little fuss – Zimbra essentially sticks to its own branch, and with the Zimbra schemas it’s a matter of mapping/replicating attributes from one branch to another.
There is a potential third option in MMR with syncrepl that should possibly be investigated.
There’s some exciting RFE’s in the Zimbra bugzilla db though, including this one, where marking a message as junk in your mail client will automagically train SpamAssassin, there is a cron script workaround too. This is excellent because it no longer requires the user to manually forward spam to firstname.lastname@example.org – it’s completely transparent to the end user, which is how systems should be IMHO. My interest, however, is in how to replicate the SpamAssassin training between our existing MTA layer and a potential Zimbra mailhost layer. So anything that gets through our current antispam is marked at the user level, the mailhosts learn and this replicates upwards to the MTA’s – all transparent to the user!
Needless to say, this is a pretty fun challenge 🙂