Traditional mail readers have a tendency to remove mail articles when you mark them as read, in some way. Gnus takes a fundamentally different approach to mail reading.
Gnus basically considers mail just to be news that has been received in a rather peculiar manner. It does not think that it has the power to actually change the mail, or delete any mail messages. If you enter a mail group, and mark articles as “read”, or kill them in some other fashion, the mail articles will still exist on the system. I repeat: Gnus will not delete your old, read mail. Unless you ask it to, of course.
To make Gnus get rid of your unwanted mail, you have to mark the articles as expirable. (With the default key bindings, this means that you have to type E.) This does not mean that the articles will disappear right away, however. In general, a mail article will be deleted from your system if, 1) it is marked as expirable, AND 2) it is more than one week old. If you do not mark an article as expirable, it will remain on your system until hell freezes over. This bears repeating one more time, with some spurious capitalizations: IF you do NOT mark articles as EXPIRABLE, Gnus will NEVER delete those ARTICLES.
You do not have to mark articles as expirable by hand. Gnus provides
two features, called “auto-expire” and “total-expire”, that can help you
with this. In a nutshell, “auto-expire” means that Gnus hits E
for you when you select an article. And “total-expire” means that Gnus
considers all articles as expirable that are read. So, in addition to
the articles marked ‘E’, also the articles marked ‘r’,
‘R’, ‘O’, ‘K’, ‘Y’ (and so on) are considered
expirable. gnus-auto-expirable-marks
has the full list of
these marks.
When should either auto-expire or total-expire be used? Most people who are subscribed to mailing lists split each list into its own group and then turn on auto-expire or total-expire for those groups. (See Splitting Mail, for more information on splitting each list into its own group.)
Which one is better, auto-expire or total-expire? It’s not easy to answer. Generally speaking, auto-expire is probably faster. Another advantage of auto-expire is that you get more marks to work with: for the articles that are supposed to stick around, you can still choose between tick and dormant and read marks. But with total-expire, you only have dormant and ticked to choose from. The advantage of total-expire is that it works well with adaptive scoring (see Adaptive Scoring). Auto-expire works with normal scoring but not with adaptive scoring.
Groups that match the regular expression
gnus-auto-expirable-newsgroups
will have all articles that you
read marked as expirable automatically. All articles marked as
expirable have an ‘E’ in the first column in the summary buffer.
By default, if you have auto expiry switched on, Gnus will mark all the articles you read as expirable, no matter if they were read or unread before. To avoid having articles marked as read marked as expirable automatically, you can put something like the following in your ~/.gnus.el file:
(remove-hook 'gnus-mark-article-hook 'gnus-summary-mark-read-and-unread-as-read) (add-hook 'gnus-mark-article-hook 'gnus-summary-mark-unread-as-read)
Note that making a group auto-expirable doesn’t mean that all read articles are expired—only the articles marked as expirable will be expired. Also note that using the d command won’t make articles expirable—only semi-automatic marking of articles as read will mark the articles as expirable in auto-expirable groups.
Let’s say you subscribe to a couple of mailing lists, and you want the articles you have read to disappear after a while:
(setq gnus-auto-expirable-newsgroups "mail.nonsense-list\\|mail.nice-list")
Another way to have auto-expiry happen is to have the element
auto-expire
in the group parameters of the group.
If you use adaptive scoring (see Adaptive Scoring) and auto-expiring, you’ll have problems. Auto-expiring and adaptive scoring don’t really mix very well.
The nnmail-expiry-wait
variable supplies the default time an
expirable article has to live. The value of this variable can be
either a number of days (not necessarily an integer), or one of the
symbols immediate
or never
, meaning an article is
immediately or never expirable, respectively.
Gnus starts counting days from when the message arrived, not from when it was sent. The default is seven days.
The nnmail-expiry-wait-function
variable lets you fine-tune how
long articles are to live, based on what group they are in. When set
to a function, its returned value, if non-nil
, overrides that
of nnmail-expiry-wait
. Otherwise, the value of
nnmail-expiry-wait
is used instead.
For example, let’s say you want to have a one month expiry period in the ‘mail.private’ group, a one day expiry period in the ‘mail.junk’ group, and a six day expiry period everywhere else. This can be achieved as follows:
(setq nnmail-expiry-wait-function (lambda (group) (cond ((string= group "mail.private") 31) ((string= group "mail.junk") 1) ((string= group "important") 'never) (t 6))))
The group names this function is fed are “unadorned” group names—no ‘nnml:’ prefixes and the like.
As an alternative to the variables nnmail-expiry-wait
or
nnmail-expiry-wait-function
, you can also use the
expiry-wait
group parameter to selectively change the expiry
period (see Group Parameters).
The normal action taken when expiring articles is to delete them.
However, in some circumstances it might make more sense to move them
to other groups instead of deleting them. The variable
nnmail-expiry-target
(and the expiry-target
group
parameter) controls this. The variable supplies a default value for
all groups, which can be overridden for specific groups by the group
parameter. default value is delete
, but this can also be a
string (which should be the name of the group the message should be
moved to), or a function (which will be called in a buffer narrowed to
the message in question, and with the name of the group being moved
from as its parameter) which should return a target—either a group
name or delete
.
Here’s an example for specifying a group name:
(setq nnmail-expiry-target "nnml:expired")
Gnus provides a function nnmail-fancy-expiry-target
which will
expire mail to groups according to the variable
nnmail-fancy-expiry-targets
. Here’s an example:
(setq nnmail-expiry-target 'nnmail-fancy-expiry-target nnmail-fancy-expiry-targets '((to-from "boss" "nnfolder:Work") ("subject" "IMPORTANT" "nnfolder:IMPORTANT.%Y.%b") ("from" ".*" "nnfolder:Archive-%Y")))
With this setup, any mail that has IMPORTANT
in its Subject
header and was sent in the year YYYY
and month MMM
, will
get expired to the group nnfolder:IMPORTANT.YYYY.MMM
. If its
From or To header contains the string boss
, it will get expired
to nnfolder:Work
. All other mail will get expired to
nnfolder:Archive-YYYY
.
If nnmail-keep-last-article
is non-nil
, Gnus will never
expire the final article in a mail newsgroup. This is to make life
easier for procmail users.
By the way: That line up there, about Gnus never expiring non-expirable
articles, is a lie. If you put total-expire
in the group
parameters, articles will not be marked as expirable, but all read
articles will be put through the expiry process. Use with extreme
caution. Even more dangerous is the
gnus-total-expirable-newsgroups
variable. All groups that match
this regexp will have all read articles put through the expiry process,
which means that all old mail articles in the groups in question
will be deleted after a while. Use with extreme caution, and don’t come
crying to me when you discover that the regexp you used matched the
wrong group and all your important mail has disappeared. Be a
man! Or a woman! Whatever you feel more comfortable
with! So there!
Most people make most of their mail groups total-expirable, though.
If gnus-inhibit-user-auto-expire
is non-nil
, user marking
commands will not mark an article as expirable, even if the group has
auto-expire turned on.
The expirable marks of articles will be removed when copying or moving
them to a group in which auto-expire is not turned on. This is for
preventing articles from being expired unintentionally. On the other
hand, to a group that has turned auto-expire on, the expirable marks of
articles that are copied or moved will not be changed by default. I.e.,
when copying or moving to such a group, articles that were expirable
will be left expirable and ones that were not expirable will not be
marked as expirable. So, even though in auto-expire groups, some
articles will never get expired (unless you read them again). If you
don’t side with that behavior that unexpirable articles may be mixed
into auto-expire groups, you can set
gnus-mark-copied-or-moved-articles-as-expirable
to a
non-nil
value. In that case, articles that have been read will
be marked as expirable automatically when being copied or moved to a
group that has auto-expire turned on. The default value is nil
.