This is ../info/gnus, produced by makeinfo version 4.0 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 <SPC> 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'.