From: Gregory N. S. <gsh...@us...> - 2004-10-30 04:17:28
|
Update of /cvsroot/vm-faq/vm-faq In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1523 Added Files: vm-procmail.html Log Message: Add Sam's VM with procmail FAQ --- NEW FILE: vm-procmail.html --- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <!-- saved from url=(0094)http://web.archive.org/web/20040214214031/http://www.cs.hmc.edu/~smikes/emacs/vm-procmail.html --> <!-- $Source: /cvsroot/vm-faq/vm-faq/vm-procmail.html,v $ --> <!-- $Revision: 1.1 $ --> <!-- $Date: 2004/10/30 04:17:18 $ --> <!-- $Author: gshapiro $ --> <!-- $Locker: $ --> <HTML> <HEAD> <TITLE>VM with procmail FAQ</TITLE> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"><LINK rev=made href="mailto:sm...@al..."> <META content="MSHTML 6.00.2800.1458" name=GENERATOR> </HEAD> <BODY><!-- bgcolor="#000000" text="#f0f0f0" --> <H1>FAQ: Using VM with procmail</H1> <UL> <LI><A href="#meta">0. This Document</A> <UL> <LI><A href="#meta_why">0.1 Why</A> <LI><A href="#meta_where">0.2 Where</A> <LI><A href="#meta_when">0.3 When</A> <LI><A href="#meta_who">0.4 Who</A> <LI><A href="#meta_how">0.5 How</A> <LI><A href="#meta_future">0.6 Future</A> </UL> <LI><A href="#lock">1. Locking and spool files</A> <UL> <LI><A href="#lock_revert">1.1 "I'm using <KBD>procmail</KBD> to save messages to a folder..."</A> <LI><A href="#lock_why">1.2 "Why do I have to use spool files?"</A> <LI><A href="#lock_procmailex">1.3 "What's this in the <KBD>procmailex(1)</KBD> man page about emacs lock-files?"</A> <LI><A href="#lock_variant">1.4 "What's another way to do this?"</A> </UL> <LI><A href="#pop">2. POP</A> <UL> <LI><A href="#pop_vmprocmail">2.1 "Can I use VM's POP capability together with <KBD>procmail</KBD>?"</A> <LI><A href="#pop_fetchmta">2.2 "How do I go about using fetchmail to deliver to my MTA?"</A> <LI><A href="#pop_fetchmda">2.2 "How do I go about using fetchmail to deliver to my MDA?"</A> </UL> <LI><A href="#notif">3. Notification of Incoming Mail</A> <UL> <LI><A href="#notif_vm">3.1 VM</A> <LI><A href="#notif_xbuffy">3.2 xbuffy</A> <LI><A href="#notif_mspool">3.3 mspools.el</A> <LI><A href="#notif_comsat">3.4 comsat</A> <LI><A href="#notif_procmaillog">3.5 A procmail log monitor</A> </UL> <LI><A href="#res">4. Other Resources</A> <UL> <LI><A href="#res_vm">4.1 VM Resources</A> <LI><A href="#res_proc">4.2 <KBD>procmail</KBD> Resources</A> <LI><A href="#res_filt">4.3 Mail filtering Resources</A> <LI><A href="#res_configs">4.4 Example configurations</A> </UL> </UL> <H2><A name="meta">0. This document</A></H2> <H3><A name="meta_why">0.1 Why</A></H3> <P>Between January 1, 1998 and February 24, 1998, 17 messages about VM and <KBD>procmail</KBD> were posted to the gnu.emacs.vm.bug and gnu.emacs.vm.info newsgroups. Many of the questions asked had already been answered within the last 3-6 months. The <A href="#res_vm">VM FAQ</A> doesn't currently contain a section on VM and <KBD>procmail</KBD>. I started to write an addition to the VM FAQ, but quickly realized that there's too much information on VM and <KBD>procmail</KBD> to quickly toss together. Thus, this document. <H3><A name="meta_where">0.2 Where</A></H3> <P>This FAQ can be obtained from its canonical location, <A href="vm-procmail.html">http://www.wonderworks.com/vm/vm-procmail.html</A>. It is currently not being mirrored. It may be posted regularly to some newsgroups: gnu.emacs.vm.info comes to mind. <H3><A name="meta_when">0.3 When</A></H3> <P>This document was last modified on: $Date: 2004/10/30 04:17:18 $<BR>This is version (not revision!) 0.10 of this document. <H3><A name="meta_who">0.4 Who</A></H3> <P>This FAQ is currently maintained by Samuel Mikes <sm...@al...>. <P>Several code examples are provided at the end of this FAQ; where I knew the author, I have attempted to give appropriate credit. If your code is mistakenly attributed to someone else -- or you'd like to contribute examples -- please contact the current FAQ maintainer. <P>I thank Brian Gorka and Era Eriksson for their helpful comments. <H3><A name="meta_how">0.5 How</A></H3> <P>This FAQ is written in HTML using psgml-html mode under XEmacs 20.3. The syntax of the document is verified against the HTML 3.2 Final DTD. <P>Text versions of this FAQ (such as those posted to newsgroups) are created with lynx (<KBD>lynx -dump -nolist</KBD>). <H3><A name="meta_future">0.6 Future</A></H3> <P>Things that I'd like to do with this document: <UL> <LI>Add a "<KBD>fetchmail</KBD> Resources" section <LI>Make sure that style is consistent throughout. <LI>Cull samples for duplication; possibly split off samples into a different document? </UL> <H2><A name="lock">1. Locking and spool files</A></H2> <H3><A name="lock_revert">1.1 "I'm using <KBD>procmail</KBD> to save messages to a folder..."</A></H3> <P>This is the most common problem. You should not use <KBD>procmail</KBD> to save messages to a VM folder. You should use <KBD>procmail</KBD> to save messages to a spool file, and let VM pick up the mail from the spool file. <P>In your VM configuration file (~/.vm or ~/.emacs): <HR> <PRE> ;;; first, set up special handling for the system mailbox (setq vm-spool-files (list ;; this should be a list of triples: ;; <mail folder> <spool file> <crash box> (list "~/priv/mail/inbox" (getenv "MAIL") "~/priv/mail/inbox.crash"))) ;; now set the defaults for other folders: (setq vm-crash-box-suffix ".crash") (setq vm-spool-file-suffixes (list ".spool")) </PRE> <HR> <P>This tells VM to look for system mail in the location specified by the environment variable <KBD>$MAIL</KBD>, put it in <KBD>~/priv/mail/inbox</KBD>, and use <KBD>inbox.crash</KBD> as a crash box to protect you from catastrophic loss of mail. You will want to modify this sample code from my setup, since most people don't keep their mail in <KBD>~/priv/mail/inbox</KBD>. <!-- Hello, jared! --> <P>For all other folders, VM will look for a file named "<file>.spool" and incorporate mail from that. <P>Your procmailrc should then deliver mail into the spool files: <HR> <PRE> # .procmailrc :0: * ^Subject:.*\[foo-users\] foo-users.spool :0: * ^Sender:.*baz-request baz-request.spool </PRE> <HR> <P>Now, if you visit the folder "baz-request", vm will automatically pick up mail from "baz-request.spool" and incorporate it into the folder. If new mail arrives for 'baz-request" while you're visiting the folder, you can bring it in with <KBD>vm-get-new-mail</KBD>, normally bound to "g". <P>If the variable "vm-spooled-mail-interval" is set, then VM will periodically check for new mail: if a visited folder has new mail waiting, the "Mail" indicator will be displayed in its buffer's mode-line. If the variable "vm-auto-get-new-mail" is set to a number (n), VM will automatically retrieve new mail for visited folders, polling every n seconds. <P>Some other ways of doing this are presented <A href="#lock_variant">below</A>. <H3><A name="lock_why">1.2 "Why do I have to use spool files?"</A></H3> <P>The problem stems from the fact that <KBD>emacs</KBD> (and thus VM) have a different philosophy of file locking from <KBD>sendmail</KBD>, <KBD>procmail</KBD>, and the like. <P>The <KBD>procmail</KBD> (and <KBD>/bin/mail</KBD>, and <KBD>sendmail</KBD>, etc..) locking model is designed for a system where many programs (or many instances of the same program) wish to modify the same file. Each program wants to lock the file, append the message it's responsible for, and unlock the file. This locking model works well for mail delivery. <P>The <KBD>emacs</KBD> locking model is designed to allow lots of people to look at files without modifying them. <KBD>emacs</KBD> doesn't try to lock a file until you start to modify it. This lets a number of people view the same file by holding a buffer in memory unmodified and unlocked. The first person who tries to modify (not open!) the file gets the lock. <P>VM expects that no-one else will modify its mail folders while it's working with them. When you visit a mail folder, VM reads the folder from disk into a buffer, and manipulates the buffer in memory (marking, deleting, and saving messages, for example). When you tell VM to incorporate new mail into the folder (vm-get-new-mail, by default bound to "g") or save the folder, VM checks to make sure the file on disk hasn't changed since it was read. If it has, VM prints the dreaded "Folder inbox changed on disk, consider M-x revert-buffer" message. <P>To me, the cleanest solution is to not use <KBD>procmail</KBD> to deliver to VM's folders. However, dissenting opinions exist; <A href="#heretic">see below</A>. <H3><A name="lock_procmailex">1.3 "What's this in the <KBD>procmailex(5)</KBD> man page about emacs lock-files?"</A></H3> <P>The <KBD>procmailex(5)</KBD> man page says (in part) <PRE> When delivering to emacs folders (i.e. mailfolders managed by any emacs mail package, e.g. RMAIL or VM) directly, you should use emacs-compatible lockfiles. The emacs mailers are a bit braindamaged in that respect, they get very upset if someone delivers to mailfolders which they already have in their internal buffers. The following recipe assumes that $HOME equals /home/john. MAILDIR=Mail :0:/usr/local/lib/emacs/lock/!home!john!Mail!mailbox * ^Subject:.*whatever mailbox Alternatively, you can have <KBD>procmail</KBD> deliver into its own set of mailboxes, which you then periodically empty and copy over to your emacs files using movemail. Movemail uses mailbox.lock local lockfiles per mailbox. </PRE> <P>The first paragraph and the accompanying example talks about delivering mail to emacs folders, which is a bad idea, as we've discussed <A href="#lock_revert">above</A>. <P>The second paragraph talks about using <KBD>procmail</KBD> to deliver to "its own set of mailboxes" -- i.e., spool files -- and moving the mail using <KBD>movemail</KBD>. That's what VM does with the mailbox-spoolfile-crashbox system. <P>Since movemail uses the <KBD>procmail</KBD> "<file>.lock" locking convention, you <EM>should not</EM> configure <KBD>procmail</KBD> to use <KBD>emacs</KBD>-style locking for your spool files. Using the normal ":0:"-style locking is enough. <H3><A name="lock_variant">1.4 "What's another way to do this?"</A></H3> <P>Everybody has their own way of doing this, of course; that's the beauty of VM. <UL> <LI>You can use the variables <KBD>vm-spool-file-suffix</KBD> and <KBD>vm-crash-box-suffix</KBD> as described above. <LI>Or, you could define the functions <KBD>vm-make-spool-file-name</KBD> and <KBD>vm-make-crash-box-name</KBD>, and use them to do arbitrary transformations on the mail box name to make the spool file/crash box names. <LI>You could even write a <KBD>vm-make-spool-file-name</KBD> that reads your <KBD>.procmailrc</KBD> file and does the right thing based on that. </UL> <P>Sample code is provided at the end of this document, in the resources section under <A href="#res_config">sample configurations</A> <H2><A name="pop">2. POP</A></H2> <H3><A name="pop_vmprocmail">2.1 "Can I use VM's POP capability together with <KBD>procmail</KBD>?"</A></H3> <P>Nope. <P>But you can use any of a number popmail clients, and configure them to use <KBD>procmail</KBD> as a local delivery agent. I recommend Eric S. Raymond's <KBD>fetchmail</KBD>, available at <A href="http://www.ccil.org/~esr/fetchmail">http://www.ccil.org/~esr/fetchmail</A>. <KBD>fetchmail</KBD> works best with a local mail transfer agent such as <KBD>sendmail</KBD>, but it can be configured to directly use a local mail delivery agent, such as <KBD>procmail</KBD>. <H3><A name="pop_fetchmta">2.2 "How do I go about using fetchmail to deliver to my MTA?"</A></H3><EM>(I assume that you have a mail transfer agent (MTA) such as <KBD>sendmail</KBD> or <KBD>qmail</KBD> installed, and that you're using <KBD>procmail</KBD> for local delivery -- either as the default mail delivery agent (MDA), or through a forward file as described in the <KBD>procmail(1)</KBD> man page. If you don't have an MTA installed, either install one or skip to <A href="#pop_fetchmda">the appropriate section</A> of this FAQ.) </EM> <P>Obtain and install fetchmail and follow the directions for setting up a .fetchmailrc. For a simple case, your .fetchmailrc will look like mine: <PRE> # .fetchmailrc poll pop.teokem.lu.se user teosom there is smikes here </PRE> <P>Run fetchmail, either interactively (<KBD>$ fetchmail</KBD>) or as a daemon (<KBD>$ fetchmail -d 30</KBD>). <P>If you don't have a mail transfer agent installed and listening on port 25 (smtp), this won't work. So, hie yourself over to <A href="http://www.sendmail.org/">http://www.sendmail.org/</A>, or try the next option. <H3><A name="pop_fetchmda">2.3 "How do I go about using fetchmail to deliver to my MDA (<KBD>procmail</KBD>)?"</A></H3> <P>Obtain and install fetchmail (<A href="#pop_vmprocmail">as before</A>). <P>Create a .fetchmailrc which tells fetchmail to hand off your mail to <KBD>procmail</KBD> for delivery (we'll use <KBD>formail</KBD> to preprocess the mail and hand it off to <KBD>procmail</KBD>) <PRE> # .fetchmailrc poll pop.teokem.lu.se user teosom there is smikes here and wants mda "/usr/bin/formail -ds procmail" </PRE> <P><STRONG>WARNING: YOU MAY LOSE MAIL.</STRONG>. The author of fetchmail, Eric S. Raymond, says this about the "mda" option of fetchmail (from the fetchmail manual): <HR> <PRE> You can force mail to be passed to an MDA directly (rather than forwarded to port 25) with the -mda or -m option. If fetchmail is running as root, it sets its userid to that of the target user while delivering mail through an MDA. Some possible MDAs are "/usr/sbin/sendmail -oem", "/usr/lib/sendmail -oem", "/usr/bin/formail", and "/usr/bin/deliver". Local delivery addresses will be inserted into the MDA command wherever you place a %s. Do not use an MDA like "sendmail -oem -t" that dispatches on the contents of To/Cc/Bcc, it will create mail loops and bring the just wrath of many postmasters down upon your head. ... ... When forwarding to an MDA, however, there is more possibility of error (because there's no way for fetchmail to get a reliable positive acknowledgement from the MDA). </PRE> <HR> <P>Since direct delivery to an MDA can lose mail, I recommend installing and using an MTA, such as <KBD>sendmail</KBD>. An added benefit of installing <KBD>sendmail</KBD> is that you can use the <KBD>check_mail</KBD> anti-spam rules maintained by Claus Assmann. <H2><A name="notif">3. Notification of Incoming Mail</A></H2> <H3><A name="notif_vm">3.1 VM</A></H3> <P>You can make VM automatically check for and incorporate mail from spool files. Consider the following variables: <HR> <PRE> `vm-auto-get-new-mail' (buffer: *Hyper Apropos*, mode: Hyper-Apropos) User variable: value: nil *Non-nil value causes VM to automatically move mail from spool files to a mail folder when the folder is first visited. Nil means you must always use vm-get-new-mail to pull in newly arrived messages. If the value is a number, then it specifies how often (in seconds) VM should check for new mail and try to retrieve it. This is done asynchronously and may occur while you are editing other files. It should not disturb your editing, except perhaps for a pause while the check is being done. --- `vm-mail-check-interval' is a variable declared in Lisp. Value: nil Documentation: *Numeric value specifies the number of seconds between checks for new mail. The maildrops for all visited folders are checked. A nil value means don't check for new mail. Note that mail if new mail is found, it is not retrieved. The buffer local variable vm-spooled-mail-waiting is set non-nil in the buffers of those folders that have mail waiting. VM uses the displays "Mail" in the mode line of folders that have mail waiting. </PRE> <HR> <P>If you set <KBD>vm-auto-get-new-mail</KBD> to `t' and <KBD>vm-mail-check-interval</KBD> to some number, then new mail will be incorporated into a buffer when you first visit it. While you're visiting it, if new mail arrives, the "Mail" indicator will appear in your mode-line, and you can hit "g" to get the new mail. <P>On the other hand, you could set <KBD>vm-auto-get-new-mail</KBD> to, say 10 -- in which case, new mail would be incorporated into visited buffers every ten seconds. <P>These variable definitions are from VM 6.43. Use `describe-variable' and `apropos' on your version of VM to see whether it has these variables. If you're stuck with an older version of VM (you run an older version of FSF emacs, say), you should consider one of the alternative options. <H3><A name="notif_xbuffy">3.2 xbuffy</A></H3> <P><KBD>xbuffy</KBD> is a generalization of <KBD>xbiff</KBD>. It can watch multiple spool files, execute a user-defined command when mail arrives (by default, it beeps), display a summary of the incoming mail, and execute a user-defined command when you middle-click on a mailbox. (This could be used, for example, to run gnuclient(1) and tell your <KBD>emacs</KBD> to visit the folder.) <P><KBD>xbuffy</KBD> can be obtained from an X11 archive site, such as <A href="ftp://ftp.sunet.se/pub/X11/contrib/utilities/">ftp://ftp.sunet.se/pub/X11/contrib/utilities/</A>. The most recent version of xbuffy as of the date printed on this FAQ is 3.3 <H3><A name="notif_mspool">3.3 mspools.el</A></H3> <P>There is reputed to be some sort of multiple-spool watching code written in elisp by Stephen Eglen. I haven't tried it. <P>The code is available through Stephen's <A href="http://www.cns.ed.ac.uk/people/stephen/emacs">emacs</A> page, or directly at <A href="http://www.cns.ed.ac.uk/people/stephen/emacs/mspools.el">http://www.cns.ed.ac.uk/people/stephen/emacs/mspools.el</A> <P> <H3><A name="notif_comsat">3.4 comsat</A></H3> <P>Since <KBD>procmail</KBD> does the normal comsat-notification when new mail arrives, you could build some sort of mail-notification around the <KBD>comsat(8)</KBD> daemon. Just a thought, though: I don't think this is a terribly good idea. <H3><A name="notif_procmaillog">3.5 A procmail log monitor</A></H3> <P>(Suggested by era eriksson <er...@ik...>) <P>Since <KBD>procmail</KBD> can be configured to log all received mail (by specifying a logfile in the .procmailrc), it would be possible to cook up your own mail-monitor by watching the procmail log file for deliveries. <H2><A name="res">4. Other Resources</A></H2> <H3><A name="res_vm">4.1 VM Resources</A></H3> <P>The latest version of VM can be obtained from <A href="ftp://ftp.uu.net/">ftp://ftp.uu.net/</A>in the directory <A href="ftp://ftp.uu.net/networking/mail/vm/">networking/mail/vm/</A> as <A href="ftp://ftp.uu.net/networking/mail/vm/vm.tar.gz">vm.tar.gz</A>. <P>There are two VM newsgroups: <A href="news:gnu.emacs.vm.info">gnu.emacs.vm.info</A> for general questions and discussion, and <A href="news:gnu.emacs.vm.bug">gnu.emacs.vm.bug</A> for bug reports. (Bug reports should be submitted with M-x vm-submit-bug-report.) The newsgroups are also gatewayed to mailing lists, as described in the MAILINGLISTS file in the emacs distribution. <P>The VM FAQ (<A href="FAQ.html">http://www.wonderworks.com/vm/FAQ.html</A>) was written by Brian Gorka. It answers general questions about VM, its user interface, and configuration. <P>A library of VM code can be found at Emmett Hogan's VM Add-Ons web page, <A href="http://www.gnac.com/~hogan/vm/">http://www.gnac.com/~hogan/vm/</A>. He has several sample configurations and some neat hacks and enhancements, including the <KBD>spookmime.el</KBD> MIME boundary generator. <H3><A name="res_proc">4.2 <KBD>procmail</KBD> resources</A></H3> <P><KBD>procmail</KBD> can be obtained from many locations; the primary source is <A href="ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/">ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/</A>. <P>A Procmail FAQ is at <A href="http://www.iki.fi/~era/procmail/mini-faq.html">http://www.iki.fi/~era/procmail/mini-faq.html</A>. The maintainer of that FAQ also maintains a list of <A href="http://www.iki.fi/~era/procmail/links.html"><KBD>procmail</KBD> links</A>, which includes pointers to example recipes and mailing lists. <H3><A name="res_filt">4.3 Mail Filtering resources</A></H3> <P>The Infinite Ink Mail Filtering FAQ can be obtained through their faq-launcher at <A href="http://www.ii.com/internet/faqs/launchers/mail/filtering-faq/">http://www.ii.com/internet/faqs/launchers/mail/filtering-faq/</A> <H3><A name="res_configs">4.4 Example configurations</A></H3> <H4>Neal Young <Nea...@da...></H4> <PRE> ;; run vm with file-completion on folders with waiting mail ;;;###autoload (defun ney-vm () "vm primary mbox. Prompt for folder, defaulting to first with mail waiting, and completing on non-empty. with prefix-arg, prompt for file name instead" (interactive) (require 'vm) (vm-session-initialization) (let ((this-command 'vm-visit-folder) (folder (if current-prefix-arg (read-file-name "Run vm on file: " nil nil t) (let* ((waiting (ney-vm-folders-with-mail-waiting)) (default (car waiting))) (completing-read "Run vm on folder: " (mapcar 'list waiting) nil nil (and default (cons default 0))))))) (vm-visit-folder (or folder vm-primary-inbox)))) (defun ney-vm-mail-waiting-p (inbox) (let ((attributes (file-attributes (file-truename (expand-file-name inbox))))) (and attributes ; file exists (not (eq (car attributes) t)) ; not directory (> (nth 7 attributes) 0)))) ; not empty (defun ney-vm-folders-with-mail-waiting () (ney-reset-vm-spool-files) ; defined below (delete nil (mapcar (function (lambda (triple) (if (ney-vm-mail-waiting-p (nth 1 triple)) (file-name-nondirectory (nth 0 triple))))) vm-spool-files))) ;; set "vm-spool-files" automatically according to existing spool files ;; I define and run this in my .vm file and in procedure ney-vm below. ;; assumes spool files will exist even if empty (defun ney-reset-vm-spool-files () (setq vm-spool-files (append (list (list (my-folder "in") (or (getenv "mail") "/usr/spool/mail/ney") (my-crashbox "in"))) (mapcar '(lambda (x) (list (my-folder x) (my-inbox x) (my-crashbox x))) (select-list-items "^[^.]" (directory-files (concat vm-folder-directory "spool"))) )))) </PRE> <H4>ke...@ak... (Kerry Thompson)</H4>.forward: <PRE> "|IFS=' '&& exec /usr/bin/procmail -m /home/kerryt/.procmailrc ||exit 75" </PRE> <PRE> # .procmailrc PATH=/bin:/usr/bin:/usr/bin MAILDIR=$HOME/Mail #you'd better make sure it exists #DEFAULT=$MAILDIR/mbox #completely optional LOGFILE=$MAILDIR/procmail.log #recommended :0: * ^TOdjb-qmail qmail-in :0: * ^TOexim-users exim-in :0: * ^TOinfo-vm vm-in #:0 #* ^Subject:.*flame #/dev/null </PRE> <P>This tells procmail to stick matching (VM list) messages into ~/Mail/vm-in, all of my mail folders live in ~/Mail. Then I setup vm-spool files in my ~/.vm : <PRE> (setq vm-spool-files '(("~/INBOX" "/var/spool/mail/kerryt" "~/Mail/INBOX.CRASH") ("qmail" "~/Mail/qmail-in" "~/Mail/qmail.CRASH") ("exim" "~/Mail/exim-in" "~/Mail/exim.CRASH") ("vm" "~/Mail/vm-in" "~/Mail/vm.CRASH") )) </PRE> <H4>Gael Marziou <Gae...@hp...></H4> <PRE> ;; to work with mailagent and xbuffy ;; mailagent is a mail filter like procmail ;; filtered mail is put into spool files located under ~/var/mail/ ;; the functions below tell vm how to retrieve the spool file name ;; associated to a VM folder. (defconst my-mail-spool-dir "~/var/mail/") (defun my-vm-make-spool-file-name (folder) (let* ((my-vm-folder-directory (expand-file-name vm-folder-directory)) (indx (string-match my-vm-folder-directory (expand-file-name folder)))) (if indx (concat my-mail-spool-dir (substring (expand-file-name folder) (+ indx (length my-vm-folder-directory)))) folder))) (setq vm-make-spool-file-name 'my-vm-make-spool-file-name) </PRE> <H4>Raymond Wiker <et...@et...></H4> <P>... A better way of doing this is to send the mail to am different file, and tell vm to fetch mail for INBOX from this file. In my setup, I use <PRE> (setq vm-spool-files (list (mapcar 'expand-file-name '("~/INBOX" "~/INBOX.CRASH" "~/Mail/new")) (mapcar 'expand-file-name '("~/INBOX" "~/INBOX.CRASH" "/var/mail/etorwi")) (mapcar 'expand-file-name '("~/Mail/spam" "~/Mail/spam.crash" "~/Mail/spam-p")) (mapcar 'expand-file-name '("~/Mail/spam" "~/Mail/spam.crash" "~/Mail/spam-new")))) </PRE> <H4>David Maslen <da...@bi...></H4> <P>David posted this code to gnu.emacs.vm.info, but he didn't write it, so please don't go bothering him about it! If the author of this code would like to take responsibility for it, please contact the <A href="#meta_who">FAQ maintainer</A> <PRE> ;; Since I use procmail to filter my mail, I like to shove my incoming ;; mail to folders. Due to Emacs (and hence VM) locking, it's not wise ;; to view the incoming spool file, so I make procmail dump mail to ;; folders IN ALL CAPS. Then I have VM make spool files from each one of ;; those, except they'll be in all lower case. (setq vm-spool-files (append (list (list vm-primary-inbox "~/Mailbox" (concat vm-primary-inbox ".crash"))) ;; Mailing list inboxes ;; I arrange that all my procmail maildrops are in ~/Mail/[A-Z]* (mapcar '(lambda (s) "make the appropriate entry for vm-spool-files" (list (concat vm-folder-directory "lists/" s) (concat vm-folder-directory "lists/" (upcase s)) (concat vm-folder-directory "lists/" s ".crash"))) ;; So I create a vm-spool-files entry for each mail drop (mapcar 'downcase (directory-files (concat vm-folder-directory "lists/") nil "^[A-Z].+"))))) </PRE> <H4><A name="heretic">"J. Daniel Smith" <Da...@br...></A></H4> <P><EM>From a post to gnu.emacs.vm.info: edited and HTML-ized by Sam Mikes</EM> <P>well, I finally figured out today that Emacs 19 was writing its lock files in a different directory! I'm not sure I completely understand your reasons for wanting VM and procmail to have different files (a "spool file" and a "folder"), but I will concede I'm "proceeding at my own risk". <P>The original thread was the frequent mixing of procmail and VM. The usual solution for things like mailing lists is to have ~/.procmailrc write things to a "spool file", and then tell VM in ~/.vm about the relationship. My complaint about this scheme is that it requires me to keep the two files in sync, something I'd rather not do. <P>Other items were dealing with how I manage my mail with "procmail" - most of the stuff I get is of a "read and delete" nature; thus I have procmail sort incoming mail into files in a "toread" directory. Then, in VM, I can visit the "toread" directory and using Emacs' file completion to easily see what new mail I have. <P>The various solutions with vm-spool-file-suffixes or putting spool files in a different folder all have various problems with this scheme: <UL> <LI>names in the completion window (vm and vm.spool) <LI>file-completion to vm.spool if there is no "vm" file in my "toread" directory <LI>not being able to tell I have stuff to read by doing file-completion on the "toread" directory <LI>etc. </UL> <P>I *think* everything would be solved to my liking with the following two enhancements to VM <UL> <LI>visiting a folder with a suffix in vm-spool-files-suffixes visits the folder itself. That way if I use file-completion to visit "vm.spool" (no "vm" folder), VM does the Right Thing. <LI>do some kind of filtering on the file completion window - this may be a Emacs limitation </UL> <P>Anyway, my solution for now is to attack the problem from the other direction - that is, make procmail use Emacs' locks. That way when I'm visiting a folder in VM, procmail won't try to dump anything into it. <!-- Here endeth the vm-procmail FAQ --> <HR> <ADDRESS>Last updated on Apr 23 1998 at 22:26 by Samuel Mikes </ADDRESS> <!-- SOME LINK HREF'S ON THIS PAGE HAVE BEEN REWRITTEN BY THE WAYBACK MACHINE OF THE INTERNET ARCHIVE IN ORDER TO PRESERVE THE TEMPORAL INTEGRITY OF THE SESSION. --> <SCRIPT language=Javascript> <!-- // FILE ARCHIVED ON 20040214214031 AND RETRIEVED FROM THE // INTERNET ARCHIVE ON 20041018210538. // JAVASCRIPT APPENDED BY WAYBACK MACHINE, COPYRIGHT INTERNET ARCHIVE. // ALL OTHER CONTENT MAY ALSO BE PROTECTED BY COPYRIGHT (17 U.S.C. // SECTION 108(a)(3)). var sWayBackCGI = "http://web.archive.org/web/20040214214031/"; function xLateUrl(aCollection, sProp) { var i = 0; for(i = 0; i < aCollection.length; i++) if (aCollection[i][sProp].indexOf("mailto:") == -1 && aCollection[i][sProp].indexOf("javascript:") == -1) aCollection[i][sProp] = sWayBackCGI + aCollection[i][sProp]; } if (document.links) xLateUrl(document.links, "href"); if (document.images) xLateUrl(document.images, "src"); if (document.embeds) xLateUrl(document.embeds, "src"); if (document.body && document.body.background) document.body.background = sWayBackCGI + document.body.background; //--> </SCRIPT> <!-- LocalWords: procmail FAQ procmailex VM's fetchmail MTA MDA xbuffy comsat --><!-- LocalWords: mspools vm http www cs html setq priv inbox getenv foo baz --><!-- LocalWords: procmailrc sendmail mailfolders RMAIL lockfiles braindamaged --><!-- LocalWords: MAILDIR lib movemail spoolfile crashbox popmail Raymond's lu --><!-- LocalWords: ccil org esr qmail fetchmailrc teokem se teosom smtp hie mda --><!-- LocalWords: formail preprocess ds userid MDAs sbin oem Cc Bcc spam xbiff --><!-- LocalWords: acknowledgement Assman maildrops gnuclient cns ac uk stephen --><!-- LocalWords: uu gz Gorka gnac com Neal dartmouth autoload defun ney mbox --><!-- LocalWords: arg mapcar truename eq nondirectory concat kerryt akl co nz --><!-- LocalWords: optimation Kerry IFS LOGFILE TOdjb TOexim exim TOinfo var hp --><!-- LocalWords: Gael Marziou mailagent defconst dir indx Wiker etorwi eto au --><!-- LocalWords: ericsson Maslen david inboxes upcase downcase DanS conceed --><!-- LocalWords: sync toread psgml DTD nolist gatewayed MAILINGLISTS gorkab --><!-- LocalWords: cyberpass vmfaq htm Emmett Hogan's spookmime funet fi unix --><!-- LocalWords: iki faq internet faqs sunet contrib Eglen Stephen's eriksson --><!-- LocalWords: logfile informatik rwth aachen de --></BODY></HTML> |