Go to the first, previous, next, last section, table of contents.

The Group Buffer

The group buffer lists all (or parts) of the available groups. It is the first buffer shown when Gnus starts, and will never be killed as long as Gnus is active.

Group Buffer Format

The default format of the group buffer is nice and dull, but you can make it as exciting and ugly as you feel like.

Here's a couple of example group lines:

     25: news.announce.newusers
 *    0: alt.fan.andrea-dworkin

Quite simple, huh?

You can see that there are 25 unread articles in `news.announce.newusers'. There are no unread articles, but some ticked articles, in `alt.fan.andrea-dworkin' (see that little asterisk at the beginning of the line?)

You can fuck that up to your heart's delight by fiddling with the gnus-group-line-format variable. This variable works along the lines of a format specification, which is pretty much the same as a printf specifications, for those of you who use (feh!) C.

In addition to the normal "padding" specs that format supports (eg. `%7d'), specifications like `%7,12s' are allowed. A spec of this type means that the field will be at least 7 characters long, and never more that 12 characters long.

The default value that produced those lines above is `"%M%S%5y: %(%g%)\n"'.

There should always be a colon on the line; the cursor always moves to the colon after performing an operation. Nothing else is required - not even the group name. All displayed text is just window dressing, and is never examined by Gnus. Gnus stores all real information it needs using text properties.

(Note that if you make a really strange, wonderful, spreadsheet-like layout, everybody will believe you are hard at work with the accounting instead of wasting time reading news.)

Here's a list of all available format characters:

Only marked articles.
Whether the group is subscribed.
Level of subscribedness.
Number of unread articles.
Number of dormant articles.
Number of ticked articles.
Number of read articles.
Total number of articles.
Number of unread, unticked, non-dormant articles.
Number of ticked and dormant articles.
Full group name.
Group name.
Newsgroup description.
Select method.
Select from where.
A string that looks like `<%s:%n>' if a foreign select method is used.
User defined specifier. The next character in the format string should be a letter. GNUS will call the function gnus-user-format-function-`X', where `X' is the letter following `%u'. The function will be passed the current headers as argument. The function should return a string, which will be inserted into the buffer just like information from any other specifier.

All the "number-of" specs will be filled with an asterisk (`*') if no info is available - for instance, if it is a non-activated foreign group, or a bogus (or semi-bogus) native group.

The mode line can be changed by setting (gnus-group-mode-line-format). It doesn't understand that many format specifiers:

Default news server.
Default select method.

Group Maneuvering

All movement commands understand the numeric prefix and will behave as expected, hopefully.

Go to the next group that has unread articles (gnus-group-next-unread-group).
Go to the previous group group that has unread articles (gnus-group-prev-unread-group).
Go to the next group (gnus-group-next-group).
Go to the previous group (gnus-group-prev-group).
Go to the next unread group on the same level (or lower) (gnus-group-next-unread-group-same-level).
Go to the previous unread group on the same level (or lower) (gnus-group-prev-unread-group-same-level).

Three commands for jumping to groups:

Jump to a group (and make it visible if it isn't already) (gnus-group-jump-to-group). Killed groups can be jumped to, just like living groups.
Jump to the unread group with the lowest level (gnus-group-best-unread-group).
Jump to the first group with unread articles (gnus-group-first-unread-group).

If gnus-group-goto-unread is nil, all the movement commands will move to the next group, not the next unread group. Even the commands that say they move to the next unread group.

Selecting a Group

Select the current group, switch to the summary buffer and display the first unread article (gnus-group-read-group). If there are no unread articles in the group, or if you give a non-numerical prefix to this command, Gnus will offer to fetch all the old articles in this group from the server. If you give a numerical prefix N, Gnus will fetch N number of articles. If N is positive, fetch the N newest articles, if N is negative, fetch the abs(N) oldest articles.
Select the current group and switch to the summary buffer (gnus-group-select-group). Takes the same arguments as gnus-group-read-group - the only difference is that this command does not display the first unread article automatically upon group entry.
Mark all unticked articles in this group as read (gnus-group-catchup-current).
Mark all articles in this group, even the ticked ones, as read (gnus-group-catchup-current-all).

The gnus-large-newsgroup variable says what Gnus should consider to be a big group. If the group has more unread articles than this, Gnus will query the user before entering the group. The user can then specify how many articles should be fetched from the server. If the user specifies a negative number (`-n'), the `n' oldest articles will be fetched. If it is positive, the `n' articles that have arrived most recently will be fetched.

If gnus-auto-select-first is non-nil, the first unread article in the group will be displayed when you enter the group. If you want to prevent automatic selection in some group (say, in a binary group with Huge articles) you can set this variable to nil in gnus-select-group-hook, which is called when a group is selected.

If you are using a threaded summary display, you can sort the threads by setting gnus-thread-sort-functions, which is a list of functions. By default, sorting is done on article numbers. Ready-made sorting functions include gnus-thread-sort-by-number, gnus-thread-sort-by-author, gnus-thread-sort-by-subject, gnus-thread-sort-by-date, gnus-thread-sort-by-score, gnus-thread-sort-by-total-score.

Each function takes two threads and return non-nil if the first thread should be sorted before the other. If you use more than one function, the primary sort key should be the last function in the list.

If you would like to sort by score, then by subject, and finally by date, you could do something like:

(setq gnus-thread-sort-functions 

The function in the gnus-thread-score-function variable (default +) is used for calculating the total score of a thread. Useful functions might be max, min, or squared means, or whatever tickles you fancy.

Group Subscribing

S t
Toggle subscription to the current group (gnus-group-unsubscribe-current-group).
S s
Prompt for a group to subscribe, and then subscribe it. If it was subscribed already, unsubscribe it instead (gnus-group-unsubscribe-group).
S k
Kill the current group (gnus-group-kill-group).
S y
Yank the last killed group (gnus-group-yank-group).
S w
Kill all groups in the region (gnus-group-kill-region).
S z
Kill all zombie groups (gnus-group-kill-all-zombies).

Group Levels

All groups have a level of subscribedness. For instance, if a group is on level 2, it is more subscribed than a group on level 5. You can ask Gnus to just list groups on a given level or lower (see section Listing Groups), or to just check for new articles in groups on a given level or lower (see section Misc Group Stuff).

S l
Set the level of the current group. If a numeric prefix is given, the next n groups will have their levels set. The user will be prompted for a level.

Gnus considers groups on between levels 1 and gnus-level-subscribed (inclusive) to be subscribed, gnus-level-subscribed (exclusive) and gnus-level-unsubscribed (inclusive) to be unsubscribed, gnus-level-zombie to be zombies (walking dead) and gnus-level-killed to be killed, completely dead. Gnus treats subscribed and unsubscribed groups exactly the same, but zombie and killed groups have no information on what articles you have read, etc, stored. This distinction between dead and living groups isn't done because it is nice or clever, it is done purely for reasons of efficiency.

It is recommended that you keep all your mail groups (if any) on quite low levels (eg. 1 or 2).

If you want to play with the level variables, you should show some care. Set them once, and don't touch them ever again. Better yet, don't touch them at all unless you know exactly what you're doing.

Two closely related variables are gnus-level-default-subscribed and gnus-level-default-unsubscribed, which are the levels that new groups will be put on if they are (un)subscribed. These two variables should, of course, be inside the relevant legal ranges.

If gnus-keep-same-level is non-nil, some movement commands will only move to groups that are of the same level (or lower). In particular, going from the last article in one group to the next group will go to the next group of the same level (or lower). This might be handy if you want to read the most important groups before you read the rest.

All groups with a level less than or equal to gnus-group-default-list-level will be listed in the group buffer by default.

If gnus-group-use-permament-levels is non-nil, once you give a level prefix to g or l, all subsequent commands will use this level as the "work" level.

Marking Groups

If you want to perform some action on several groups, and they appear subsequently in the group buffer, you would normally just give a numerical prefix to the command. Most group commands will then do your bidding on those groups.

However, if the groups are not in sequential order, you can still perform an action on several groups. You simply mark the groups first, and then execute the command.

M m
Set the mark on the current group (gnus-group-mark-group).
< u
Remove the mark from the current group (gnus-group-unmark-group).
M w
Mark all groups between point and mark (gnus-group-mark-region).

Foreign Groups

A foreign group is a group that is not read by the usual (or default) means. It could be, for instance, a group from a different NNTP server, it could be a virtual group, or it could be your own personal mail group.

A foreign group (or any group, really) is specified by a name and a select method. To take the latter first, a select method is a list where the first element says what backend to use (eg. nntp, nnspool, nnml) and the second element is the server name. There may be additional elements in the select method, where the value may have special meaning for the backend in question.

One could say that a select method defines a virtual server - so we do just that (see section The Server Buffer).

The name of the group is the name the backend will recognize the group as.

For instance, the group `soc.motss' on the NNTP server `some.where.edu' will have the name `soc.motss' and select method (nntp "some.where.edu"). Gnus will call this group, in all circumstances, `nntp+some.where.edu:soc.motss', even though the nntp backend just knows this group as `soc.motss'.

Here are some commands for making and editing general foreign groups, and some commands to ease the creation of some special-purpose groups:

G m
Make a new group (gnus-group-make-group). Gnus will prompt you for a name, a method and possibly an address. For an easier way to subscribe to NNTP groups, See section Browse Foreign Server.
G e
Enter a buffer where you can edit the select method of the current group (gnus-group-edit-group-method).
G p
Enter a buffer where you can edit the group parameters (gnus-group-edit-group-parameters).
Enter a buffer where you can edit the group info (gnus-group-edit-group).
G d
Make a directory group. You will be prompted for a directory name (gnus-group-make-directory-group).
G h
Make the Gnus help group (gnus-group-make-help-group).
G a
Make a Gnus archive group (gnus-group-make-archive-group). By default a group pointing to the most recent articles will be created (gnus-group-recent-archibe-directory), but given a prefix, a full group will be created from from gnus-group-archive-directory.
G k
Make a kiboze group. You will be prompted for a name, for a regexp to match groups to be "included" in the kiboze group, and a series of strings to match on headers (gnus-group-make-kiboze-group).
Read a random directory as if with were a newsgroup with the nneething backend (gnus-group-enter-directory).
G f
Make a group based on some file or other (gnus-group-make-doc-group). You will be prompted for a file name and a file type. Currently supported types are babyl, mbox and digest.
Make a new, fresh, empty nnvirtual group (gnus-group-make-empty-virtual).
G v
Add the current group to an nnvirtual group (gnus-group-add-to-virtual). Uses the process/prefix convention.

The different methods all have their peculiarities, of course.

If the gnus-activate-foreign-newsgroups is a positive number, Gnus will check all foreign groups with this level or lower at startup. This might take quite a while, especially if you subscribe to lots of groups from different NNTP servers. It is nil by default, which means that you won't be told whether there are new articles in these groups. How many unread articles there are will be determined when, or if, you decide to enter them. You can also activate any group with M-g to see how many unread articles there are.


Subscribing to a foreign group from an NNTP server is rather easy. You just specify nntp as method and the address of the NNTP server as the, uhm, address.

If the NNTP server is located at a non-standard port, setting the third element of the select method to this port number should allow you to connect to the right port. You'll have to edit the group info for that (see section Foreign Groups).

The name of the foreign group can be the same as a native group. In fact, you can subscribe to the same group from as many different servers you feel like. There will be no name collisions.

The following variables can be used to create a virtual nntp server:

nntp-server-opened-hook is run after a connection has been made. It can be used to send commands to the NNTP server after it has been contacted. By default is sends the command `MODE READER' to the server with the nntp-send-mode-reader function. Another popular function is nntp-send-authinfo, which will prompt you for an NNTP password and stuff.
If the NNTP server doesn't support NOV headers, this backend will collect headers by sending a series of head commands. To speed things up, the backend sends lots of these commands without waiting for reply, and then reads all the replies. This is controlled by the nntp-maximum-request variable, and is 400 by default. If your network is buggy, you should set this to 1.
If you have lots of foreign nntp groups that you connect to regularly, you're sure to have problems with NNTP servers not responding properly, or being too loaded to reply within reasonable time. This is can lead to awkward problems, which can be helped somewhat by setting nntp-connection-timeout. This is an integer that says how many seconds the nntp backend should wait for a connection before giving up. If it is nil, which is the default, no timeouts are done.
This hook is run as the last step when connecting to an NNTP server.
The address of the remote system running the NNTP server.
Port number to connect to when using the nntp-open-network-stream connect function.
Set this to non-nil if your select routine is buggy.
If the NNTP server does not support NOV, you could set this variable to t, but nntp usually checks whether NOV can be used automatically.
List of strings that are used as commands to fetch NOV lines from a server. The default value of this variable is ("XOVER" "XOVERVIEW").
nntp normally sends just one big request for NOV lines to the server. The server responds with one huge list of lines. However, if you have read articles 2-5000 in the group, and only want to read article 1 and 5001, that means that nntp will fetch 4999 NOV lines that you do not want, and will not use. This variable says how big a gap between two consecutive articles is allowed to be before the XOVER request is split into several request. Note that if your network is fast, setting this variable to a really small number means that fetching will probably be slower. If this variable is nil, nntp will never split requests.
A hook run before attempting to connect to an NNTP server.
How many articles should be pre-fetched when in asynchronous mode. If this variable is t, nntp will pre-fetch all the articles that it can without bound. If it is nil, no pre-fetching will be made.


Subscribing to a foreign group from the local spool is extremely easy, and might be useful, for instance, to speed up reading groups like `alt.binaries.pictures.furniture'.

Anyways, you just specify nnspool as the method and `""' (or anything else) as the address.

If you have access to a local spool, you should probably use that as the native select method (see section Finding the News).

Program used to post an article.
Parameters given to the inews program when posting an article.
Where nnspool looks for the articles. This is normally `/usr/spool/news/'.
Where nnspool will look for NOV files. This is normally `/usr/spool/news/over.view/'.
Where the news lib dir is (`/usr/lib/news/' by default).
The path of the active file.
The path of the group description file.
The path of the news history file.
The path of the active date file.
If non-nil, nnspool won't try to use any NOV files that it finds.
If non-nil, which is the default, use sed to get the relevant portion from the overview file. If nil, nnspool will load the entire file into a buffer and process it there.


An nnvirtual group is really nothing more than a collection of other groups.

For instance, if you are tired of reading many small group, you can put them all in one big group, and then grow tired of reading one big, unwieldy group. The joys of computing!

You specify nnvirtual as the method. The address should be a regexp to match component groups.

All marks in the virtual group will stick to the articles in the component groups. So if you tick an article in a virtual group, the article will also be ticked in the component group from whence it came. (And vice versa - marks from the component groups will also be shown in the virtual group.)

Here's an example nnvirtual method that collects all Andrea Dworkin newsgroups into one, big, happy newsgroup:

(nnvirtual "^alt\\.fan\\.andrea-dworkin$\\|^rec\\.dworkin.*")

The component groups can be native or foreign; everything should work smoothly, but if your computer explodes, it was probably my fault.

Collecting the same group from several servers might actually be a good idea if users have set the Distribution header to limit distribution. If you would like to read `soc.motss' both from a server in Japan and a server in Norway, you could use the following as the group regexp:


This should work kinda smoothly - all articles from both groups should end up in this one, and there should be no duplicates. Threading (and the rest) will still work as usual, but there might be problems with the sequence of articles. Sorting on date might be an option here (see section Selecting a Group.

One limitation, however - all groups that are included in a virtual group has to be alive (i.e., subscribed or unsubscribed). Killed or zombie groups can't be component groups for nnvirtual groups.


Kibozing is defined by OED as "grepping through (parts of) the news feed". nnkiboze is a backend that will do this for you. Oh joy! Now you can grind any NNTP server down to a halt with useless requests! Oh happiness!

The address field of the nnkiboze method is, as with nnvirtual, a regexp to match groups to be "included" in the nnkiboze group. There most similarities between nnkiboze and nnvirtual ends.

In addition to this regexp detailing component groups, an nnkiboze group must have a score file to say what articles that are to be included in the group (see section Score Files).

You must run M-x nnkiboze-generate-groups after creating the nnkiboze groups you want to have. This command will take time. Lots of time. Oodles and oodles of time. Gnus has to fetch the headers from all the articles in all the components groups and run them through the scoring process to determine if there are any articles in the groups that are to be part of the nnkiboze groups.

Please limit the number of component groups by using restrictive regexps. Otherwise your sysadmin may become annoyed with you, and the NNTP site may throw you off and never let you back in again. Stranger things have happened.

nnkiboze component groups do not have to be alive - they can be dead, and they can be foreign. No restrictions.

The generation of an nnkiboze group means writing two files in nnkiboze-directory, which is `~/News/' by default. One contains the NOV header lines for all the articles in the group, and the other is an additional `.newsrc' file to store information on what groups that have been searched through to find component articles.

Articles that are marked as read in the nnkiboze group will have their NOV lines removed from the NOV file.


If you have a directory that has lots of articles in separate files in it, you might treat it as a newsgroup. The files have to have numerical names, of course.

This might be an opportune moment to mention ange-ftp, that most wonderful of all wonderful Emacs packages. When I wrote nndir, I didn't think much about it - a backend to read directories. Big deal.

ange-ftp changes that picture dramatically. For instance, if you enter `"/ftp@sina.tcamc.uh.edu:/pub/emacs/ding-list/"' as the the directory name, ange-ftp will actually allow you to read this directory over at `sina' as a newsgroup. Distributed news ahoy!

nndir will use NOV files if they are present.

nndir is a "read-only" backend - you can't delete or expire articles with this method. You can use nnmh or nnml for whatever you use nndir for, so you could switch to any of those methods if you feel the need to have a non-read-only nndir.


From the nndir backend (which reads a single spool-like directory), it's just a hop and a skip to nneething, which pretends that any random directory is a newsgroup. Strange, but true.

When nneething is presented with a directory, it will scan this directory and assign article numbers to each file. When you enter such a group, nneething must create "headers" that Gnus can use. After all, Gnus is a newsreader, in case you're forgetting. nneething does this in a two-step process. First, it snoops each file in question. If the file looks like an article (i.e., the first few lines look like headers), it will use this as the head. If this is just some random file without a head (eg. a C source file), nneething will cobble up a header out of thin air. It will use file ownership, name and date and do whatever it can with these elements.

All this should happen automatically for you, and you will be presented with something that looks very much like a newsgroup. Totally like a newsgroup, to be precise. If you select an article, it will be displayed in the article buffer, just as usual.

If you select a line that represents a directory, Gnus will pop you into a new summary buffer for this nneething group. And so on. You can traverse the entire disk this way, if you feel like, but remember that Gnus is not dired, really, and does not intend to be, either.

There are two overall modes to this action - ephemeral or solid. When doing the ephemeral thing (i.e., G D from the group buffer), Gnus will not store information on what files you have read, and what files are new, and so on. If you create a solid nneething group the normal way with G m, Gnus will store a mapping table between article numbers and file names, and you can treat this group like any other groups. When you activate a solid nneething group, you will be told how many unread articles it contains, etc., etc.

Some variables:

All the mapping files for solid nneething groups will be stored in this directory, which defaults to `~/.nneething/'.
All files that match this regexp will be ignored. Nice to use to exclude auto-save files and the like, which is what it does by default.
Name of the map files.


nndoc is a cute little thing that will let you read a single file as a newsgroup. Currently supported file types are babyl, mbox and digest.

nndoc will not try to change the file or insert any extra headers into it - it will simply, like, let you use the file as the basis for a group. And that's it.

Virtual server variables:

This should be one of mbox, babyl or digest.

Reading Mail

Reading mail with a newsreader - isn't that just plain WeIrD? But of course.

Gnus will read the mail spool when you activate a mail group. The mail file is first copied to your home directory. What happens after that depends on what format you want to store your mail in.

The mail backends all call nnmail-read-incoming-hook after reading new mail. You can use this hook to notify any mail watch programs, if you want to.

nnmail-spool-file says where to look for new mail. If this variable is nil, the mail backends will never attempt to fetch mail by themselves. It is quite likely that Gnus supports POP-mail. Set this variable to begin with the string `po:', and everything should go smoothly, even though I have never tested this.

If nnmail-use-procmail is non-nil, the mail backends will look in nnmail-procmail-directory for incoming mail. All the files in that directory that have names ending in gnus-procmail-suffix will be considered incoming mailboxes, and will be searched for new mail.

nnmail-prepare-incoming-hook is run in a buffer that holds all the new incoming mail, and can be used for, well, anything, really.

nnmail-tmp-directory says where to move the incoming mail to while processing it. This is usually done in the same directory that the mail backend inhabits (i.e., `~/Mail/'), but if this variable is non-nil, it will be used instead.

nnmail-movemail-program is executed to move mail from the user's inbox to her home directory. The default is `"movemail"'.

If nnmail-delete-incoming is non-nil, the mail backends will delete the temporary incoming file after splitting mail into the proper groups. This is nil by default for reasons of security.

If you are a member of a couple of mailing list, you will sometime receive two copies of the same mail. This can be quite annoying, so nnmail checks for and discards any duplicates it might find. To do this, it keeps a cache of old Message-IDs - nnmail-message-id-cache-file, which is `~/.nnmail-cache' by default. The approximate maximum number of Message-IDs stored there is controlled by the nnmail-message-id-cache-length variable, which is 1000 by default. (So 1000 Message-IDs will be stored.) If all this sounds scary to you, you can set nnmail-delete-duplicates to nil (which is what it is by default), and nnmail won't do any duplicate checking.

Here's a neat feature: If you know that the recipient reads her mail with Gnus, and that she has nnmail-delete-duplicates set to t, you can send her as many insults as you like, just by using a Message-ID of a mail that you know that she's already received. Think of all the fun! She'll never see any of it! Whee!

Gnus gives you all the opportunity you could possibly want for shooting yourself in the foot. Let's say you create a group that will contain all the mail you get from your boss. And then you accidentally unsubscribe from the group. Gnus will still put all the mail from your boss in the unsubscribed group, and so, when your boss mails you "Have that report ready by Monday or you're fired!", you'll never see it and, come Tuesday, you'll still believe that you're gainfully employed while you really should be out collecting empty bottles to save up for next month's rent money.

Creating Mail Groups

You can make Gnus read your personal, private, secret mail.

You should first set gnus-secondary-select-methods to, for instance, ((nnmbox "")). When you start up Gnus, Gnus will ask this backend for what groups it carries (`mail.misc' by default) and subscribe it the normal way. (Which means you may have to look for it among the zombie groups, I guess, all depending on your gnus-subscribe-newsgroup-method variable.)

Then you should set the variable nnmail-split-methods to specify how the incoming mail is to be split into groups.

(setq nnmail-split-methods
  '(("mail.junk" "^From:.*Lars Ingebrigtsen")
    ("mail.crazy" "^Subject:.*die\\|^Organization:.*flabby")
    ("mail.other" "")))

This variable is a list of lists, where the first element of each of these lists is the name of the mail group (they do not have to be called something beginning with `mail', by the way), and the second element is a regular expression used on the header of each mail to determine if it belongs in this mail group.

The second element can also be a function. In that case, it will be called narrowed to the headers with the first element of the rule as the argument. It should return a non-nil value if it thinks that the mail belongs in that group.

The last of these groups should always be a general one, and the regular expression should always be `""' so that it matches any mails that haven't been matched by any of the other regexps.

If you like to tinker with this yourself, you can set this variable to a function of your choice. This function will be called without any arguments in a buffer narrowed to the headers of an incoming mail message. The function should return a list of groups names that it thinks should carry this mail message.

The mail backends all support cross-posting. If several regexps match, the mail will be "cross-posted" to all those groups. nnmail-crosspost says whether to use this mechanism or not. Note that no articles are crossposted to the general (`""') group.

Fancy Mail Splitting

If the rather simple, standard method for specifying how to split mail doesn't allow you to do what you want, you can set nnmail-split-methods to nnmail-split-fancy. Then you can play with the nnmail-split-fancy variable.

Let's look at an example value of this variable first:

;; Messages from the mailer daemon are not crossposted to any of
;; the ordinary groups.  Warnings are put in a separate group
;; from real errors.
(| ("from" mail (| ("subject" "warn.*" "mail.warning")
   ;; Non-error messages are crossposted to all relevant
   ;; groups, but we don't crosspost between the group for the
   ;; (ding) list and the group for other (ding) related mail.
   (& (| (any "ding@ifi\\.uio\\.no" "ding.list")
	 ("subject" "ding" "ding.misc"))
      ;; Other mailing lists...
      (any "procmail@informatik\\.rwth-aachen\\.de" "procmail.list")
      (any "SmartList@informatik\\.rwth-aachen\\.de" "SmartList.list")
      ;; People...
      (any "larsi@ifi\\.uio\\.no" "people.Lars Magne Ingebrigtsen"))
   ;; Unmatched mail goes to the catch all group.

This variable has the format of a split. A split is a (possibly) recursive structure where each split may contain other splits. Here are the four possible split syntaxes:

If the split is a string, that will be taken as a group name.
If the split is a list, and the first element is a string, then that means that if header FIELD (a regexp) contains VALUE (also a regexp), then store the message as specified by SPLIT.
(| SPLIT...)
If the split is a list, and the first element is | (vertical bar), then process each SPLIT until one of them matches. A SPLIT is said to match if it will cause the mail message to be stored in one or more groups.
(& SPLIT...)
If the split is a list, and the first element is &, then process all SPLITs in the list.

In these splits, FIELD must match a complete field name. VALUE must match a complete word according to the fundamental mode syntax table. You can use .* in the regexps to match partial field names or words.

FIELD and VALUE can also be lisp symbols, in that case they are expanded as specified by the variable nnmail-split-abbrev-alist. This is an alist of cons cells, where the car of the cells contains the key, and the cdr contains a string.

Mail & Procmail

Many people use procmail to split incoming mail into groups. If you do that, you should set nnmail-spool-file to procmail to ensure that the mail backends never ever try to fetch mail by themselves.

This also means that you probably don't want to set nnmail-split-methods either, which has some, perhaps, unexpected side effects.

When a mail backend is queried for what groups it carries, it replies with the contents of that variable, along with any groups it has figured out that it carries by other means. None of the backends (except nnmh) actually go out to the disk and check what groups actually exist. (It's not trivial to distinguish between what the user thinks is a basis for a newsgroup and what is just a plain old file or directory.)

This means that you have to tell Gnus (and the backends) what groups exist by hand.

Let's take the nnmh backend as an example.

The folders are located in nnmh-directory, say, `~/Mail/'. There are three folders, `foo', `bar' and `mail.baz'.

Go to the group buffer and type G m. When prompted, answer `foo' for the name and `nnmh' for the method. Repeat twice for the two other groups, `bar' and `mail.baz'. Be sure to include all your mail groups.

That's it. You are now set to read your mail. An active file for this method will be created automatically.

If you use nnfolder or any other backend that store more than a single article in each file, you should never have procmail add mails to the file that Gnus sees. Instead, procmail should put all incoming mail in nnmail-procmail-directory. To arrive at the file name to put the incoming mail in, append nnmail-procmail-suffix to the group name. The mail backends will read the mail from these files.

When Gnus reads a file called `mail.misc.spool', this mail will be put in the mail.misc, as one would expect. However, if you want Gnus to split the mail the normal way, you could set nnmail-resplit-incoming to t.

If you use procmail to split things directory into an nnmh directory (which you shouldn't do), you should set nnmail-keep-last-article to non-nil to prevent Gnus from ever expiring the final article in a mail newsgroup. This is quite, quite important.

Expiring Old Mail Articles

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. 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. Groups that match the regular expression gnus-auto-expirable-newsgroups will have all articles that you read marked as expirable automatically. All articles that are marked as expirable have an `E' in the first column in the summary buffer.

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 

Another way to have auto-expiry happen is to have the element auto-expire in the select method of the group.

The nnmail-expiry-wait variable supplies the default time an expirable article has to live. The default is seven days.

Gnus also supplies a function that lets you fine-tune how long articles are to live, based on what group they are in. Let's say you want to have 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:

(setq nnmail-expiry-wait-function
      (lambda (group)
       (cond ((string= group "mail.private")
             ((string= group "mail.junk")

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.

Note that at present, Gnus will not actually delete any expirable articles automatically. You have to enter one of the expiry functions (eg. `C-c M-c-x' in the group buffer) to actually run articles through the expiry process. Or you can add a call to the expiry function in the group exit hook. Gnus will probably do all this automatically in the future.

Not Reading Mail

If you start using any of the mail backends, they have the annoying habit of assuming that you want to read mail with them. This might not be unreasonable, but it might not be what you want.

If you set nnmail-spool-file to nil, none of the backends will ever attempt to read incoming mail, which should help.

This might be too much, if, for instance, you are reading mail quite happily with nnml and just want to peek at some old RMAIL file you have stashed away with nnbabyl. All backends have variables called backend-get-new-mail. If you want to disable the nnbabyl mail reading, you edit the virtual server for the group to have a setting where nnbabyl-get-new-mail to nil.

All the mail backends will call nn*-prepare-save-mail-hook narrowed to the article to be saved before saving it when reading incoming mail.


The nnmbox backend will use the standard Un*x mbox file to store mail. nnmbox will add extra headers to each mail article to say which group it belongs in.

Virtual server settings:

The name of the mail box in the user's home directory.
The name of the active file for the mail box.
If non-nil, nnmbox will read incoming mail and split it into groups.


The nnbabyl backend will use a babyl mail box (aka. rmail mbox) to store mail. nnbabyl will add extra headers to each mail article to say which group it belongs in.

Virtual server settings:

The name of the rmail mbox file.
The name of the active file for the rmail box.
If non-nil, nnbabyl will read incoming mail.


The nnml spool mail format isn't compatible with any other known format. It should be used with some caution.

If you use this backend, Gnus will split all incoming mail into files; one file for each mail, and put the articles into the correct directories under the directory specified by the nnml-directory variable. The default value is `~/Mail/'.

You do not have to create any directories beforehand; Gnus will take care of all that.

If you have a strict limit as to how many files you are allowed to store in your account, you should not use this backend. As each mail gets its own file, you might very well occupy thousands of inodes within a few weeks. If this is no problem for you, and it isn't a problem for you having your friendly systems administrator walking around, madly, shouting "Who is eating all my inodes?! Who? Who!?!", then you should know that this is probably the fastest format to use. You do not have to trudge through a big mbox file just to read your new mail.

nnml is probably the slowest backend when it comes to article splitting. It has to create lots of files, and it also generates NOV databases for the incoming mails. This makes is the fastest backend when it comes to reading mail.

Virtual server settings:

All nnml directories will be placed under this directory.
The active file for the nnml server.
The nnml group description file.
If non-nil, nnml will read incoming mail.
If non-nil, this backend will ignore any NOV files.
The name of the NOV files. The default is `.overview'.

If your nnml groups and NOV files get totally out of whack, you can do a complete update by typing M-x nnml-generate-nov-databases. This command will trawl through the entire nnml hierarchy, looking at each and every article, so it might take a while to complete.


nnmh is just like nnml, except that is doesn't generate NOV databases and it doesn't keep an active file. This makes nnmh a much slower backend than nnml, but it also makes it easier to write procmail scripts for.

Virtual server settings:

All nnmh directories will be located under this directory.
If non-nil, nnmh will read incoming mail.
If non-nil, nnmh will go to ridiculous lengths to make sure that the articles in the folder is actually what Gnus think they are. It will check date stamps, and stat everything in sight, so setting this to t will mean a serious slow-down. If you never use anything by Gnus to read the nnmh articles, you do not have to set this variable to t.


nnfolder is a backend for storing each mail group in a separate file. Each file is in the standard Un*x mbox format. nnfolder will add extra headers to keep track of article numbers and arrival dates.

Virtual server settings:

All the nnfolder mail boxes will be stored under this directory.
The name of the active file.
The name of the group description file.
If non-nil, nnfolder will read incoming mail.

Group Parameters

Gnus stores all information on a group in a list that is usually known as the group info. This list has from three to six elements. Here's an example info.

("nnml:mail.ding" 3 ((1 . 232) 244 (256 . 270)) ((tick 246 249))
                  (nnml "private") ((to-address . "ding@ifi.uio.no")))

The first element is the group name, as Gnus knows the group, anyway. The second element is the subscription level, which normally is a small integer. The third element is a list of ranges of read articles. The fourth element is a list of lists of article marks of various kinds. The fifth element is the select method (or virtual server, if you like). The sixth element is a list of group parameters, which is what this section is about.

Any of the last three elements may be missing if they are not required. In fact, the vast majority of groups will normally only have the first three elements, which saves quite a lot of cons cells.

At present, there's not much you can put in the group parameters list:

If the group parameter list contains an element that looks like `(to-address . "some@where.com")', that address will be used by the backend when doing followups and posts. This is primarily useful in mail groups that represent mailing lists. You just set this address to whatever the list address is. This trick will actually work whether the group is foreign or not. Let's say there's a group on the server that is called `fa.4ad-l'. This is a real newsgroup, but the server has gotten the articles from a mail-to-news gateway. Posting directly to this group is therefore impossible - you have to send mail to the mailing list address instead.
IF the group parameter list contains an element like (to-group . "some.group.name"), all posts will be sent to that groups.
If this symbol is present in the group parameter list, all articles that are read will be marked as expirable. For an alternative approach, See section Expiring Old Mail Articles.
If this symbol is present, all read articles will be put through the expiry process, even if they are not marked as expirable. Use with caution.

If you want to change the group parameters (or anything else of the group info) you can use the G E to edit enter a buffer where you can edit the group info.

You usually don't want to edit the entire group info, so you'd be better off using the G p command to just edit the group parameters.

Listing Groups

These commands all list various slices of the groups that are available.

A s
List all groups that have unread articles (gnus-group-list-groups). If the numeric prefix is used, this command will list only groups of level ARG and lower. By default, it only lists groups of level five or lower (i.e., just subscribed groups).
A u
List all groups, whether they have unread articles or not (gnus-group-list-all-groups). If the numeric prefix is used, this command will list only groups of level ARG and lower. By default, it lists groups of level seven or lower (i.e., just subscribed and unsubscribed groups).
A k
List all killed groups (gnus-group-list-killed).
A z
List all zombie groups (gnus-group-list-zombies).
A m
List all subscribed groups with unread articles that match a regexp (gnus-group-list-matching).
List groups that match a regexp (gnus-group-list-all-matching).

Group Maintenance

Find bogus groups and delete them (gnus-group-check-bogus-groups).
Find new groups and process them (gnus-find-new-newsgroups).
C-c C-x
Run all expirable articles in the current group through the expiry process (if any) (gnus-group-expire-articles).
C-c M-C-x
Run all articles in all groups through the expiry process (gnus-group-expire-all-groups).
C-c C-s
Sort the groups according to the function given by the gnus-group-sort-function variable (gnus-group-sort-groups). Available sorting functions include gnus-group-sort-by-alphabet (the default), gnus-group-sort-by-unread and gnus-group-sort-by-level.

Browse Foreign Server

You will be queried for a select method and a server name. Gnus will then attempt to contact this server and let you browse the groups there (gnus-group-browse-foreign-server).

A new buffer with a list of available groups will appear. This buffer will be use the gnus-browse-server-mode. This buffer looks a bit (well, a lot) like a normal group buffer, but with one major difference - you can't enter any of the groups. If you want to read any of the news available on that server, you have to subscribe to the groups you think may be interesting, and then you have to exit this buffer. The new groups will be added to the group buffer, and then you can read them as you would any other group.

Future versions of Gnus may possibly permit reading groups straight from the browse buffer.

Here's a list of keystrokes available in the browse mode:

Go to the next group (gnus-group-next-group).
Go to the previous group (gnus-group-prev-group).
Enter the current group and display the first article (gnus-browse-read-group).
Enter the current group (gnus-browse-select-group).
Unsubscribe to the current group, or, as will be the case here, subscribe to it (gnus-browse-unsubscribe-current-group).
Exit browse mode (gnus-browse-exit).
Describe browse mode briefly (well, there's not much to describe, is there) (gnus-browse-describe-briefly).

Exiting Gnus

Yes, Gnus is ex(c)iting.

Suspend Gnus (gnus-group-suspend). This doesn't really exit Gnus, but it kills all buffers except the Group buffer. I'm not sure why this is a gain, but then who am I to judge?
Quit Gnus (gnus-group-exit).
Quit Gnus without saving any startup files (gnus-group-quit).

gnus-suspend-gnus-hook is called when you suspend Gnus and gnus-exit-gnus-hook is called when you quit Gnus.

If you wish to completely unload Gnus and all its adherents, you can use the gnus-unload command. This command is also very handy when trying to custoize meta-variables.


Miss Lisa Cannifax, while sitting in English class, feels her feet go numbly heavy and herself fall into a hazy trance as the boy sitting behind her drew repeated lines with his pencil across the back of her plastic chair.

Misc Group Stuff

Check server for new articles. If the numeric prefix is used, this command will check only groups of level ARG and lower (gnus-group-get-new-news).
Check whether new articles have arrived in the current group (gnus-group-get-new-news-this-group).
Enter the server buffer (gnus-group-enter-server-mode). See section The Server Buffer.
Try to fetch the FAQ for the current group (gnus-group-fetch-faq). Gnus will try to get the FAQ from gnus-group-faq-directory, which is usually a directory on a remote machine. ange-ftp will be used for fetching the file.
Restart Gnus (gnus-group-restart).
Read the init file (gnus-init-file, which defaults to `~/.gnus') (gnus-group-read-init-file).
Save the `.newsrc.eld' file (and `.newsrc' if wanted) (gnus-group-save-newsrc).
Clear the dribble buffer (gnus-group-clear-dribble).
Describe the current group (gnus-group-describe-group). If given a prefix, force Gnus to re-read the description from the server.
G a
List all groups that have names that match a regexp (gnus-group-apropos).
G d
List all groups that have names or descriptions that match a regexp (gnus-group-description-apropos).
Post an article to a group (gnus-group-post-news).
Mail a message somewhere (gnus-group-mail).
C-x C-t
Transpose two groups (gnus-group-transpose-groups).
Display current Gnus version numbers (gnus-version).
Describe all groups (gnus-group-describe-all-groups). If given a prefix, force Gnus to re-read the description file from the server.
Give a very short help message (gnus-group-describe-briefly).
C-c C-i
Go to the Gnus info node (gnus-info-find-node).

gnus-group-prepare-hook is called after the group buffer is generated. It may be used to modify the buffer in some strange, unnatural way.

Go to the first, previous, next, last section, table of contents.