nnml
server just for nnmairix, but then
you have to explicitly set the corresponding server variable
nnml-get-new-mail
to 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))
(The 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
mairix.)
nnmairix
groups (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 nnmairix
groups are usually gone for good as soon as you
check the group for new mail (yes, it has happened to me...).
nnmairix
groups (you shouldn’t be able to, anyway).
nnmairix
groups (though I have no idea what happens if you do).
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.
nnmairix
group,
it is gone for good.
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
.
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.