Gnus Manual. Node: Mail Backend Variables

PREVSplitting Mail UPGetting Mail NEXTFancy Mail Splitting

6.3.3: Mail Backend Variables

These variables are (for the most part) pertinent to all the various mail backends.


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


The backends will look for new mail in this file. If this variable is nil, the mail backends will never attempt to fetch mail by themselves. If you are using a POP mail server and your name is `larsi', you should set this variable to `po:larsi'. If your name is not `larsi', you should probably modify that slightly, but you may have guessed that already, you smart & handsome devil! You can also set this variable to pop, and Gnus will try to figure out the POP mail string by itself. In any case, Gnus will call movemail which will contact the POP server named in the MAILHOST environment variable. If the POP server needs a password, you can either set nnmail-pop-password-required to t and be prompted for the password, or set nnmail-pop-password to the password itself.

nnmail-spool-file can also be a list of mailboxes.

Your Emacs has to have been configured with `--with-pop' before compilation. This is the default, but some installations have it switched off.

When you use a mail backend, 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 backend---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.


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


When a mail backend reads a spool file, mail is first moved to this file, which is `~/.gnus-crash-box' by default. If this file already exists, it will always be read (and incorporated) before any other spool files.


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


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-rfc1522 is one likely function to add to this 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)))

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


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

This can also be a function. In that case, the function will be called with two parameters -- the name of the inbox, and the file to be moved to.


If non-nil, the mail backends will delete the temporary incoming file after splitting mail into the proper groups. This is t by default.

(No Gnus release since (ding) Gnus 0.10 (or something like that) have lost mail, I think, but that's not the point. (Except certain versions of Red Gnus.)) By not deleting the Incoming* files, one can be sure not to lose mail -- if Gnus totally whacks out, one can always recover what was lost.

You may delete the `Incoming*' files at will.


If non-nil, the mail backends will use long file and directory names. Groups like `mail.misc' will end up in directories (assuming use of nnml backend) or files (assuming use of nnfolder backend) like `mail.misc'. If it is nil, the same group will end up in `mail/misc'.


Function called to delete files. It is delete-file by default.


If non-nil, put the Message-IDs of articles imported into the backend (via Gcc, for instance) into the mail duplication discovery cache. The default is nil.

PREVSplitting Mail UPGetting Mail NEXTFancy Mail Splitting