nnmlserver just for nnmairix, but then you have to explicitly set the corresponding server variable
nil. Otherwise, new mail might get put into this secondary server (and would never show up again). Here’s an example server definition:
(nnml "mairix" (nnml-directory "mairix") (nnml-get-new-mail nil))
nnmaildir back end also has a server variable
get-new-mail, but its default value is
nil, so you don’t
have to explicitly set it if you use a
nnmaildir server just for
nnmairixgroups (put them in
gnus-registry-unfollowed-groups; this is the default). Be extra careful if you use
gnus-registry-split-fancy-with-parent; mails which are split into
nnmairixgroups are usually gone for good as soon as you check the group for new mail (yes, it has happened to me...).
nnmairixgroups (you shouldn’t be able to, anyway).
nnmairixgroups (though I have no idea what happens if you do).
nnmairixuses 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
nnmairixcould delete other mail groups than its own, but anyway: you really should have a backup of your mail folders.
nnmairixgroup, it is gone for good.
nnmairixgroups, 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
nnmairixgroups by changing the variable
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.