This is gnus, produced by makeinfo version 4.5 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, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 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: Archived Messages, Next: Posting Styles, Prev: Mail and Post, Up: Composing Messages Archived Messages ================= Gnus provides a few different methods for storing the mail and news you send. The default method is to use the "archive virtual server" to store the messages. If you want to disable this completely, the `gnus-message-archive-group' variable should be `nil', which is the default. For archiving interesting messages in a group you read, see the `B c' (`gnus-summary-copy-article') command (*note Mail Group Commands::). `gnus-message-archive-method' says what virtual server Gnus is to use to store sent messages. The default is: (nnfolder "archive" (nnfolder-directory "~/Mail/archive") (nnfolder-active-file "~/Mail/archive/active") (nnfolder-get-new-mail nil) (nnfolder-inhibit-expiry t)) You can, however, use any mail select method (`nnml', `nnmbox', etc.). `nnfolder' is a quite likable select method for doing this sort of thing, though. If you don't like the default directory chosen, you could say something like: (setq gnus-message-archive-method '(nnfolder "archive" (nnfolder-inhibit-expiry t) (nnfolder-active-file "~/News/sent-mail/active") (nnfolder-directory "~/News/sent-mail/"))) Gnus will insert `Gcc' headers in all outgoing messages that point to one or more group(s) on that server. Which group to use is determined by the `gnus-message-archive-group' variable. This variable can be used to do the following: a string Messages will be saved in that group. Note that you can include a select method in the group name, then the message will not be stored in the select method given by `gnus-message-archive-method', but in the select method specified by the group name, instead. Suppose `gnus-message-archive-method' has the default value shown above. Then setting `gnus-message-archive-group' to `"foo"' means that outgoing messages are stored in `nnfolder+archive:foo', but if you use the value `"nnml:foo"', then outgoing messages will be stored in `nnml:foo'. a list of strings Messages will be saved in all those groups. an alist of regexps, functions and forms When a key "matches", the result is used. `nil' No message archiving will take place. This is the default. Let's illustrate: Just saving to a single group called `MisK': (setq gnus-message-archive-group "MisK") Saving to two groups, `MisK' and `safe': (setq gnus-message-archive-group '("MisK" "safe")) Save to different groups based on what group you are in: (setq gnus-message-archive-group '(("^alt" "sent-to-alt") ("mail" "sent-to-mail") (".*" "sent-to-misc"))) More complex stuff: (setq gnus-message-archive-group '((if (message-news-p) "misc-news" "misc-mail"))) How about storing all news messages in one file, but storing all mail messages in one file per month: (setq gnus-message-archive-group '((if (message-news-p) "misc-news" (concat "mail." (format-time-string "%Y-%m"))))) Now, when you send a message off, it will be stored in the appropriate group. (If you want to disable storing for just one particular message, you can just remove the `Gcc' header that has been inserted.) The archive group will appear in the group buffer the next time you start Gnus, or the next time you press `F' in the group buffer. You can enter it and read the articles in it just like you'd read any other group. If the group gets really big and annoying, you can simply rename if (using `G r' in the group buffer) to something nice--`misc-mail-september-1995', or whatever. New messages will continue to be stored in the old (now empty) group. That's the default method of archiving sent messages. Gnus offers a different way for the people who don't like the default method. In that case you should set `gnus-message-archive-group' to `nil'; this will disable archiving. `gnus-outgoing-message-group' All outgoing messages will be put in this group. If you want to store all your outgoing mail and articles in the group `nnml:archive', you set this variable to that value. This variable can also be a list of group names. If you want to have greater control over what group to put each message in, you can set this variable to a function that checks the current newsgroup name and then returns a suitable group name (or list of names). This variable can be used instead of `gnus-message-archive-group', but the latter is the preferred method. `gnus-gcc-mark-as-read' If non-`nil', automatically mark `Gcc' articles as read. `gnus-gcc-externalize-attachments' If `nil', attach files as normal parts in Gcc copies; if a regexp and matches the Gcc group name, attach files as external parts; if it is `all', attach local files as external parts; if it is other non-`nil', the behavior is the same as `all', but it may be changed in the future.  File: gnus, Node: Posting Styles, Next: Drafts, Prev: Archived Messages, Up: Composing Messages Posting Styles ============== All them variables, they make my head swim. So what if you want a different `Organization' and signature based on what groups you post to? And you post both from your home machine and your work machine, and you want different `From' lines, and so on? One way to do stuff like that is to write clever hooks that change the variables you need to have changed. That's a bit boring, so somebody came up with the bright idea of letting the user specify these things in a handy alist. Here's an example of a `gnus-posting-styles' variable: ((".*" (signature "Peace and happiness") (organization "What me?")) ("^comp" (signature "Death to everybody")) ("comp.emacs.i-love-it" (organization "Emacs is it"))) As you might surmise from this example, this alist consists of several "styles". Each style will be applicable if the first element "matches", in some form or other. The entire alist will be iterated over, from the beginning towards the end, and each match will be applied, which means that attributes in later styles that match override the same attributes in earlier matching styles. So `comp.programming.literate' will have the `Death to everybody' signature and the `What me?' `Organization' header. The first element in each style is called the `match'. If it's a string, then Gnus will try to regexp match it against the group name. If it is the form `(header MATCH REGEXP)', then Gnus will look in the original article for a header whose name is MATCH and compare that REGEXP. MATCH and REGEXP are strings. (There original article is the one you are replying or following up to. If you are not composing a reply or a followup, then there is nothing to match against.) If the `match' is a function symbol, that function will be called with no arguments. If it's a variable symbol, then the variable will be referenced. If it's a list, then that list will be `eval'ed. In any case, if this returns a non-`nil' value, then the style is said to "match". Each style may contain an arbitrary amount of "attributes". Each attribute consists of a `(NAME VALUE)' pair. The attribute name can be one of `signature', `signature-file', `x-face-file', `address' (overriding `user-mail-address'), `name' (overriding `(user-full-name)') or `body'. The attribute name can also be a string or a symbol. In that case, this will be used as a header name, and the value will be inserted in the headers of the article; if the value is `nil', the header name will be removed. If the attribute name is `eval', the form is evaluated, and the result is thrown away. The attribute value can be a string (used verbatim), a function with zero arguments (the return value will be used), a variable (its value will be used) or a list (it will be `eval'ed and the return value will be used). The functions and sexps are called/`eval'ed in the message buffer that is being set up. The headers of the current article are available through the `message-reply-headers' variable, which is a vector of the following headers: number subject from date id references chars lines xref extra. If you wish to check whether the message you are about to compose is meant to be a news article or a mail message, you can check the values of the `message-news-p' and `message-mail-p' functions. So here's a new example: (setq gnus-posting-styles '((".*" (signature-file "~/.signature") (name "User Name") ("X-Home-Page" (getenv "WWW_HOME")) (organization "People's Front Against MWM")) ("^rec.humor" (signature my-funny-signature-randomizer)) ((equal (system-name) "gnarly") ;; A form (signature my-quote-randomizer)) (message-news-p ;; A function symbol (signature my-news-signature)) (window-system ;; A value symbol ("X-Window-System" (format "%s" window-system))) ;; If I'm replying to Larsi, set the Organization header. ((header "from" "larsi.*org") (Organization "Somewhere, Inc.")) ((posting-from-work-p) ;; A user defined function (signature-file "~/.work-signature") (address "user@bar.foo") (body "You are fired.\n\nSincerely, your boss.") (organization "Important Work, Inc")) ("nnml:.*" (From (save-excursion (set-buffer gnus-article-buffer) (message-fetch-field "to")))) ("^nn.+:" (signature-file "~/.mail-signature")))) The `nnml:.*' rule means that you use the `To' address as the `From' address in all your outgoing replies, which might be handy if you fill many roles.  File: gnus, Node: Drafts, Next: Rejected Articles, Prev: Posting Styles, Up: Composing Messages Drafts ====== If you are writing a message (mail or news) and suddenly remember that you have a steak in the oven (or some pesto in the food processor, you craaazy vegetarians), you'll probably wish there was a method to save the message you are writing so that you can continue editing it some other day, and send it when you feel its finished. Well, don't worry about it. Whenever you start composing a message of some sort using the Gnus mail and post commands, the buffer you get will automatically associate to an article in a special "draft" group. If you save the buffer the normal way (`C-x C-s', for instance), the article will be saved there. (Auto-save files also go to the draft group.) The draft group is a special group (which is implemented as an `nndraft' group, if you absolutely have to know) called `nndraft:drafts'. The variable `nndraft-directory' says where `nndraft' is to store its files. What makes this group special is that you can't tick any articles in it or mark any articles as read--all articles in the group are permanently unread. If the group doesn't exist, it will be created and you'll be subscribed to it. The only way to make it disappear from the Group buffer is to unsubscribe it. The special properties of the draft group comes from a group property (*note Group Parameters::), and if lost the group behaves like any other group. This means the commands below will not be available. To restore the special properties of the group, the simplest way is to kill the group, using `C-k', and restart Gnus. The group is automatically created again with the correct parameters. The content of the group is not lost. When you want to continue editing the article, you simply enter the draft group and push `D e' (`gnus-draft-edit-message') to do that. You will be placed in a buffer where you left off. Rejected articles will also be put in this draft group (*note Rejected Articles::). If you have lots of rejected messages you want to post (or mail) without doing further editing, you can use the `D s' command (`gnus-draft-send-message'). This command understands the process/prefix convention (*note Process/Prefix::). The `D S' command (`gnus-draft-send-all-messages') will ship off all messages in the buffer. If you have some messages that you wish not to send, you can use the `D t' (`gnus-draft-toggle-sending') command to mark the message as unsendable. This is a toggling command.  File: gnus, Node: Rejected Articles, Next: Signing and encrypting, Prev: Drafts, Up: Composing Messages Rejected Articles ================= Sometimes a news server will reject an article. Perhaps the server doesn't like your face. Perhaps it just feels miserable. Perhaps _there be demons_. Perhaps you have included too much cited text. Perhaps the disk is full. Perhaps the server is down. These situations are, of course, totally beyond the control of Gnus. (Gnus, of course, loves the way you look, always feels great, has angels fluttering around inside of it, doesn't care about how much cited text you include, never runs full and never goes down.) So Gnus saves these articles until some later time when the server feels better. The rejected articles will automatically be put in a special draft group (*note Drafts::). When the server comes back up again, you'd then typically enter that group and send all the articles off.  File: gnus, Node: Signing and encrypting, Prev: Rejected Articles, Up: Composing Messages Signing and encrypting ====================== Gnus can digitally sign and encrypt your messages, using vanilla PGP format or PGP/MIME or S/MIME. For decoding such messages, see the `mm-verify-option' and `mm-decrypt-option' options (*note Security::). Often, you would like to sign replies to people who send you signed messages. Even more often, you might want to encrypt messages which are in reply to encrypted messages. Gnus offers `gnus-message-replysign' to enable the former, and `gnus-message-replyencrypt' for the latter. In addition, setting `gnus-message-replysignencrypted' (on by default) will sign automatically encrypted messages. Instructing MML to perform security operations on a MIME part is done using the `C-c C-m s' key map for signing and the `C-c C-m c' key map for encryption, as follows. `C-c C-m s s' Digitally sign current message using S/MIME. `C-c C-m s o' Digitally sign current message using PGP. `C-c C-m s p' Digitally sign current message using PGP/MIME. `C-c C-m c s' Digitally encrypt current message using S/MIME. `C-c C-m c o' Digitally encrypt current message using PGP. `C-c C-m c p' Digitally encrypt current message using PGP/MIME. `C-c C-m C-n' Remove security related MML tags from message. *Note Security: (message)Security, for more information.  File: gnus, Node: Select Methods, Next: Scoring, Prev: Composing Messages, Up: Top Select Methods ************** A "foreign group" is a group not read by the usual (or default) means. It could be, for instance, a group from a different NNTP server, it could be a virtual group, or it could be your own personal mail group. A foreign group (or any group, really) is specified by a "name" and a "select method". To take the latter first, a select method is a list where the first element says what back end to use (e.g. `nntp', `nnspool', `nnml') and the second element is the "server name". There may be additional elements in the select method, where the value may have special meaning for the back end in question. One could say that a select method defines a "virtual server"--so we do just that (*note Server Buffer::). The "name" of the group is the name the back end will recognize the group as. For instance, the group `soc.motss' on the NNTP server `some.where.edu' will have the name `soc.motss' and select method `(nntp "some.where.edu")'. Gnus will call this group `nntp+some.where.edu:soc.motss', even though the `nntp' back end just knows this group as `soc.motss'. The different methods all have their peculiarities, of course. * Menu: * Server Buffer:: Making and editing virtual servers. * Getting News:: Reading USENET news with Gnus. * Getting Mail:: Reading your personal mail with Gnus. * Browsing the Web:: Getting messages from a plethora of Web sources. * IMAP:: Using Gnus as a IMAP client. * Other Sources:: Reading directories, files, SOUP packets. * Combined Groups:: Combining groups into one group. * Gnus Unplugged:: Reading news and mail offline.  File: gnus, Node: Server Buffer, Next: Getting News, Up: Select Methods Server Buffer ============= Traditionally, a "server" is a machine or a piece of software that one connects to, and then requests information from. Gnus does not connect directly to any real servers, but does all transactions through one back end or other. But that's just putting one layer more between the actual media and Gnus, so we might just as well say that each back end represents a virtual server. For instance, the `nntp' back end may be used to connect to several different actual NNTP servers, or, perhaps, to many different ports on the same actual NNTP server. You tell Gnus which back end to use, and what parameters to set by specifying a "select method". These select method specifications can sometimes become quite complicated--say, for instance, that you want to read from the NNTP server `news.funet.fi' on port number 13, which hangs if queried for NOV headers and has a buggy select. Ahem. Anyway, if you had to specify that for each group that used this server, that would be too much work, so Gnus offers a way of naming select methods, which is what you do in the server buffer. To enter the server buffer, use the `^' (`gnus-group-enter-server-mode') command in the group buffer. * Menu: * Server Buffer Format:: You can customize the look of this buffer. * Server Commands:: Commands to manipulate servers. * Example Methods:: Examples server specifications. * Creating a Virtual Server:: An example session. * Server Variables:: Which variables to set. * Servers and Methods:: You can use server names as select methods. * Unavailable Servers:: Some servers you try to contact may be down. `gnus-server-mode-hook' is run when creating the server buffer.  File: gnus, Node: Server Buffer Format, Next: Server Commands, Up: Server Buffer Server Buffer Format -------------------- You can change the look of the server buffer lines by changing the `gnus-server-line-format' variable. This is a `format'-like variable, with some simple extensions: `h' How the news is fetched--the back end name. `n' The name of this server. `w' Where the news is to be fetched from--the address. `s' The opened/closed/denied status of the server. The mode line can also be customized by using the `gnus-server-mode-line-format' variable (*note Mode Line Formatting::). The following specs are understood: `S' Server name. `M' Server method. Also *note Formatting Variables::.  File: gnus, Node: Server Commands, Next: Example Methods, Prev: Server Buffer Format, Up: Server Buffer Server Commands --------------- `a' Add a new server (`gnus-server-add-server'). `e' Edit a server (`gnus-server-edit-server'). `SPACE' Browse the current server (`gnus-server-read-server'). `q' Return to the group buffer (`gnus-server-exit'). `k' Kill the current server (`gnus-server-kill-server'). `y' Yank the previously killed server (`gnus-server-yank-server'). `c' Copy the current server (`gnus-server-copy-server'). `l' List all servers (`gnus-server-list-servers'). `s' Request that the server scan its sources for new articles (`gnus-server-scan-server'). This is mainly sensible with mail servers. `g' Request that the server regenerate all its data structures (`gnus-server-regenerate-server'). This can be useful if you have a mail back end that has gotten out of sync.  File: gnus, Node: Example Methods, Next: Creating a Virtual Server, Prev: Server Commands, Up: Server Buffer Example Methods --------------- Most select methods are pretty simple and self-explanatory: (nntp "news.funet.fi") Reading directly from the spool is even simpler: (nnspool "") As you can see, the first element in a select method is the name of the back end, and the second is the "address", or "name", if you will. After these two elements, there may be an arbitrary number of `(VARIABLE FORM)' pairs. To go back to the first example--imagine that you want to read from port 15 on that machine. This is what the select method should look like then: (nntp "news.funet.fi" (nntp-port-number 15)) You should read the documentation to each back end to find out what variables are relevant, but here's an `nnmh' example: `nnmh' is a mail back end that reads a spool-like structure. Say you have two structures that you wish to access: One is your private mail spool, and the other is a public one. Here's the possible spec for your private mail: (nnmh "private" (nnmh-directory "~/private/mail/")) (This server is then called `private', but you may have guessed that.) Here's the method for a public spool: (nnmh "public" (nnmh-directory "/usr/information/spool/") (nnmh-get-new-mail nil)) If you are behind a firewall and only have access to the NNTP server from the firewall machine, you can instruct Gnus to `rlogin' on the firewall machine and telnet from there to the NNTP server. Doing this can be rather fiddly, but your virtual server definition should probably look something like this: (nntp "firewall" (nntp-open-connection-function nntp-open-via-rlogin-and-telnet) (nntp-via-address "the.firewall.machine") (nntp-address "the.real.nntp.host") (nntp-end-of-line "\n")) If you want to use the wonderful `ssh' program to provide a compressed connection over the modem line, you could add the following configuration to the example above: (nntp-via-rlogin-command "ssh") See also `nntp-via-rlogin-command-switches'. If you're behind a firewall, but have direct access to the outside world through a wrapper command like "runsocks", you could open a socksified telnet connection to the news server as follows: (nntp "outside" (nntp-pre-command "runsocks") (nntp-open-connection-function nntp-open-via-telnet) (nntp-address "the.news.server") (nntp-end-of-line "\n")) This means that you have to have set up `ssh-agent' correctly to provide automatic authorization, of course. And to get a compressed connection, you have to have the `Compression' option in the `ssh' `config' file.  File: gnus, Node: Creating a Virtual Server, Next: Server Variables, Prev: Example Methods, Up: Server Buffer Creating a Virtual Server ------------------------- If you're saving lots of articles in the cache by using persistent articles, you may want to create a virtual server to read the cache. First you need to add a new server. The `a' command does that. It would probably be best to use `nnspool' to read the cache. You could also use `nnml' or `nnmh', though. Type `a nnspool RET cache RET'. You should now have a brand new `nnspool' virtual server called `cache'. You now need to edit it to have the right definitions. Type `e' to edit the server. You'll be entered into a buffer that will contain the following: (nnspool "cache") Change that to: (nnspool "cache" (nnspool-spool-directory "~/News/cache/") (nnspool-nov-directory "~/News/cache/") (nnspool-active-file "~/News/cache/active")) Type `C-c C-c' to return to the server buffer. If you now press `RET' over this virtual server, you should be entered into a browse buffer, and you should be able to enter any of the groups displayed.  File: gnus, Node: Server Variables, Next: Servers and Methods, Prev: Creating a Virtual Server, Up: Server Buffer Server Variables ---------------- One sticky point when defining variables (both on back ends and in Emacs in general) is that some variables are typically initialized from other variables when the definition of the variables is being loaded. If you change the "base" variable after the variables have been loaded, you won't change the "derived" variables. This typically affects directory and file variables. For instance, `nnml-directory' is `~/Mail/' by default, and all `nnml' directory variables are initialized from that variable, so `nnml-active-file' will be `~/Mail/active'. If you define a new virtual `nnml' server, it will _not_ suffice to set just `nnml-directory'--you have to explicitly set all the file variables to be what you want them to be. For a complete list of variables for each back end, see each back end's section later in this manual, but here's an example `nnml' definition: (nnml "public" (nnml-directory "~/my-mail/") (nnml-active-file "~/my-mail/active") (nnml-newsgroups-file "~/my-mail/newsgroups")) Server variables are often called "server parameters".  File: gnus, Node: Servers and Methods, Next: Unavailable Servers, Prev: Server Variables, Up: Server Buffer Servers and Methods ------------------- Wherever you would normally use a select method (e.g. `gnus-secondary-select-method', in the group select method, when browsing a foreign server) you can use a virtual server name instead. This could potentially save lots of typing. And it's nice all over.  File: gnus, Node: Unavailable Servers, Prev: Servers and Methods, Up: Server Buffer Unavailable Servers ------------------- If a server seems to be unreachable, Gnus will mark that server as `denied'. That means that any subsequent attempt to make contact with that server will just be ignored. "It can't be opened," Gnus will tell you, without making the least effort to see whether that is actually the case or not. That might seem quite naughty, but it does make sense most of the time. Let's say you have 10 groups subscribed to on server `nephelococcygia.com'. This server is located somewhere quite far away from you and the machine is quite slow, so it takes 1 minute just to find out that it refuses connection to you today. If Gnus were to attempt to do that 10 times, you'd be quite annoyed, so Gnus won't attempt to do that. Once it has gotten a single "connection refused", it will regard that server as "down". So, what happens if the machine was only feeling unwell temporarily? How do you test to see whether the machine has come up again? You jump to the server buffer (*note Server Buffer::) and poke it with the following commands: `O' Try to establish connection to the server on the current line (`gnus-server-open-server'). `C' Close the connection (if any) to the server (`gnus-server-close-server'). `D' Mark the current server as unreachable (`gnus-server-deny-server'). `M-o' Open the connections to all servers in the buffer (`gnus-server-open-all-servers'). `M-c' Close the connections to all servers in the buffer (`gnus-server-close-all-servers'). `R' Remove all marks to whether Gnus was denied connection from any servers (`gnus-server-remove-denials'). `L' Set server status to offline (`gnus-server-offline-server').  File: gnus, Node: Getting News, Next: Getting Mail, Prev: Server Buffer, Up: Select Methods Getting News ============ A newsreader is normally used for reading news. Gnus currently provides only two methods of getting news--it can read from an NNTP server, or it can read from a local spool. * Menu: * NNTP:: Reading news from an NNTP server. * News Spool:: Reading news from the local spool.  File: gnus, Node: NNTP, Next: News Spool, Up: Getting News NNTP ---- Subscribing to a foreign group from an NNTP server is rather easy. You just specify `nntp' as method and the address of the NNTP server as the, uhm, address. If the NNTP server is located at a non-standard port, setting the third element of the select method to this port number should allow you to connect to the right port. You'll have to edit the group info for that (*note Foreign Groups::). The name of the foreign group can be the same as a native group. In fact, you can subscribe to the same group from as many different servers you feel like. There will be no name collisions. The following variables can be used to create a virtual `nntp' server: `nntp-server-opened-hook' is run after a connection has been made. It can be used to send commands to the NNTP server after it has been contacted. By default it sends the command `MODE READER' to the server with the `nntp-send-mode-reader' function. This function should always be present in this hook. `nntp-authinfo-function' This function will be used to send `AUTHINFO' to the NNTP server. The default function is `nntp-send-authinfo', which looks through your `~/.authinfo' (or whatever you've set the `nntp-authinfo-file' variable to) for applicable entries. If none are found, it will prompt you for a login name and a password. The format of the `~/.authinfo' file is (almost) the same as the `ftp' `~/.netrc' file, which is defined in the `ftp' manual page, but here are the salient facts: 1. The file contains one or more line, each of which define one server. 2. Each line may contain an arbitrary number of token/value pairs. The valid tokens include `machine', `login', `password', `default'. In addition Gnus introduces two new tokens, not present in the original `.netrc'/`ftp' syntax, namely `port' and `force'. (This is the only way the `.authinfo' file format deviates from the `.netrc' file format.) `port' is used to indicate what port on the server the credentials apply to and `force' is explained below. Here's an example file: machine news.uio.no login larsi password geheimnis machine nntp.ifi.uio.no login larsi force yes The token/value pairs may appear in any order; `machine' doesn't have to be first, for instance. In this example, both login name and password have been supplied for the former server, while the latter has only the login name listed, and the user will be prompted for the password. The latter also has the `force' tag, which means that the authinfo will be sent to the NNTP server upon connection; the default (i.e., when there is not `force' tag) is to not send authinfo to the NNTP server until the NNTP server asks for it. You can also add `default' lines that will apply to all servers that don't have matching `machine' lines. default force yes This will force sending `AUTHINFO' commands to all servers not previously mentioned. Remember to not leave the `~/.authinfo' file world-readable. `nntp-server-action-alist' This is a list of regexps to match on server types and actions to be taken when matches are made. For instance, if you want Gnus to beep every time you connect to innd, you could say something like: (setq nntp-server-action-alist '(("innd" (ding)))) You probably don't want to do that, though. The default value is '(("nntpd 1\\.5\\.11t" (remove-hook 'nntp-server-opened-hook 'nntp-send-mode-reader))) This ensures that Gnus doesn't send the `MODE READER' command to nntpd 1.5.11t, since that command chokes that server, I've been told. `nntp-maximum-request' If the NNTP server doesn't support NOV headers, this back end will collect headers by sending a series of `head' commands. To speed things up, the back end sends lots of these commands without waiting for reply, and then reads all the replies. This is controlled by the `nntp-maximum-request' variable, and is 400 by default. If your network is buggy, you should set this to 1. `nntp-connection-timeout' If you have lots of foreign `nntp' groups that you connect to regularly, you're sure to have problems with NNTP servers not responding properly, or being too loaded to reply within reasonable time. This is can lead to awkward problems, which can be helped somewhat by setting `nntp-connection-timeout'. This is an integer that says how many seconds the `nntp' back end should wait for a connection before giving up. If it is `nil', which is the default, no timeouts are done. `nntp-server-hook' This hook is run as the last step when connecting to an NNTP server. `nntp-buggy-select' Set this to non-`nil' if your select routine is buggy. `nntp-nov-is-evil' If the NNTP server does not support NOV, you could set this variable to `t', but `nntp' usually checks automatically whether NOV can be used. `nntp-xover-commands' List of strings used as commands to fetch NOV lines from a server. The default value of this variable is `("XOVER" "XOVERVIEW")'. `nntp-nov-gap' `nntp' normally sends just one big request for NOV lines to the server. The server responds with one huge list of lines. However, if you have read articles 2-5000 in the group, and only want to read article 1 and 5001, that means that `nntp' will fetch 4999 NOV lines that you will not need. This variable says how big a gap between two consecutive articles is allowed to be before the `XOVER' request is split into several request. Note that if your network is fast, setting this variable to a really small number means that fetching will probably be slower. If this variable is `nil', `nntp' will never split requests. The default is 5. `nntp-prepare-server-hook' A hook run before attempting to connect to an NNTP server. `nntp-warn-about-losing-connection' If this variable is non-`nil', some noise will be made when a server closes connection. `nntp-record-commands' If non-`nil', `nntp' will log all commands it sends to the NNTP server (along with a timestamp) in the `*nntp-log*' buffer. This is useful if you are debugging a Gnus/NNTP connection that doesn't seem to work. `nntp-open-connection-function' It is possible to customize how the connection to the nntp server will be opened. If you specify an `nntp-open-connection-function' parameter, Gnus will use that function to establish the connection. Five pre-made functions are supplied. These functions can be grouped in two categories: direct connection functions (three pre-made), and indirect ones (two pre-made). `nntp-prepare-post-hook' A hook run just before posting an article. If there is no `Message-ID' header in the article and the news server provides the recommended ID, it will be added to the article before running this hook. It is useful to make `Cancel-Lock' headers even if you inhibit Gnus to add a `Message-ID' header, you could say: (add-hook 'nntp-prepare-post-hook 'canlock-insert-header) Note that not all servers support the recommended ID. This works for INN versions 2.3.0 and later, for instance. `nntp-read-timeout' How long nntp should wait between checking for the end of output. Shorter values mean quicker response, but is more CPU intensive. The default is 0.1 seconds. If you have a slow line to the server (and don't like to see Emacs eat your available CPU power), you might set this to, say, 1. * Menu: * Direct Functions:: Connecting directly to the server. * Indirect Functions:: Connecting indirectly to the server. * Common Variables:: Understood by several connection functions.  File: gnus, Node: Direct Functions, Next: Indirect Functions, Up: NNTP Direct Functions ................ These functions are called direct because they open a direct connection between your machine and the NNTP server. The behavior of these functions is also affected by commonly understood variables (*note Common Variables::). `nntp-open-network-stream' This is the default, and simply connects to some port or other on the remote system. `nntp-open-tls-stream' Opens a connection to a server over a "secure" channel. To use this you must have GNUTLS (http://www.gnu.org/software/gnutls/) installed. You then define a server as follows: ;; "nntps" is port 563 and is predefined in our `/etc/services' ;; however, `gnutls-cli -p' doesn't like named ports. ;; (nntp "snews.bar.com" (nntp-open-connection-function nntp-open-tls-stream) (nntp-port-number ) (nntp-address "snews.bar.com")) `nntp-open-ssl-stream' Opens a connection to a server over a "secure" channel. To use this you must have OpenSSL (http://www.openssl.org) or SSLeay (ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL) installed. You then define a server as follows: ;; "snews" is port 563 and is predefined in our `/etc/services' ;; however, `openssl s_client -port' doesn't like named ports. ;; (nntp "snews.bar.com" (nntp-open-connection-function nntp-open-ssl-stream) (nntp-port-number 563) (nntp-address "snews.bar.com")) `nntp-open-telnet-stream' Opens a connection to an NNTP server by simply `telnet''ing it. You might wonder why this function exists, since we have the default `nntp-open-network-stream' which would do the job. (One of) the reason(s) is that if you are behind a firewall but have direct connections to the outside world thanks to a command wrapper like `runsocks', you can use it like this: (nntp "socksified" (nntp-pre-command "runsocks") (nntp-open-connection-function nntp-open-telnet-stream) (nntp-address "the.news.server")) With the default method, you would need to wrap your whole Emacs session, which is not a good idea.  File: gnus, Node: Indirect Functions, Next: Common Variables, Prev: Direct Functions, Up: NNTP Indirect Functions .................. These functions are called indirect because they connect to an intermediate host before actually connecting to the NNTP server. All of these functions and related variables are also said to belong to the "via" family of connection: they're all prefixed with "via" to make things cleaner. The behavior of these functions is also affected by commonly understood variables (*note Common Variables::). `nntp-open-via-rlogin-and-telnet' Does an `rlogin' on a remote system, and then does a `telnet' to the real NNTP server from there. This is useful for instance if you need to connect to a firewall machine first. `nntp-open-via-rlogin-and-telnet'-specific variables: `nntp-via-rlogin-command' Command used to log in on the intermediate host. The default is `rsh', but `ssh' is a popular alternative. `nntp-via-rlogin-command-switches' List of strings to be used as the switches to `nntp-via-rlogin-command'. The default is `nil'. If you use `ssh' for `nntp-via-rlogin-command', you may set this to `("-C")' in order to compress all data connections, otherwise set this to `("-t" "-e" "none")' or `("-C" "-t" "-e" "none")' if the telnet command requires a pseudo-tty allocation on an intermediate host. `nntp-open-via-telnet-and-telnet' Does essentially the same, but uses `telnet' instead of `rlogin' to connect to the intermediate host. `nntp-open-via-telnet-and-telnet'-specific variables: `nntp-via-telnet-command' Command used to `telnet' the intermediate host. The default is `telnet'. `nntp-via-telnet-switches' List of strings to be used as the switches to the `nntp-via-telnet-command' command. The default is `("-8")'. `nntp-via-user-password' Password to use when logging in on the intermediate host. `nntp-via-envuser' If non-`nil', the intermediate `telnet' session (client and server both) will support the `ENVIRON' option and not prompt for login name. This works for Solaris `telnet', for instance. `nntp-via-shell-prompt' Regexp matching the shell prompt on the intermediate host. The default is `bash\\|\$ *\r?$\\|> *\r?'. Here are some additional variables that are understood by all the above functions: `nntp-via-user-name' User name to use when connecting to the intermediate host. `nntp-via-address' Address of the intermediate host to connect to.  File: gnus, Node: Common Variables, Prev: Indirect Functions, Up: NNTP Common Variables ................ The following variables affect the behavior of all, or several of the pre-made connection functions. When not specified, all functions are affected. `nntp-pre-command' A command wrapper to use when connecting through a non native connection function (all except `nntp-open-network-stream', `nntp-open-tls-stream', and `nntp-open-ssl-stream'. This is where you would put a `SOCKS' wrapper for instance. `nntp-address' The address of the NNTP server. `nntp-port-number' Port number to connect to the NNTP server. The default is `nntp'. If you use NNTP over tls/ssl, you may want to use integer ports rather than named ports (i.e, use `563' instead of `snews' or `nntps'), because external TLS/SSL tools may not work with named ports. `nntp-end-of-line' String to use as end-of-line marker when talking to the NNTP server. This is `\r\n' by default, but should be `\n' when using a non native connection function. `nntp-telnet-command' Command to use when connecting to the NNTP server through `telnet'. This is _not_ for an intermediate host. This is just for the real NNTP server. The default is `telnet'. `nntp-telnet-switches' A list of switches to pass to `nntp-telnet-command'. The default is `("-8")'.  File: gnus, Node: News Spool, Prev: NNTP, Up: Getting News News Spool ---------- Subscribing to a foreign group from the local spool is extremely easy, and might be useful, for instance, to speed up reading groups that contain very big articles--`alt.binaries.pictures.furniture', for instance. Anyway, you just specify `nnspool' as the method and `""' (or anything else) as the address. If you have access to a local spool, you should probably use that as the native select method (*note Finding the News::). It is normally faster than using an `nntp' select method, but might not be. It depends. You just have to try to find out what's best at your site. `nnspool-inews-program' Program used to post an article. `nnspool-inews-switches' Parameters given to the inews program when posting an article. `nnspool-spool-directory' Where `nnspool' looks for the articles. This is normally `/usr/spool/news/'. `nnspool-nov-directory' Where `nnspool' will look for NOV files. This is normally `/usr/spool/news/over.view/'. `nnspool-lib-dir' Where the news lib dir is (`/usr/lib/news/' by default). `nnspool-active-file' The name of the active file. `nnspool-newsgroups-file' The name of the group descriptions file. `nnspool-history-file' The name of the news history file. `nnspool-active-times-file' The name of the active date file. `nnspool-nov-is-evil' If non-`nil', `nnspool' won't try to use any NOV files that it finds. `nnspool-sift-nov-with-sed' If non-`nil', which is the default, use `sed' to get the relevant portion from the overview file. If `nil', `nnspool' will load the entire file into a buffer and process it there.  File: gnus, Node: Getting Mail, Next: Browsing the Web, Prev: Getting News, Up: Select Methods Getting Mail ============ Reading mail with a newsreader--isn't that just plain WeIrD? But of course. * Menu: * Mail in a Newsreader:: Important introductory notes. * Getting Started Reading Mail:: A simple cookbook example. * Splitting Mail:: How to create mail groups. * Mail Sources:: How to tell Gnus where to get mail from. * Mail Back End Variables:: Variables for customizing mail handling. * Fancy Mail Splitting:: Gnus can do hairy splitting of incoming mail. * Group Mail Splitting:: Use group customize to drive mail splitting. * Incorporating Old Mail:: What about the old mail you have? * Expiring Mail:: Getting rid of unwanted mail. * Washing Mail:: Removing cruft from the mail you get. * Duplicates:: Dealing with duplicated mail. * Not Reading Mail:: Using mail back ends for reading other files. * Choosing a Mail Back End:: Gnus can read a variety of mail formats.  File: gnus, Node: Mail in a Newsreader, Next: Getting Started Reading Mail, Up: Getting Mail Mail in a Newsreader -------------------- If you are used to traditional mail readers, but have decided to switch to reading mail with Gnus, you may find yourself experiencing something of a culture shock. Gnus does not behave like traditional mail readers. If you want to make it behave that way, you can, but it's an uphill battle. Gnus, by default, handles all its groups using the same approach. This approach is very newsreaderly--you enter a group, see the new/unread messages, and when you read the messages, they get marked as read, and you don't see them any more. (Unless you explicitly ask for them.) In particular, you do not do anything explicitly to delete messages. Does this mean that all the messages that have been marked as read are deleted? How awful! But, no, it means that old messages are "expired" according to some scheme or other. For news messages, the expire process is controlled by the news administrator; for mail, the expire process is controlled by you. The expire process for mail is covered in depth in *Note Expiring Mail::. What many Gnus users find, after using it a while for both news and mail, is that the transport mechanism has very little to do with how they want to treat a message. Many people subscribe to several mailing lists. These are transported via SMTP, and are therefore mail. But we might go for weeks without answering, or even reading these messages very carefully. We may not need to save them because if we should need to read one again, they are archived somewhere else. Some people have local news groups which have only a handful of readers. These are transported via NNTP, and are therefore news. But we may need to read and answer a large fraction of the messages very carefully in order to do our work. And there may not be an archive, so we may need to save the interesting messages the same way we would personal mail. The important distinction turns out to be not the transport mechanism, but other factors such as how interested we are in the subject matter, or how easy it is to retrieve the message if we need to read it again. Gnus provides many options for sorting mail into "groups" which behave like newsgroups, and for treating each group (whether mail or news) differently. Some users never get comfortable using the Gnus (ahem) paradigm and wish that Gnus should grow up and be a male, er, mail reader. It is possible to whip Gnus into a more mailreaderly being, but, as said before, it's not easy. People who prefer proper mail readers should try VM instead, which is an excellent, and proper, mail reader. I don't mean to scare anybody off, but I want to make it clear that you may be required to learn a new way of thinking about messages. After you've been subjected to The Gnus Way, you will come to love it. I can guarantee it. (At least the guy who sold me the Emacs Subliminal Brain-Washing Functions that I've put into Gnus did guarantee it. You Will Be Assimilated. You Love Gnus. You Love The Gnus Mail Way. You Do.)