1 @node Mail with Gnus, , Key bindings, Top
2 @comment node-name, next, previous, up
3 @chapter Mail with Gnus
5 Quite a few people wish to read mail with Gnus but stumble across a few
6 issues which make this a bit difficult. This comes from the fact that
7 Gnus is really a newsreader, and thus it treats mail in a newsreaderly
8 fashion. It is not desirable to change this, because it is a wonderful
9 thing and this is what distinguishes Gnus from other mail readers. In
10 this little tutorial, I'll try to explain what ``newsreaderly fashion''
11 means and how exactly Gnus treats mail.
13 Specific pieces of behavior can always be changed, but if you desire to
14 make Gnus behave like a conventional mail reader, think again. It will
15 be an uphill battle. Maybe a different mail reader is for you? But
16 also, read on. Maybe you'll find the right behavior in the description
19 @c ------------------------------------------------------------
20 @section Gnus Terminology
21 @c ------------------------------------------------------------
23 First, let's talk about a few terms which I'm going to use which might
27 @item Posting, Article, Message, Mail
28 These are all related terms. A news message might also be called a
29 posting or an article, whereas a mail message is known as a mail. Since
30 Gnus treats both news and mail, the distinction isn't as clear. In the
31 following, I'll use the term ``message'' for the generic case and ``news
32 message'' and ``mail message'' for the specific cases. But sometimes, I
33 might use ``posting'' or ``article'', too, both synonymous with
37 Gnus can read messages from various sources. On the one hand, there is
38 news, and on the other hand, there is mail. News can be read from a
39 news server (an NNTP server), or from a so-called spool directory. Mail
40 can be read in various formats.
42 Generally speaking, a backend describes the way Gnus accesses a set of
43 messages. For a news server, this is the Network News Transfer
44 Protocol, NNTP, and thus there is a backend ``nntp''. For mail stored
45 in the same format that the MH message handling system used, there is
46 the backend ``nnmh''. And so on. See below for a list of backends.
49 Whereas a backend describes the mechanism used by Gnus to access the
50 messages, a server is a specific instance of that mechanism. You might
51 create a specific server for accessing the host @file{news.frob.org}
52 using NNTP, say. Or you might create a server for accessing the
53 MH-style directory @file{~/OldMail}.
55 If you are a programmer, think of a backend as the class and of a server
56 as an object (instance) of that class. If you are a cook, think of a
57 backend as an apple pie recipe (say), and think of a server as an actual
58 apple pie. (Yummy!) If you live in a huge city, think of a backend as
59 a bus (or tram, or underground) line (the Circle Line comes to mind),
60 and think of a server as a specific bus (or tram train, or underground
61 train). The one at 8:15 last Monday morning, for example. If you drive
62 a car, think of a backend as the model and make and of a server as a
65 Obviously, there can be two servers using the same backend. (Two
66 instances of the same class, two apple pies baked according to the same
67 recipe, two busses going the same route, two cars of the same model.)
70 Just another term for server.
73 This is the primary server, so to speak. Most people let their news
74 server be the native server, hence:
76 (setq gnus-select-method '(nntp "news.frob.org"))
78 Groups from the native server are also known as native groups.
80 @item Secondary select methods
81 This is a list of other servers which one also wishes to use. Many
82 people are only going to have two servers, one native (for news) and one
83 secondary (for mail). Thus:
85 (setq gnus-secondary-select-methods '((nnml "")))
87 Note that there is one more pair of parentheses in order to be able to
88 mention more than one seconary select method.
90 Groups from a secondary server are also known as secondary groups.
92 In order to be able to distinguish native groups from secondary groups,
93 each server is identified with a (unique) name and that name is used as
94 a prefix for the secondary groups. Thus, you might have a group
95 @file{gnu.emacs.help} (which is native) and another group
96 @file{nnml:mail.misc} (which is secondary). A plus character is used if
97 the name of a server is not the empty string. For example, given the
98 following in your @file{.gnus} file
100 (setq gnus-secondary-select-methods
101 '((nnml "work" (nnml-directory "~/Mail.work/"))
102 (nnml "play" (nnml-directory "~/Mail.play/"))))
104 you might have the groups @file{nnml+work:boss} and
105 @file{nnml+play:so}@footnote{``SO'' standing for ``significant other'',
106 i.e.@ girlfriend or boyfriend}.
109 Well, if you've read news before, you know about different news groups.
110 One of my favorites is @file{gnu.emacs.gnus}, and I wish I would read
111 @file{alt.fan.pratchett}. Since Gnus treats mail in a newsreaderly
112 fashion, it is obvious that it uses groups rather than ``folders'' like
113 other mail readers do. So with Gnus there are news groups and mail
114 groups, where mail groups are known as mail folders to other programs.
116 Each group belongs to a certain server, and each server uses a certain
120 News servers offer news groups which contain news postings. New news
121 postings come in, so the news postings accumulate, and pretty soon the
122 new hard disk is full. This is not good news at all.
124 Thus, a news server does what is known as @dfn{expiry}: it deletes old
125 messages. Of course, on a news server, expiry happens with no regard of
126 whether people have already seen the message in question; instead, the
127 news server admin chooses expiry times based on available disk space and
128 maybe on the normal amount of traffic in a news group.
130 But mail messages should be under the users' control, so there better be
131 no server which deletes messages regardless of users having seen them!
132 Instead, Gnus adopts a scheme where users say which messages may be
133 deleted, and Gnus takes care of deleting them after a while. (They are
134 not deleted immediately in case you made a mistake, or in case you wish
135 to refer back to an old article.)
138 Gnus distinguishes between a number of article marks, which indicate
139 whether they have been looked at, or are considered important, or the
140 like. Marks are represented by a character.
142 If that character is a space, it looks as if the message isn't marked at
143 all. These messages are called @dfn{unmarked}, the mark character used
144 is a space, and marking a message with space is considered to be the
145 same as removing all marks---after all, such messages are unmarked. You
146 can type @kbd{M-u} to remove all marks and make an article unmarked.
148 Articles that are considered important or where you wish to indicate
149 that you have to deal with them later can be @dfn{ticked}. The mark
150 character used for ticked messages is the exclamation mark, and you can
151 use @kbd{u} or @kbd{!} to tick messages. Ticked messages are always
152 shown when you enter a group.
154 There is the @dfn{dormant} mark which is similar to the ticked mark but
155 does not imply importance or urgency; thus, dormant messages aren't
156 shown by default. The mark character used is the question mark, and you
157 can mark messages as dormant using the @kbd{?} key.
159 So far, each kind of mark was associated with one character (as was the
160 absence of any mark). But articles which you have read are a bit
161 different, since lots of different characters are used here. The
162 important thing to realize is that these messages are treated in the
163 same way by Gnus; the different characters are only used as an
164 information for the user.
166 Articles which are marked as read because you have actually read them
167 (the normal case, one would think) are marked with the `R' character.
168 (Type @kbd{@key{SPC}} or @kbd{g} to read a message, or click on it using
169 the middle mouse button, @kbd{@key{mouse-2}}.) You can also mark a
170 message as read without actually reading it, this is indicated with the
171 `r' character and can be achieved with @kbd{d} or @kbd{M r}.
173 After exiting a group and then entering it again (some time later), the
174 messages that had been marked as read before appear with the `O'
177 To reiterate: the difference between `r', `R' and `O' is only an
178 information for the user.
184 @c ------------------------------------------------------------
185 @section Choosing a mail backend
186 @c ------------------------------------------------------------
188 The Gnus manual lists quite a few backends. Of these, the news backends
189 pose no problem: you use the @code{nntp} backend if you access a news
190 server and the @code{nnspool} backend if you have a local news spool
191 directory. (Leafnode users should use @code{nntp} so that the leafnode
192 program can see what you are doing and choose the groups to download
193 accordingly.) But the mail backends are more difficult. There are many
194 of them, and it is not obvious which is the best choice. In quite a few
195 cases, this is because there is no single best choice; or maybe what's
196 the best choice depends on the group or changes over time.
198 Below, I'll give a list of mail backends. While I say something about
199 how messages are stored, I'll try to emphasize what that means for you
202 Let's try to structure the discussion a bit. We have servers, which
203 contain groups, which in turn contain messages. How could we store this
204 on disk? After some thought, you'll quickly come up with the following
205 alternatives: You could store all messages from a server in one file.
206 The second alternative is to store all messages from one group in one
207 file, different groups are stored in different files. A third
208 alternative is to store each message in one file; in this case, one
209 could use a directory per group. A very interesting fourth alternative
210 is not to store the messages at all but instead to use the Oracle of
211 Delphi (say) to predict what the messages will be; this saves a lot of
212 disk space. I won't talk about the fourth alternative in the following.
215 @subsection Backends with one file per server
217 Many people use just two servers, the native server for news and a
218 secondary server for mail. Thus, this alternative would mean that you
219 store all your mail in one file. Since Emacs has no fancy mechanisms to
220 access parts of files, this means that Gnus loads that file into main
221 memory at startup, and all your mails are kept in main memory all the
222 time. (Of course, copies are written to disk every now and then, for
225 I think you can pretty much figure out the consequences on your own,
229 Handling large amounts of mail will be a problem. (Emacs has a maximum
230 file size of 128 MB.)
233 Some operations on mails will be fast, since they are in-memory
234 operations. (Saving everything to disk will be slow, though.)
237 Some operations on mails will be slow, since they have to search through
241 It is convenient to have all mail stored in one file: you can easily
242 transfer it to another computer using FTP, say, or store it on a floppy
243 or Zip disk or a tape.
247 Conclusion: If you don't have a lot of mail to deal with and like the
248 convenience of storing it all in one file, one of these backends might
249 be for you. However, since Gnus really shines when dealing with lots of
250 mails, most Gnus users can be expected to deal with quite a large volume
251 of mail. Thus, I don't think many Gnus users choose one of these
256 This backend uses the well-known ``mbox'' format for storing mails. In
257 this format, a message begins with the five characters @code{From_} (the
258 last character is a space) at the beginning of a line, and ends with an
262 This backend uses the lesser known ``babyl'' format for storing mails.
263 This uses delimiters for the beginning and the end of a message which
264 are less likely to occur in a message.
267 CCC Are they guaranteed to never occur?
270 One advantage of a babyl file over an mbox file is that it is possible
271 to insert information about a message in the babyl file, without having
272 to change the message itself. In an mbox file, the only place to put
273 such information is the message header, which is part of the message.
274 Thus, adding information about a message to an mbox file means that one
275 has to change the message.
277 I think Gnus doesn't make use of this advantage, though. Gnus stores
278 information about messages in an extra file, @file{~/.newsrc.eld}.
283 CCC Can somebody provide me with some more arguments in favor of one of
286 CCC Is it possible to just use an existing babyl file for Gnus, by
287 creating a new nnmbox server and pointing it at the file? What about
292 @subsection Backends with one file per group
294 Storing all messages in a group in one file provides a nice middle
295 ground between the one file per server type of backend and the one file
296 per message type of backend. Using lots of little files wastes disk
297 space; since this approach uses a moderate number of files, less disk
301 CCC Which operations are fast using this kind of backend? Which are
307 This backend uses the same file format as @code{nnmbox}, but uses the
308 one file per group approach.
312 There is no ``nnbabylfolder'' backend which uses babyl format.
315 @subsection Backends with one file per message
317 If the number of messages grows so large that even the size of a single
318 group exceeds the limit which can be handled by the file-per-group
319 backends, you need to think about using one of the backends mentioned
322 This category also includes @code{nnml}, the backend which is fastest if
323 you have lots of messages.
327 This backend uses the same file format (and directory structure) as MH,
328 i.e.@ a group is a directory, and each message is stored in a file, and
329 the file names are numbers.
331 Since @code{nnml} is so similar to @code{nnmh} but a lot faster, only
332 unusual situations could warrant using this backend. You may want to
333 use @code{nnmh} if you wish to use Gnus in parallel to your old MH based
336 Normally, you should not let two programs write the same Gnus directory
337 (not even two instances of Gnus!), but if you really must, you may wish
338 to use @code{nnmh}, since there the probability of things breaking is
339 smaller than with the other backends.
342 This backend is like @code{nnmh} but also includes an extra file
343 @file{.overview} in each directory (group) which contains some headers
344 from each message. Thus, where @code{nnmh} needs to open every file in
345 a group to examine its headers, @code{nnml} (normally) needs to only
346 read the @file{.overview} file, which is a lot faster.
350 @subsection Other mail backends
352 There is one other mail backend, for keeping messages on an IMAP server.
356 This backend transforms Gnus into an IMAP client. The general idea of
357 IMAP is to store and manipulate the mails on a server (similar to NNTP
360 @code{nnimap} only works with the current development version of Gnus,
361 though. See @url{http://www.extundo.com/nnimap/} for @code{nnimap} and
362 see @url{http://www.gnus.org/} for Gnus. Don't forget to subscribe to
363 both the Gnus and the nnimap mailing lists since you are using alpha
364 grade software which can be exptected to have bugs. Be prepared to
365 submit meaningful bug reports if you encounter bugs.
367 Rumor has it that @code{nnimap} will be integrated with the next version
368 of Gnus (version 5.8, presumably), when that comes out.
375 If you must talk to an IMAP server, the choice is clear. But if you
376 keep mails on your local disk, the choice isn't as clear-cut. I think
377 that @code{nnml} is generally the best choice unless you have real great
378 disk space trouble. Then, you should be thinking about @code{nnfolder}.
380 I'm not sure if there is a situation where @code{nnmbox} or
381 @code{nnbabyl} is desirable.
384 CCC Tell me about it if you know more!
388 @c ------------------------------------------------------------
389 @section Auto-expire versus total-expire
390 @c ------------------------------------------------------------
392 Every now and then, people ask about auto-expire and total-expire.
393 Since both of these features are means to the same end, and since they
394 are similar and dissimilar at the same time, great confusion can result
395 in the unsuspecting new Gnus user. I'll try to explain how each works
396 and which one to use. However, be prepared that there will be no clear
397 recommendation: both work well, so for many situations both are
398 appropriate. So it is more a matter of taste which one to choose. And
399 I can't help you with that!
402 @subsection What is expiry?
404 Gnus treats mail in a newsreaderly fashion, so it is useful to examine
405 the situation for news. Your news server periodically contacts other
406 news servers and exchanges messages with the other server. The two news
407 servers exchange lists of messages, and messages present in one server
408 but not in the other are sent to the other server. This works in both
409 directions. Many connections between news servers exist, and this is
410 the way how postings travel from you into the world: when you post a
411 message, your news server stores it and offers it to the other servers
412 in the message list exchanging phase. Since the other servers aren't
413 going to have the posting you just wrote, it gets transferred and
414 finally can be seen all over the world.
416 You can quickly see that new messages will be arriving at your news
417 server, which stores them on disk. So something has got to happen else
418 the disk will fill up real fast. That ``something'' is expiry: the
419 oldest messages are deleted to make room for the new ones. Normally, a
420 news server can be configured on a per-group basis which messages should
421 be deleted. In some groups, messages might be deleted which are older
422 than a day, in other groups, messages might be kept for a month.
424 This means if you go on vacation then come back later to read news, you
425 are likely to miss some postings if the expiration time for the groups
426 you read is shorter than the time you were on vacation.
428 How does that apply to mail?
430 Well, mail should stay more under the control of the user than news is.
431 When you come back from a vacation, you expect to see all messages
432 arrived during that time, not only the recent ones!
434 Because of this, Gnus offers you the @kbd{E} key. This marks a message
435 as expirable. No mail is ever deleted from disk, unless it is
436 expirable. Every once in a while (by default, whenever you quit a group
437 by hitting @kbd{q} in the Summary buffer), the expiry process is run,
438 which goes through all expirable messages (of a group) and expires it if
439 old enough. By default, messages older than seven days are ``old
440 enough''. Seven days, that is, since it was marked as expirable.
443 CCC Last sentence correct?
446 ``But when I read a message, exit the group, then enter it again, the
449 Right. By default, Gnus hides messages which have already been read.
450 If you are the keyboard type, you can hit @kbd{C-u @key{RET}} or
451 @kbd{C-u @key{SPC}} to enter the group or @kbd{C-u M-g} when in the
452 group to look at the read messages. If you are the mousey type, you may
453 wish to use the ``See old articles'' entry in the ``Group'' menu.
456 CCC How does one code menu entries in TeXinfo?
460 @subsection Why auto-expire and total-expire?
462 When reading mail, by default Gnus marks as read each message that you
463 read. If you want to mark it as expirable, you have to hit @kbd{E}.
464 Many people are subscribed to mailing lists and they configure Gnus to
465 put mails from a mailing list into their own group. Most messages in
466 such groups should be expirable, once read. But hitting @kbd{E} all the
467 gets old real quick. Hence, auto-expire and total-expire were invented.
470 @subsection Auto-expire vs.@ total-expire
472 Auto-expire and total-expire both aim at the same goal: articles which
473 are read should normally be expired, only if one does something special
474 should these articles be saved on disk. But what happens when a message
475 is being read by you, the user? Well, the message is marked as read
476 (with the `R' mark). So, what can be done to make these messages
477 expire? Well, two approaches come to mind: one idea is to change the
478 mark that is attached to messages that you read, and the other idea is
479 to make the `R' articles expirable. These are @emph{exactly} the things
480 that are done in Gnus: auto-expire means to change the mark that is
481 attached to a message that is being read, and total-expire means to
482 change the meaning of the `R' mark to mean expirable.
484 A more precise description of auto-expire might be the following: If an
485 article is unmarked and then selected for reading,@footnote{Using
486 @kbd{g}, or @kbd{@key{mouse-2}}, or by moving to it with @kbd{n} or
487 @kbd{p}, or by one of the many other methods provided by Gnus.} it is
488 marked with `E', as if the user had hit @kbd{E}.
490 It is important to realize that auto-expire has @emph{no other}
491 consequences. Selecting a message for reading which wasn't unmarked
492 doesn't do anything special, and hitting @kbd{d} on a message also
493 doesn't do anything special. (It therefore marks the message as read,
496 Now, forget about auto-expire, empty your mind and prepare to learn
497 about total-expire. Like I said, total-expire changes what it means for
498 an article to be marked as read.
500 A more precise description of total-expire might be the following: When
501 the expire process is run (for example, when you leave a group with
502 @kbd{q}), all messages marked as read are considered to be expirable, as
503 if they had been marked with `E'. Recall that there are several ways to
504 mark a message as read: by reading it, by hitting @kbd{d} on it, and in
505 a few other ways which I haven't mentioned so far. Recall that, in
506 addition to the messages marked with `R', also those marked with `r' or
507 `O' are considered to be marked as read.
509 Can auto-expire and total-expire be used together? Well, in principle
510 they can, but that doesn't make sense. Just using total-expire alone
511 achieves the same effect.
513 So, how do auto-expire and total-expire compare? Well, for once thing,
514 hitting @kbd{d} on a message means it is expirable if total-expire is
515 on (since it is marked as read and all messages marked as read are
516 considered expirable when total-expire is on), but it is not expirable
517 if auto-expire is on (since it is marked as read and only articles
518 marked expirable (`E') are considered to be expirable). If you want to
519 mark a message as expirable when total-expire is off, use @kbd{E}.
521 One way of comparing auto-expire and total-expire is to compare the
522 message marks that are available, and what they mean. Since auto-expire
523 does not change the meaning of marks, its behavior is the same as in the
524 default case. It's only important whether total-expire is on or off.
525 Thus, there are only two cases: the default case and the total-expire
528 @subsubsection Article marks with and without total-expire
530 The following are the default article marks and behavior:
534 All new messages are unmarked. This means you haven't seen them. They
535 are always shown and won't be deleted.
538 Messages marked as read are not shown by default but kept on disk till
539 hell freezes over. You can show them with @kbd{C-u M-g} from the
540 summary buffer, or with @kbd{C-u @key{SPC}} or with the `Group' menu
541 item `See old articles' from the group buffer.
543 Depending on the setting of @var{gnus-fetch-old-headers}, a message
544 marked as read might be shown if there is a followup or reply to it.
547 Dormant messages aren't shown by default but kept on disk till hell
548 freezes over. You can show them with @kbd{/ D} from the summary buffer.
549 If there is a reply or followup to a dormant message, the dormant
550 message is also shown.
553 Ticked messages are always shown and kept on disk till hell freezes
557 Expirable messages will be deleted in due time. They are not shown by
558 default, but you can make them appear with @kbd{C-u M-g} and so on,
559 similar to the read ones.
563 Please note that the behavior for ticked messages is similar to the
564 unread ones, and that the behavior of dormant messages is similar to the
565 read ones. Especially the second fact will become important when we
568 The behavior of the article marks with total-expire:
572 Same as in the default case.
575 Same as in the default case.
581 Same as in the default case.
584 Same as in the default case.
588 As you can see, only the behavior of the read messages is different, and
589 you can use the dormant mark if you want to achieve behavior similar to
590 the behavior of read messages in the default case.
593 @subsubsection Speed issues
595 Total-expire may be slow when expiry happens. Why is that? Well, Gnus
596 keeps an explicit list of all expirable messages (the ones marked `E'
597 without taking total-expire into account), as well as a list of dormant
598 messages, and a list of ticked messages. Normally, when expiration time
599 comes, Gnus goes through all articles in the expire list and looks if
600 they are old enough to be expired.
602 However, for read messages the situation is different. Here, Gnus just
603 keeps a list of ranges of article numbers to be able to distinguish read
604 messages from unmarked ones. The assumption is that a message is to be
605 considered marked as read if it falls in one of the ranges and isn't
606 mentioned in any of the expirable, dormant or ticked lists.
608 When total-expire is turned on, Gnus needs to go through all messages in
609 the read range in order to look if it's in one of the lists. If the
610 message is not in the ticked or dormant list, it is expirable and thus
611 Gnus looks to see if it is old enough.
613 Obviously, going through all the articles in the read ranges takes more
614 time than going through just the list of expirable articles.
616 Something can be done about the speed issue, though. Normally, the
617 expiry process is started whenever you leave a group. I suggest that
618 you disable this and instead run expiry just once per day, for example
619 while you are going for lunch. This means that expiry still takes a
620 long time, but you don't see it and thus it doesn't bother you.
622 Here's how to do that: You disable the expire-on-group-exit thing with
623 the following line in your @file{~/.gnus} file:
625 (remove-hook 'gnus-summary-prepare-exit-hook
626 'gnus-summary-expire-articles)
628 And before you leave for lunch, you hit @kbd{C-M-x}, or @kbd{M-x
629 gnus-group-expire-all-groups @key{RET}}.
632 @subsubsection Functionality
634 Adaptive scoring doesn't work with auto-expire. (But normal scoring
635 still works fine.) Adaptive scoring works fine with total-expire.
638 @subsubsection A summary
640 Well, it is difficult to sum up the whole discussion. I used to use
641 total-expire but have switched to auto-expire a long time ago. I liked
642 the fact that I could use one more kind of article mark. I also liked
643 the fact that marking a message as read works the same in auto-expirable
644 groups and in normal mail groups: you hit @kbd{E}. (With total-expire,
645 you normally hit @kbd{d} but must remember to use @kbd{E} for those
646 groups where total-expire is off.) And I liked that auto-expire is
649 On the other hand, adaptive scoring is surely a very useful feature (I'm
650 just beginning to use it), so many people might prefer total-expire.
652 And on a third hand, maybe the key binding issue isn't so important
653 after all. You see, in mail groups the @kbd{d} key means `keep this
654 message for archival purposes', whereas in many other modes (dired, CCC
655 others?) it stands for `delete'. I propose to make it mean delete in
656 mail groups, too, with the following line in
657 @file{~/.gnus}:@footnote{See the chapter on key bindings; maybe you need
658 a `require' statement.}
660 (define-key gnus-summary-mode-map "d" 'gnus-summary-mark-as-expirable)
662 Marking messages as expirable (rather than read) in news groups does no
663 harm, nor does it harm to do so in total-expirable mail groups. The old
664 `keep this message' semantics can still be had by marking a message as
665 dormant or by using @kbd{M r} (in non-total-expirable groups only).
668 @c ------------------------------------------------------------
669 @section Migrating old mail
670 @c ------------------------------------------------------------
672 Probably, you've been reading mail in pre-Gnus times, right? And surely
673 you wish to carry this over to Gnus. Well, I haven't found a real good
674 way to do it, but I can offer a few suggestions for doing it at least
677 One way of getting at your old mail is to type @kbd{G f}, and to then
678 enter the name of your old mail file. This provides read-only access to
679 your mails. For some people, this might be sufficient. (With @kbd{G
680 f}, you have created an @code{nndoc} group.)
682 Some people might want to have their mails available in their normal
683 mail groups hierarchy. That's simple, just create an @code{nndoc} group
684 for your mail file, then mark all messages in it with @kbd{M P a}, then
685 copy all of them over to a normal mail group, with @kbd{B c}.
687 This is good for people who wish to keep their old arrangement of
688 folders, and who have a one-to-one correspondence between old mail files
689 and new Gnus groups. But some people might wish to split up their mails
690 differently. For them, it might be useful to set up
691 @var{nnmail-split-methods} correctly and to use @kbd{B r} instead of
692 @kbd{B c}. This goes through all process-marked messages and subjects
693 them to the same splitting process that newly arriving messages go
694 through. (Whee! What a run-on sentence!)
701 Say something about the cache. Though this belongs in the news reading
707 @c TeX-master: "tutorials.texi"