Extensions

How To Support Additional Languages

By default, MailArchiva can handle the indexing and search of emails in English Brazillian, Chinese, Czech, German, Greek, French, Dutch, Russian, Korean, Japanese, and Thai. If your language is not listed, do not worry, for MailArchiva can easily be extended to support additional languages.

MailArchiva uses Lucene as its underlying search engine. To support additional languages, you need find an Lucene Analyzer for your target language. Once you have found your analyzer, download the JAR file and place in c:\Program Files\MailArchiva\server\webapps\ROOT\WEB-INF\lib or /usr/local/mailarchiva/server/webapps/ROOT/WEB-INF/lib. Next, you need to add the following to your server.conf file:

search.analyzer.language.1=[countrycode]

search.analyzer.class.1 = [full class name]

For example, to support Spanish, you would need to download the Lucene Snowball analyzer from here. Install the JAR file as described above. Add the following to your server conf file:

search.analyzer.language.1=es

search.analyzer.class.1=org.apache.lucene.analysis.snowball.SnowballAnalyzer

Now if you want to set Spanish as your default language, change the following property in server.conf:

index.language=es

If you want to force MailArchiva to index emails in Spanish and disable auto language detection, you can set language detection to no:

index.language.detect = no

Now, to translate the MailArchiva user interface, you need create a new application.properties file. Edit the properties file /usr/local/mailarchiva/server/webapps/ROOT/WEB-INF/classes/properties/application.properties and save as application_es.properties. If you want special accent characters to show up, you need to convert the application_es.properties to ASCII using the Java utility native2ascii (available in the Java Development Kit)

To translate MailArchiva to Spanish, please rename application.properties to application_es.properties and insert the translations. Thereafter, copy the file to /usr/local/mailarchiva/server/webapps/ROOT/WEB-INF/classes/properties, restart MailArchiva and send your Browser language to spanish. You should see the spanish translations appear.

The Snowball analyzer is capable of supporting French, Spanish, Portuguese, Italian, Romanian, German, Dutch, Swedish, Norwegian, Danish, Russian, Finnish, Hungarian and Turkish languages.

How to do LDAP Authentication with Open Source Edition

Note: The Enterprise Edition now supports basic LDAP authentication with LDAP repositories such as OpenLDAP?

We have a Linux PDC that uses LDAP to store user information, including samba groups, SIDs, etc. We have not deployed Kerberos for every service, but from my AD days, I am passingly familiar. With this setup, there is no objectClass: user or sAMAccountName attribute.

Mailarchiva's LDAP lookup mechanism requires three (well, four) things from your setup (at least, it seems this way to me as I wasn't able to coerce it into working any other way. Please feel free to correct me):

1) Kerberized LDAP 2) Each user to be looked up must have a sAMAccountName attribute 3) Each user to be looked up must have an objectClass of user (not necessarily the Structural object class, just an objectClass of user). 4) mail attributes (or whatever you choose to use to store your user's email address).

Since our LDAP was already set up as described in the first paragraph, I just needed to march down the list and set each piece up accordingly.

1) I used MIT Kerberos v5. I set up a KDC and added principals for each user, as well as a host principal to get the ticket-granting-ticket to access LDAP.

2 and 3) I created a new schema for OpenLDAP? that had a user objectClass. This objectClass had to be marked as AUXILIARY instead of STRUCTURAL due to the fact that inetOrgPerson was STRUCTURAL in my org, and each user can only have one STRUCTURAL objectClass in OpenLDAP?. Next, I added an attribute named sAMAccountName that was EQUIVALENT to uid (username in our org), and was a MAY in the user objectClass.

4) I created an LDIF that added the objectClass and atrribute to each user in the system, and added secondary email addresses (if necessary).

Ta-da! It works! I can point to URLs to get someone started if they like. The only downside is that our Kerberos passwords and LDAP passwords are not in sync, so I have to assign passwords for each user (at least I know they are strong!). If anyone knows how to change that last piece, I am very anxious to know.

Thanks, and hope this helps. -Nick