This is ../info/gnus, produced by makeinfo version 4.3 from gnus.texi. INFO-DIR-SECTION Emacs START-INFO-DIR-ENTRY * Gnus: (gnus). The newsreader Gnus. END-INFO-DIR-ENTRY This file documents Gnus, the GNU Emacs newsreader. Copyright (C) 1995,96,97,98,99,2000,2001 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being none, with the Front-Cover texts being "A GNU Manual", and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled "GNU Free Documentation License" in the Emacs manual. (a) The FSF's Back-Cover Text is: "You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development." This document is part of a collection distributed under the GNU Free Documentation License. If you want to distribute this document separately from the collection, you can do so by adding a copy of the license to the document, as described in section 6 of the license.  File: gnus, Node: Fetching Mail, Prev: Mail Source Customization, Up: Mail Sources Fetching Mail ............. The way to actually tell Gnus where to get new mail from is to set `mail-sources' to a list of mail source specifiers (*note Mail Source Specifiers::). If this variable (and the obsolescent `nnmail-spool-file') is `nil', the mail back ends will never attempt to fetch mail by themselves. If you want to fetch mail both from your local spool as well as a POP mail server, you'd say something like: (setq mail-sources '((file) (pop :server "pop3.mail.server" :password "secret"))) Or, if you don't want to use any of the keyword defaults: (setq mail-sources '((file :path "/var/spool/mail/user-name") (pop :server "pop3.mail.server" :user "user-name" :port "pop3" :password "secret"))) When you use a mail back end, Gnus will slurp all your mail from your inbox and plonk it down in your home directory. Gnus doesn't move any mail if you're not using a mail back end--you have to do a lot of magic invocations first. At the time when you have finished drawing the pentagram, lightened the candles, and sacrificed the goat, you really shouldn't be too surprised when Gnus moves your mail.  File: gnus, Node: Mail Back End Variables, Next: Fancy Mail Splitting, Prev: Mail Sources, Up: Getting Mail Mail Back End Variables ----------------------- These variables are (for the most part) pertinent to all the various mail back ends. `nnmail-read-incoming-hook' The mail back ends all call this hook after reading new mail. You can use this hook to notify any mail watch programs, if you want to. `nnmail-split-hook' Hook run in the buffer where the mail headers of each message is kept just before the splitting based on these headers is done. The hook is free to modify the buffer contents in any way it sees fit--the buffer is discarded after the splitting has been done, and no changes performed in the buffer will show up in any files. `gnus-article-decode-encoded-words' is one likely function to add to this hook. `nnmail-pre-get-new-mail-hook' `nnmail-post-get-new-mail-hook' These are two useful hooks executed when treating new incoming mail--`nnmail-pre-get-new-mail-hook' (is called just before starting to handle the new mail) and `nnmail-post-get-new-mail-hook' (is called when the mail handling is done). Here's and example of using these two hooks to change the default file modes the new mail files get: (add-hook 'gnus-pre-get-new-mail-hook (lambda () (set-default-file-modes 511))) (add-hook 'gnus-post-get-new-mail-hook (lambda () (set-default-file-modes 551))) `nnmail-use-long-file-names' If non-`nil', the mail back ends will use long file and directory names. Groups like `mail.misc' will end up in directories (assuming use of `nnml' back end) or files (assuming use of `nnfolder' back end) like `mail.misc'. If it is `nil', the same group will end up in `mail/misc'. `nnmail-delete-file-function' Function called to delete files. It is `delete-file' by default. `nnmail-cache-accepted-message-ids' If non-`nil', put the `Message-ID's of articles imported into the back end (via `Gcc', for instance) into the mail duplication discovery cache. The default is `nil'.  File: gnus, Node: Fancy Mail Splitting, Next: Group Mail Splitting, Prev: Mail Back End Variables, Up: Getting Mail 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") "mail.misc")) ;; 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") ;; Both lists below have the same suffix, so prevent ;; cross-posting to mkpkg.list of messages posted only to ;; the bugs- list, but allow cross-posting when the ;; message was really cross-posted. (any "bugs-mypackage@somewhere" "mypkg.bugs") (any "mypackage@somewhere\" - "bugs-mypackage" "mypkg.list") ;; People... (any "larsi@ifi\\.uio\\.no" "people.Lars_Magne_Ingebrigtsen")) ;; Unmatched mail goes to the catch all group. "misc.misc") 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 five possible split syntaxes: 1. `group': If the split is a string, that will be taken as a group name. Normal regexp match expansion will be done. See below for examples. 2. `(FIELD VALUE `[-' RESTRICT `[...]'`]' SPLIT)': If the split is a list, the first element of which is a string, then store the message as specified by SPLIT, if header FIELD (a regexp) contains VALUE (also a regexp). If RESTRICT (yet another regexp) matches some string after FIELD and before the end of the matched VALUE, the SPLIT is ignored. If none of the RESTRICT clauses match, SPLIT is processed. 3. `(| 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. 4. `(& SPLIT...)': If the split is a list, and the first element is `&', then process all SPLITs in the list. 5. `junk': If the split is the symbol `junk', then don't save this message. Use with extreme caution. 6. `(: FUNCTION ARG1 ARG2 ...)': If the split is a list, and the first element is `:', then the second element will be called as a function with ARGS given as arguments. The function should return a SPLIT. For instance, the following function could be used to split based on the body of the messages: (defun split-on-body () (save-excursion (set-buffer " *nnmail incoming*") (goto-char (point-min)) (when (re-search-forward "Some.*string" nil t) "string.group"))) 7. `(! FUNC SPLIT)': If the split is a list, and the first element is `!', then SPLIT will be processed, and FUNC will be called as a function with the result of SPLIT as argument. FUNC should return a split. 8. `nil': If the split is `nil', it is ignored. 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. In other words, all VALUE's are wrapped in `\<' and `\>' pairs. 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 a cell contains the key, and the `cdr' contains the associated value. `nnmail-split-fancy-syntax-table' is the syntax table in effect when all this splitting is performed. If you want to have Gnus create groups dynamically based on some information in the headers (i.e., do `replace-match'-like substitutions in the group names), you can say things like: (any "debian-\\b\\(\\w+\\)@lists.debian.org" "mail.debian.\\1") In this example, messages sent to `debian-foo@lists.debian.org' will be filed in `mail.debian.foo'. If the string contains the element `\&', then the previously matched string will be substituted. Similarly, the elements `\\1' up to `\\9' will be substituted with the text matched by the groupings 1 through 9. `nnmail-split-fancy-with-parent' is a function which allows you to split followups into the same groups their parents are in. Sometimes you can't make splitting rules for all your mail. For example, your boss might send you personal mail regarding different projects you are working on, and as you can't tell your boss to put a distinguishing string into the subject line, you have to resort to manually moving the messages into the right group. With this function, you only have to do it once per thread. To use this feature, you have to set `nnmail-treat-duplicates' to a non-nil value. And then you can include `nnmail-split-fancy-with-parent' using the colon feature, like so: (setq nnmail-split-fancy '(| (: nnmail-split-fancy-with-parent) ;; other splits go here )) This feature works as follows: when `nnmail-treat-duplicates' is non-nil, Gnus records the message id of every message it sees in the file specified by the variable `nnmail-message-id-cache-file', together with the group it is in (the group is omitted for non-mail messages). When mail splitting is invoked, the function `nnmail-split-fancy-with-parent' then looks at the References (and In-Reply-To) header of each message to split and searches the file specified by `nnmail-message-id-cache-file' for the message ids. When it has found a parent, it returns the corresponding group name. It is recommended that you set `nnmail-message-id-cache-length' to a somewhat higher number than the default so that the message ids are still in the cache. (A value of 5000 appears to create a file some 300 kBytes in size.) When `nnmail-cache-accepted-message-ids' is non-`nil', Gnus also records the message ids of moved articles, so that the followup messages goes into the new group.  File: gnus, Node: Group Mail Splitting, Next: Incorporating Old Mail, Prev: Fancy Mail Splitting, Up: Getting Mail Group Mail Splitting -------------------- If you subscribe to dozens of mailing lists but you don't want to maintain mail splitting rules manually, group mail splitting is for you. You just have to set TO-LIST and/or TO-ADDRESS in group parameters or group customization and set `nnmail-split-methods' to `gnus-group-split'. This splitting function will scan all groups for those parameters and split mail accordingly, i.e., messages posted from or to the addresses specified in the parameters TO-LIST or TO-ADDRESS of a mail group will be stored in that group. Sometimes, mailing lists have multiple addresses, and you may want mail splitting to recognize them all: just set the EXTRA-ALIASES group parameter to the list of additional addresses and it's done. If you'd rather use a regular expression, set SPLIT-REGEXP. All these parameters in a group will be used to create an `nnmail-split-fancy' split, in which the FIELD is `any', the VALUE is a single regular expression that matches TO-LIST, TO-ADDRESS, all of EXTRA-ALIASES and all matches of SPLIT-REGEXP, and the SPLIT is the name of the group. RESTRICTs are also supported: just set the SPLIT-EXCLUDE parameter to a list of regular expressions. If you can't get the right split to be generated using all these parameters, or you just need something fancier, you can set the parameter SPLIT-SPEC to an `nnmail-split-fancy' split. In this case, all other aforementioned parameters will be ignored by `gnus-group-split'. In particular, SPLIT-SPEC may be set to `nil', in which case the group will be ignored by `gnus-group-split'. `gnus-group-split' will do cross-posting on all groups that match, by defining a single `&' fancy split containing one split for each group. If a message doesn't match any split, it will be stored in the group named in `gnus-group-split-default-catch-all-group', unless some group has SPLIT-SPEC set to `catch-all', in which case that group is used as the catch-all group. Even though this variable is often used just to name a group, it may also be set to an arbitrarily complex fancy split (after all, a group name is a fancy split), and this may be useful to split mail that doesn't go to any mailing list to personal mail folders. Note that this fancy split is added as the last element of a `|' split list that also contains a `&' split with the rules extracted from group parameters. It's time for an example. Assume the following group parameters have been defined: nnml:mail.bar: ((to-address . "bar@femail.com") (split-regexp . ".*@femail\\.com")) nnml:mail.foo: ((to-list . "foo@nowhere.gov") (extra-aliases "foo@localhost" "foo-redist@home") (split-exclude "bugs-foo" "rambling-foo") (admin-address . "foo-request@nowhere.gov")) nnml:mail.others: ((split-spec . catch-all)) Setting `nnmail-split-methods' to `gnus-group-split' will behave as if `nnmail-split-fancy' had been selected and variable `nnmail-split-fancy' had been set as follows: (| (& (any "\\(bar@femail\\.com\\|.*@femail\\.com\\)" "mail.bar") (any "\\(foo@nowhere\\.gov\\|foo@localhost\\|foo-redist@home\\)" - "bugs-foo" - "rambling-foo" "mail.foo")) "mail.others") If you'd rather not use group splitting for all your mail groups, you may use it for only some of them, by using `nnmail-split-fancy' splits like this: (: gnus-mlsplt-fancy GROUPS NO-CROSSPOST CATCH-ALL) GROUPS may be a regular expression or a list of group names whose parameters will be scanned to generate the output split. NO-CROSSPOST can be used to disable cross-posting; in this case, a single `|' split will be output. CATCH-ALL is the fallback fancy split, used like GNUS-GROUP-SPLIT-DEFAULT-CATCH-ALL-GROUP. If CATCH-ALL is `nil', or if SPLIT-REGEXP matches the empty string in any selected group, no catch-all split will be issued. Otherwise, if some group has SPLIT-SPEC set to `catch-all', this group will override the value of the CATCH-ALL argument. Unfortunately, scanning all groups and their parameters can be quite slow, especially considering that it has to be done for every message. But don't despair! The function `gnus-group-split-setup' can be used to enable `gnus-group-split' in a much more efficient way. It sets `nnmail-split-methods' to `nnmail-split-fancy' and sets `nnmail-split-fancy' to the split produced by `gnus-group-split-fancy'. Thus, the group parameters are only scanned once, no matter how many messages are split. However, if you change group parameters, you have to update `nnmail-split-fancy' manually. You can do it by running `gnus-group-split-update'. If you'd rather have it updated automatically, just tell `gnus-group-split-setup' to do it for you. For example, add to your `.gnus': (gnus-group-split-setup AUTO-UPDATE CATCH-ALL) If AUTO-UPDATE is non-`nil', `gnus-group-split-update' will be added to `nnmail-pre-get-new-mail-hook', so you won't ever have to worry about updating `nnmail-split-fancy' again. If you don't omit CATCH-ALL (it's optional, equivalent to `nil'), `gnus-group-split-default-catch-all-group' will be set to its value. Because you may want to change `nnmail-split-fancy' after it is set by `gnus-group-split-update', this function will run `gnus-group-split-updated-hook' just before finishing.  File: gnus, Node: Incorporating Old Mail, Next: Expiring Mail, Prev: Group Mail Splitting, Up: Getting Mail Incorporating Old Mail ---------------------- Most people have lots of old mail stored in various file formats. If you have set up Gnus to read mail using one of the spiffy Gnus mail back ends, you'll probably wish to have that old mail incorporated into your mail groups. Doing so can be quite easy. To take an example: You're reading mail using `nnml' (*note Mail Spool::), and have set `nnmail-split-methods' to a satisfactory value (*note Splitting Mail::). You have an old Unix mbox file filled with important, but old, mail. You want to move it into your `nnml' groups. Here's how: 1. Go to the group buffer. 2. Type `G f' and give the path to the mbox file when prompted to create an `nndoc' group from the mbox file (*note Foreign Groups::). 3. Type to enter the newly created group. 4. Type `M P b' to process-mark all articles in this group's buffer (*note Setting Process Marks::). 5. Type `B r' to respool all the process-marked articles, and answer `nnml' when prompted (*note Mail Group Commands::). All the mail messages in the mbox file will now also be spread out over all your `nnml' groups. Try entering them and check whether things have gone without a glitch. If things look ok, you may consider deleting the mbox file, but I wouldn't do that unless I was absolutely sure that all the mail has ended up where it should be. Respooling is also a handy thing to do if you're switching from one mail back end to another. Just respool all the mail in the old mail groups using the new mail back end.  File: gnus, Node: Expiring Mail, Next: Washing Mail, Prev: Incorporating Old Mail, Up: Getting Mail Expiring Mail ------------- 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 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' 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 groups 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 (*note 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. Gnus starts counting days from when the message _arrived_, not from when it was sent. 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") 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. The `nnmail-expiry-wait' variable and `nnmail-expiry-wait-function' function can either be a number (not necessarily an integer) or one of the symbols `immediate' or `never'. You can also use the `expiry-wait' group parameter to selectively change the expiry period (*note 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") 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.  File: gnus, Node: Washing Mail, Next: Duplicates, Prev: Expiring Mail, Up: Getting Mail Washing Mail ------------ Mailers and list servers are notorious for doing all sorts of really, really stupid things with mail. "Hey, RFC 822 doesn't explicitly prohibit us from adding the string `wE aRe ElItE!!!!!1!!' to the end of all lines passing through our server, so let's do that!!!!1!" Yes, but RFC 822 wasn't designed to be read by morons. Things that were considered to be self-evident were not discussed. So. Here we are. Case in point: The German version of Microsoft Exchange adds `AW: ' to the subjects of replies instead of `Re: '. I could pretend to be shocked and dismayed by this, but I haven't got the energy. It is to laugh. Gnus provides a plethora of functions for washing articles while displaying them, but it might be nicer to do the filtering before storing the mail to disc. For that purpose, we have three hooks and various functions that can be put in these hooks. `nnmail-prepare-incoming-hook' This hook is called before doing anything with the mail and is meant for grand, sweeping gestures. It is called in a buffer that contains all the new, incoming mail. Functions to be used include: `nnheader-ms-strip-cr' Remove trailing carriage returns from each line. This is default on Emacs running on MS machines. `nnmail-prepare-incoming-header-hook' This hook is called narrowed to each header. It can be used when cleaning up the headers. Functions that can be used include: `nnmail-remove-leading-whitespace' Clear leading white space that "helpful" listservs have added to the headers to make them look nice. Aaah. `nnmail-remove-list-identifiers' Some list servers add an identifier--for example, `(idm)'--to the beginning of all `Subject' headers. I'm sure that's nice for people who use stone age mail readers. This function will remove strings that match the `nnmail-list-identifiers' regexp, which can also be a list of regexp. `nnmail-list-identifiers' may not contain `\\(..\\)'. For instance, if you want to remove the `(idm)' and the `nagnagnag' identifiers: (setq nnmail-list-identifiers '("(idm)" "nagnagnag")) This can also be done non-destructively with `gnus-list-identifiers', *Note Article Hiding::. `nnmail-remove-tabs' Translate all tab characters into space characters. `nnmail-fix-eudora-headers' Eudora produces broken `References' headers, but OK `In-Reply-To' headers. This function will get rid of the `References' headers. `nnmail-prepare-incoming-message-hook' This hook is called narrowed to each message. Functions to be used include: `article-de-quoted-unreadable' Decode Quoted Readable encoding.  File: gnus, Node: Duplicates, Next: Not Reading Mail, Prev: Washing Mail, Up: Getting Mail Duplicates ---------- If you are a member of a couple of mailing lists, you will sometimes receive two copies of the same mail. This can be quite annoying, so `nnmail' checks for and treats any duplicates it might find. To do this, it keeps a cache of old `Message-ID's-- `nnmail-message-id-cache-file', which is `~/.nnmail-cache' by default. The approximate maximum number of `Message-ID's stored there is controlled by the `nnmail-message-id-cache-length' variable, which is 1000 by default. (So 1000 `Message-ID's will be stored.) If all this sounds scary to you, you can set `nnmail-treat-duplicates' to `warn' (which is what it is by default), and `nnmail' won't delete duplicate mails. Instead it will insert a warning into the head of the mail saying that it thinks that this is a duplicate of a different message. This variable can also be a function. If that's the case, the function will be called from a buffer narrowed to the message in question with the `Message-ID' as a parameter. The function must return either `nil', `warn', or `delete'. You can turn this feature off completely by setting the variable to `nil'. If you want all the duplicate mails to be put into a special "duplicates" group, you could do that using the normal mail split methods: (setq nnmail-split-fancy '(| ;; Messages duplicates go to a separate group. ("gnus-warning" "duplication of message" "duplicate") ;; Message from daemons, postmaster, and the like to another. (any mail "mail.misc") ;; Other rules. [ ... ] )) Or something like: (setq nnmail-split-methods '(("duplicates" "^Gnus-Warning:") ;; Other rules. [...])) Here's a neat feature: If you know that the recipient reads her mail with Gnus, and that she has `nnmail-treat-duplicates' set to `delete', 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!  File: gnus, Node: Not Reading Mail, Next: Choosing a Mail Back End, Prev: Duplicates, Up: Getting Mail Not Reading Mail ---------------- If you start using any of the mail back ends, 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 `mail-sources' and `nnmail-spool-file' to `nil', none of the back ends 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 back ends have variables called back-end-`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 back ends will call `nn'*`-prepare-save-mail-hook' narrowed to the article to be saved before saving it when reading incoming mail.  File: gnus, Node: Choosing a Mail Back End, Prev: Not Reading Mail, Up: Getting Mail Choosing a Mail Back End ------------------------ 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. There are five different mail back ends in the standard Gnus, and more back ends are available separately. The mail back end most people use (because it is the fastest and most flexible) is `nnml' (*note Mail Spool::). * Menu: * Unix Mail Box:: Using the (quite) standard Un*x mbox. * Rmail Babyl:: Emacs programs use the rmail babyl format. * Mail Spool:: Store your mail in a private spool? * MH Spool:: An mhspool-like back end. * Mail Folders:: Having one file for each group. * Comparing Mail Back Ends:: An in-depth looks at pros and cons.  File: gnus, Node: Unix Mail Box, Next: Rmail Babyl, Up: Choosing a Mail Back End Unix Mail Box ............. The "nnmbox" back end 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: `nnmbox-mbox-file' The name of the mail box in the user's home directory. `nnmbox-active-file' The name of the active file for the mail box. `nnmbox-get-new-mail' If non-`nil', `nnmbox' will read incoming mail and split it into groups.  File: gnus, Node: Rmail Babyl, Next: Mail Spool, Prev: Unix Mail Box, Up: Choosing a Mail Back End Rmail Babyl ........... The "nnbabyl" back end 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: `nnbabyl-mbox-file' The name of the rmail mbox file. `nnbabyl-active-file' The name of the active file for the rmail box. `nnbabyl-get-new-mail' If non-`nil', `nnbabyl' will read incoming mail.  File: gnus, Node: Mail Spool, Next: MH Spool, Prev: Rmail Babyl, Up: Choosing a Mail Back End Mail Spool .......... The "nnml" spool mail format isn't compatible with any other known format. It should be used with some caution. If you use this back end, Gnus will split all incoming mail into files, one file for each mail, and put the articles into the corresponding 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 back end. 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 back end 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 it the fastest back end when it comes to reading mail. Virtual server settings: `nnml-directory' All `nnml' directories will be placed under this directory. `nnml-active-file' The active file for the `nnml' server. `nnml-newsgroups-file' The `nnml' group descriptions file. *Note Newsgroups File Format::. `nnml-get-new-mail' If non-`nil', `nnml' will read incoming mail. `nnml-nov-is-evil' If non-`nil', this back end will ignore any NOV files. `nnml-nov-file-name' The name of the NOV files. The default is `.overview'. `nnml-prepare-save-mail-hook' Hook run narrowed to an article before saving. 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. A better interface to this functionality can be found in the server buffer (*note Server Commands::).  File: gnus, Node: MH Spool, Next: Mail Folders, Prev: Mail Spool, Up: Choosing a Mail Back End MH Spool ........ `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 back end than `nnml', but it also makes it easier to write procmail scripts for. Virtual server settings: `nnmh-directory' All `nnmh' directories will be located under this directory. `nnmh-get-new-mail' If non-`nil', `nnmh' will read incoming mail. `nnmh-be-safe' If non-`nil', `nnmh' will go to ridiculous lengths to make sure that the articles in the folder are actually what Gnus thinks 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 but Gnus to read the `nnmh' articles, you do not have to set this variable to `t'.  File: gnus, Node: Mail Folders, Next: Comparing Mail Back Ends, Prev: MH Spool, Up: Choosing a Mail Back End Mail Folders ............ `nnfolder' is a back end 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: `nnfolder-directory' All the `nnfolder' mail boxes will be stored under this directory. `nnfolder-active-file' The name of the active file. `nnfolder-newsgroups-file' The name of the group descriptions file. *Note Newsgroups File Format::. `nnfolder-get-new-mail' If non-`nil', `nnfolder' will read incoming mail. `nnfolder-save-buffer-hook' Hook run before saving the folders. Note that Emacs does the normal backup renaming of files even with the `nnfolder' buffers. If you wish to switch this off, you could say something like the following in your `.emacs' file: (defun turn-off-backup () (set (make-local-variable 'backup-inhibited) t)) (add-hook 'nnfolder-save-buffer-hook 'turn-off-backup) `nnfolder-delete-mail-hook' Hook run in a buffer narrowed to the message that is to be deleted. This function can be used to copy the message to somewhere else, or to extract some information from it before removing it. If you have lots of `nnfolder'-like files you'd like to read with `nnfolder', you can use the `M-x nnfolder-generate-active-file' command to make `nnfolder' aware of all likely files in `nnfolder-directory'. This only works if you use long file names, though.  File: gnus, Node: Comparing Mail Back Ends, Prev: Mail Folders, Up: Choosing a Mail Back End Comparing Mail Back Ends ........................ First, just for terminology, the "back end" is the common word for a low-level access method--a transport, if you will, by which something is acquired. The sense is that one's mail has to come from somewhere, and so selection of a suitable back end is required in order to get that mail within spitting distance of Gnus. The same concept exists for Usenet itself: Though access to articles is typically done by NNTP these days, once upon a midnight dreary, everyone in the world got at Usenet by running a reader on the machine where the articles lay (the machine which today we call an NNTP server), and access was by the reader stepping into the articles' directory spool area directly. One can still select between either the `nntp' or `nnspool' back ends, to select between these methods, if one happens actually to live on the server (or can see its spool directly, anyway, via NFS). The goal in selecting a mail back end is to pick one which simultaneously represents a suitable way of dealing with the original format plus leaving mail in a form that is convenient to use in the future. Here are some high and low points on each: `nnmbox' UNIX systems have historically had a single, very common, and well- defined format. All messages arrive in a single "spool file", and they are delineated by a line whose regular expression matches `^From_'. (My notational use of `_' is to indicate a space, to make it clear in this instance that this is not the RFC-specified `From:' header.) Because Emacs and therefore Gnus emanate historically from the Unix environment, it is simplest if one does not mess a great deal with the original mailbox format, so if one chooses this back end, Gnus' primary activity in getting mail from the real spool area to Gnus' preferred directory is simply to copy it, with no (appreciable) format change in the process. It is the "dumbest" way to move mail into availability in the Gnus environment. This makes it fast to move into place, but slow to parse, when Gnus has to look at what's where. `nnbabyl' Once upon a time, there was the DEC-10 and DEC-20, running operating systems called TOPS and related things, and the usual (only?) mail reading environment was a thing called Babyl. I don't know what format was used for mail landing on the system, but Babyl had its own internal format to which mail was converted, primarily involving creating a spool-file-like entity with a scheme for inserting Babyl-specific headers and status bits above the top of each message in the file. RMAIL was Emacs' first mail reader, it was written by Richard Stallman, and Stallman came out of that TOPS/Babyl environment, so he wrote RMAIL to understand the mail files folks already had in existence. Gnus (and VM, for that matter) continue to support this format because it's perceived as having some good qualities in those mailer-specific headers/status bits stuff. RMAIL itself still exists as well, of course, and is still maintained by Stallman. Both of the above forms leave your mail in a single file on your filesystem, and they must parse that entire file each time you take a look at your mail. `nnml' `nnml' is the back end which smells the most as though you were actually operating with an `nnspool'-accessed Usenet system. (In fact, I believe `nnml' actually derived from `nnspool' code, lo these years ago.) One's mail is taken from the original spool file, and is then cut up into individual message files, 1:1. It maintains a Usenet-style active file (analogous to what one finds in an INN- or CNews-based news system in (for instance) `/var/lib/news/active', or what is returned via the `NNTP LIST' verb) and also creates "overview" files for efficient group entry, as has been defined for NNTP servers for some years now. It is slower in mail-splitting, due to the creation of lots of files, updates to the `nnml' active file, and additions to overview files on a per-message basis, but it is extremely fast on access because of what amounts to the indexing support provided by the active file and overviews. `nnml' costs "inodes" in a big way; that is, it soaks up the resource which defines available places in the filesystem to put new files. Sysadmins take a dim view of heavy inode occupation within tight, shared filesystems. But if you live on a personal machine where the filesystem is your own and space is not at a premium, `nnml' wins big. It is also problematic using this back end if you are living in a FAT16-based Windows world, since much space will be wasted on all these tiny files. `nnmh' The Rand MH mail-reading system has been around UNIX systems for a very long time; it operates by splitting one's spool file of messages into individual files, but with little or no indexing support - `nnmh' is considered to be semantically equivalent to "`nnml' without active file or overviews". This is arguably the worst choice, because one gets the slowness of individual file creation married to the slowness of access parsing when learning what's new in one's groups. `nnfolder' Basically the effect of `nnfolder' is `nnmbox' (the first method described above) on a per-group basis. That is, `nnmbox' itself puts *all* one's mail in one file; `nnfolder' provides a little bit of optimization to this so that each of one's mail groups has a Unix mail box file. It's faster than `nnmbox' because each group can be parsed separately, and still provides the simple Unix mail box format requiring minimal effort in moving the mail around. In addition, it maintains an "active" file making it much faster for Gnus to figure out how many messages there are in each separate group. If you have groups that are expected to have a massive amount of messages, `nnfolder' is not the best choice, but if you receive only a moderate amount of mail, `nnfolder' is probably the most friendly mail back end all over.  File: gnus, Node: Browsing the Web, Next: Other Sources, Prev: Getting Mail, Up: Select Methods Browsing the Web ================ Web-based discussion forums are getting more and more popular. On many subjects, the web-based forums have become the most important forums, eclipsing the importance of mailing lists and news groups. The reason is easy to understand--they are friendly to new users; you just point and click, and there's the discussion. With mailing lists, you have to go through a cumbersome subscription procedure, and most people don't even know what a news group is. The problem with this scenario is that web browsers are not very good at being newsreaders. They do not keep track of what articles you've read; they do not allow you to score on subjects you're interested in; they do not allow off-line browsing; they require you to click around and drive you mad in the end. So--if web browsers suck at reading discussion forums, why not use Gnus to do it instead? Gnus has been getting a bit of a collection of back ends for providing interfaces to these sources. * Menu: * Web Searches:: Creating groups from articles that match a string. * Slashdot:: Reading the Slashdot comments. * Ultimate:: The Ultimate Bulletin Board systems. * Web Archive:: Reading mailing list archived on web. * Customizing w3:: Doing stuff to Emacs/w3 from Gnus. All the web sources require Emacs/w3 and the url library to work. The main caveat with all these web sources is that they probably won't work for a very long time. Gleaning information from the HTML data is guesswork at best, and when the layout is altered, the Gnus back end will fail. If you have reasonably new versions of these back ends, though, you should be ok. One thing all these Web methods have in common is that the Web sources are often down, unavailable or just plain too slow to be fun. In those cases, it makes a lot of sense to let the Gnus Agent (*note Gnus Unplugged::) handle downloading articles, and then you can read them at leisure from your local disk. No more World Wide Wait for you.  File: gnus, Node: Web Searches, Next: Slashdot, Up: Browsing the Web Web Searches ------------ It's, like, too neat to search the Usenet for articles that match a string, but it, like, totally _sucks_, like, totally, to use one of those, like, Web browsers, and you, like, have to, rilly, like, look at the commercials, so, like, with Gnus you can do _rad_, rilly, searches without having to use a browser. The `nnweb' back end allows an easy interface to the mighty search engine. You create an `nnweb' group, enter a search pattern, and then enter the group and read the articles like you would any normal group. The `G w' command in the group buffer (*note Foreign Groups::) will do this in an easy-to-use fashion. `nnweb' groups don't really lend themselves to being solid groups--they have a very fleeting idea of article numbers. In fact, each time you enter an `nnweb' group (not even changing the search pattern), you are likely to get the articles ordered in a different manner. Not even using duplicate suppression (*note Duplicate Suppression::) will help, since `nnweb' doesn't even know the `Message-ID' of the articles before reading them using some search engines (DejaNews, for instance). The only possible way to keep track of which articles you've read is by scoring on the `Date' header--mark all articles posted before the last date you read the group as read. If the search engine changes its output substantially, `nnweb' won't be able to parse it and will fail. One could hardly fault the Web providers if they were to do this--their _raison d'être_ is to make money off of advertisements, not to provide services to the community. Since `nnweb' washes the ads off all the articles, one might think that the providers might be somewhat miffed. We'll see. You must have the `url' and `w3' package installed to be able to use `nnweb'. Virtual server variables: `nnweb-type' What search engine type is being used. The currently supported types are `dejanews', `dejanewsold', `altavista' and `reference'. `nnweb-search' The search string to feed to the search engine. `nnweb-max-hits' Advisory maximum number of hits per search to display. The default is 100. `nnweb-type-definition' Type-to-definition alist. This alist says what `nnweb' should do with the various search engine types. The following elements must be present: `article' Function to decode the article and provide something that Gnus understands. `map' Function to create an article number to message header and URL alist. `search' Function to send the search string to the search engine. `address' The address the aforementioned function should send the search string to. `id' Format string URL to fetch an article by `Message-ID'.