2.18.2.9 nnmairix caveats

• If you use the Gnus agent (see section 6.9 Gnus Unplugged): don't agentize nnmairix groups (though I have no idea what happens if you do).

• If you use the Gnus registry: don't use the registry with nnmairix groups (put them in gnus-registry-unfollowed-groups). Be extra careful if you use gnus-registry-split-fancy-with-parent; mails which are split into nnmairix groups are usually gone for good as soon as you check the group for new mail (yes, it has happened to me...).

• Therefore: Never ever put "real" mails into nnmairix groups (you shouldn't be able to, anyway).

• mairix does only support us-ascii characters.

• nnmairix uses a rather brute force method to force Gnus to completely reread the group on the mail back end after mairix was called--it simply deletes and re-creates the group on the mail back end. So far, this has worked for me without any problems, and I don't see how nnmairix could delete other mail groups than its own, but anyway: you really should have a backup of your mail folders.

• All necessary information is stored in the group parameters (see section 2.10 Group Parameters). This has the advantage that no active file is needed, but also implies that when you kill a nnmairix group, it is gone for good.

• If you create and kill a lot of nnmairix groups, the "zz_mairix-*" groups will accumulate on the mail back end server. To delete old groups which are no longer needed, call nnmairix-purge-old-groups. Note that this assumes that you don't save any "real" mail in folders of the form zz_mairix-<NAME>-<NUMBER>. You can change the prefix of nnmairix groups by changing the variable nnmairix-group-prefix.

• The following only applies if you don't use the mentioned patch for mairix (see section 2.18.2.7 Propagating marks):

  A problem can occur when using nnmairix with maildir folders and comes with the fact that maildir stores mail flags like `Seen' or `Replied' by appending chars `S' and `R' to the message file name, respectively. This implies that currently you would have to update the mairix database not only when new mail arrives, but also when mail flags are changing. The same applies to new mails which are indexed while they are still in the `new' folder but then get moved to `cur' when Gnus has seen the mail. If you don't update the database after this has happened, a mairix query can lead to symlinks pointing to non-existing files. In Gnus, these messages will usually appear with "(none)" entries in the header and can't be accessed. If this happens to you, using G b u and updating the group will usually fix this.