Failed to Retrieve Message

When opening emails, you may receive the error "failed to retrieve requested message". If this is the case, you need to check the debug.log file for a more detailed explanation as to why this is occurring. Below are some hints on how to resolve this problem. Really, if you take a look at the debug log immediately after clicking on a message, you should see the specific error in question. If there is any doubt, send the log error to us and we will advise you as to what might be the happening.

In most cases, you can troubleshoot the problem yourself as it is likely due one of the following:

Mismatched Volume ID

Each message in the index has a volume ID associated with it. This is used by Mailarchiva to lookup the volume where the message can be found. The corresponding volume ID of the volume is found in a file called volumeinfo on the root of the store path. The volume info will contain something like:
 

The volume id in the index must match the id in the volume info file. If it does not, the message "failed to retrieve requested message" will be outputted when viewing the message.

Overlapping Volume ID's

In very early versions of MailArchiva, there was a bug that caused the volumeid's across multiple volumes to be the same. When volume ids are the same across multiple volumes, when a message is opened MailArchiva has the potential to look in the wrong volume. Consequently, an internal "file not found" error occurred internally and the message "failed to retrieve requested message" is outputted. The way to resolve this is edit each of your volumeinfo files on the root path of your store directory and manually change the id of an overlapping volumeid. You merely need to change one or two characters to something random. e.g. id:9fba18d6-cf0e-4db1-b4b8-4751f352fc73 to id:9fba18d6-cf0e-4db1-b4b8-4751f352fcab and then reindex the volume whose id you changed.
Index and Store Do Not Belong Together#

Perhaps, when importing an old volume, you specified using the wrong store with the wrong index. In this case, the volumeid's in the index will not correlate since a needed volume may not be imported.

Encryption Parameters Incorrect

If an email was encrypted using a different encryption password, salt or encryption algorithm, MailArchiva may not be able to read the message and will produce the error "failed to retrieve requested message". If this is the case, when you open the message you should get an error like "not in GZIP format" or something similar appear in the mailarchiva_debug.log file. Are the emails where this occurring isolated to a particular volume or do they occur across all volumes? Also, bear in mind, earlier versions of the OSE used DES as opposed to 3DES to encrypt messages (due crypto export restrictions). It could be that your volumes are encrypted using a different algorithm. Do not fear however, we have a utility called recrypt that is packaged with the malarchiva_utilities package that will run through your entire archive and normalize everything provided you have the correct password for the volumes in question. Once you have run the reencrypt utility, you should reindex your volume.

You're getting an error "not in gzip format" . This means that either the encryption password, salt or encryption algorithm is incorrect. There is a utility called reencrypt that can be used to reencrypt your data to a new password with standard salt and encryption algorithm settings. If you have forgotten your password but have your old server.conf file, the reencrypt utility has the option (-pe) to accept an encrypted password taken from the server.conf file.

The strategy is to reencrypt all your volume data to a new password, delete the old encryption password from MA, and reenter the new encryption password in MA.

Note 1): It is imperative that all volumes use the same new password. Note 2): If you have emails encrypted using different passwords in the same volume, simply run the reencrypt utility twice, each time with a different password.

Here are the steps to recover your data:

1) download and unpack the mailarchiva_utilities package from http://www.mailarchiva.com/downloads
2) open your (old) backed up server.conf file, find the line security.passhrase and copy the value (the bit after the equals..)
3) type "export MAILARCHIVA_HOME=/usr/local/mailarchiva"
4) run the command "/reencrypt.sh -s /store/store1 -d store/newstore1 -pe encrypted passphrase -x new passphrase"

where /store/store1 is the location of a volume's store directory and encrypted passphrase is the encryption password value obtained from your server.conf and new passphrase is your chosen passphrase.

5) The reencrypt utility will step through all messages and reencrypt them using your chosen passphrase.
6) If the password is correct, you should get see errors outputted by the reencrypt utility
7) Switch off journaling in Journal Accounts in your current server
8) Stop your current server
9) rename "/store/store1" to "/store/store1_bak"
10) rename "/store/newstore1" to "/store/store1"

11) In the server.conf of your current system (not the backup server.conf), located in /usr/local/mailarchiva/server/webapps/ROOT/WEB- INF/conf/server.conf, delete the line containing security.passhrase and save.
12) Start the server
13) login to server and enter the chosen new encryption password in the Configuration GUI
14) Reindex the volume\s in question
15) You should not get any GZIP errors and you should be able to access your data in search

Emails Do Not Exist

The error will be outputted simply if the email was not found. Perhaps, someone deleted the emails from the store or they got lost in a migration or something?

Remote Drive Inaccessible

If your volume store in on a remote drive, it could be that MailArchiva is unable to access the drive due to network problems or overloaded I/O. You may need to look at how your storage is connected. Do you have reliable IP connectivity to the NAS? If running on Linux, try switch over to another file sharing protocol (i.e. switch between NFS and CIFS). Is your storage device overloaded? It could be that the disks you are using to store information are overloaded. Is there any possibility of installing dedicated storage?