Having just joined the Zimbra forums, I would like to express my sincere appreciation for the information available here. It got me through the intial difficulties in understanding some of the tricky/obscure issues related to getting Zimbra running smoothly and cleanly. It's now up and running well on CentOS under VMWare. My thanks to the members, and to the Zimbra employees who so generously offer their advice.
I have a question or two (or three...) related to spam training. Searching the forums has not produced anything I can use so far, but I may have overlooked something ... flames are ok, I'm still on the steep part of the learning curve
The folks I'm supporting are Outlook and Thunderbird users (me included) who wish to continue using those tools rather than switching to the Zimbra web interface. We all monitor multiple IMAP servers which the web client is not designed to do.
I'd like to make it as easy as possible for users to train the spam filter, so my current work-around is to create special folders in each user's mailbox clearly labeled for spam and ham training. The users simply drag messages into either of these folders, and a script runs each night to invoke 'zmtrainsa' against the folders. This seems like the most intuitive way to do it, involving the least effort on the part of the users and offering a relatively MUA-independent method.
However, there are problems with this. Whenever a user changes his/her password in Zimbra, I have to ask them for it and edit the training script. This exposes passwords not only in the script but also in the Zimbra log file, something I would really rather not do. Some trusted users have root privileges and are free to review log files.
The LDAP server stores these passwords in SSHA format, but of course fetchmail can't deal with them when passed in via the zmtrainsa script. Is there any possibility that future versions of zmtrainsa can be modified to query the LDAP database (if, and only if, run as userid 'zimbra') in order to avoid admin hassles with passwords? Can the password string sent to fetchmail be suppressed/obscured in the log files?
Failing this, other suggestions for making it trivially easy for Outlook/Thunderbird users to invoke spam/ham training would be most welcome. Forwarding spam or ham messages to the special training account mailboxes is not so intuitive, and most users would quickly tire of it. A button-click or drag-and-drop method is much preferred.
Many thanks!
Chuck