On Mon, Feb 23, 2004 at 06:32:20PM EST, Colin J. Raven wrote: > Current setup: > FreeBSD4.9 STABLE > Postfix w/Courier IMAP > > My mutt is pointed at /home/colin/Maildir/new to look at mail, I have no > clue if this is correct or not. Should it just be /home/colin/Maildir or > is it indeed necessary to point Mutt at the "new" folder. (It seems to > read mail either way, but putting "new" in the path causes one more > keystroke. That's an observation, not my reason for posting hahaha) Obviously, you're not using IMAP for that account :-) If you want to use IMAP for that account, you may be able to do imap://localhost/INBOX or something like that to access it through IMAP instead of directly as a maildir (assuming you want to, of course!). > I would like to retrieve mail from another company account on the same > physical machine, and also mail from a different physical machine. Call > them account2-local and account3-remote. We'll assume that account2-local and account3-remote are both of the form user@host (i.e., all the information that uniquely identifies an IMAP account), okay? > Should I retrieve them both via imap, You can, if you want to. > and if so, where in my .muttrc > should I be telling mutt that it's checking remote (and/or local) mail > for other accounts? Well, you'll need to tell it that the inboxes in those accounts are also capable of receiving new mail (so Mutt polls them for you), so you can put something like this in your muttrc: mailboxes ! imap://account2-local/INBOX imap://account3-remote/INBOX Other than that, everything can stay more-or-less the same. An alternate solution to the whole problem is profiles, which allow you to switch "modes" from your local account to account2-local or account3-remote, and have all your settings change accordingly. I don't use profiles, so I'm the wrong person to ask about the topic. (I simply fetchmail(1) all my mail from all my accounts to my own local IMAP server, and work from there.) > Some reading indicates I should be doing this somewhere: > imap://hostname/INBOX > (all imap folders are below inbox and are INBOX.whatever) on both of the > "other" accounts as well as the main one mutt is now checking Yup, if you want to change to the inbox of account2-local, for instance, you'll want to type the following line (including the newline at the end): cimap://account2-local/INBOX ...and if you want to move something to your junk folder in account3-remote, you'll want to type this line instead (including the trailing newline, again): simap://account3-remote/INBOX.junk Is everything starting to make a little more sense now? :-) > Should I do this with both the other account on the local machine > **and** the remote machine?? Yup :-) > What else should I include in .muttrc along > with the imap thingy above?? Well, here's the IMAP section of my own muttrc: #IMAP settings: set imap_user=dave #sorta undocumented - necessary for reasonable behavior with UW IMAPD: set folder=imap://mail.dave.tj/Mail set imap_home_namespace="Mail" #This doesn't really work so well - WU-IMAPd doesn't realize it's a symlink to # my inbox, so it doesn't move new mail from /var/spool/mail/dave into there: #set spoolfile="=INBOX" #...so we have to go back to this: set spoolfile="imap://mail.dave.tj/INBOX" mailboxes ! set timeout=1 #Note the below doesn't work anyway, as the IMAP server logs us out by itself, # but it eliminates the need for password entry, which is cool: #Use the IMAP server locally using pipes instead: #set tunnel="/usr/sbin/imapd" #Attempt to use my own keepalive-generating proxy: #doesn't allow selection of other mailboxes, for some odd reason, but neither # does /usr/sbin/imapd directly ... not sure what's wrong. . . #works now just fine, mailboxes and all :-) set tunnel="~/src/imapproxy/imapproxy" You'll want to note that some of the comments are getting severely out-of-date there, and probably ought to be trashed by now. (The last comment in any given block is always correct, however.) The next thing to note is that I set my IMAP username; you don't want to do that, since you'll have different usernames depending on the account. (In other words, you can't do what I did with imap://mail.dave.tj/blahblahblah - you'd need to do the equivalent of imap://dave@xxxxxxxxxxxx/blahblahblah every time.) You'll also notice I have my folder variable set to my IMAP folder listing, so =spam is a shortcut to imap://mail.dave.tj/Mail/spam; you don't want to do that, either, since each account is going to have its own folder listing, with its own location. The simple answer here is that profiles will almost certainly be a lot easier if you want to treat each account separately, but as I said, I can't help you there. > There are no timeout issues since the > servers and me are on mondo fast connections. The timeout has to do with how often to check for new mail if you're not doing anything at the terminal. It has nothing to do with connect_timeout (which is probably what you were talking about). > I just wonder of there are > other things unique to a well groomed imap .muttrc that should be there > (wherever "there" is...at the top of the file I'm guessing) If you look at the bottom of my config above, you'll notice I've set the tunnel variable. This has to do with the IMAP server getting bored of sitting and waiting for Mutt to say something (which on my server happens after 30 minutes of inactivity - following the RFC minimum to the letter), and silently dropping the connection. Mutt then tries to do something at some later point, and gets a rude awakening, often so rude that Mutt just plain dies on it. Now, the classic solution according to the manual is to set imap_keepalive to a very small value, so it keeps your IMAP server from getting bored. However, what happens when you decide to pause Mutt (say, to compose an email - mutt must wait(2) for the editor to exit before doing anything more, and obviously can't send NOOPs to your IMAP server in the meantime)? In most cases, you'll probably finish composing your mail within 10-15 minutes, and you'll be fine. If you get sidetracked in the middle and leave your editor open while you go do something else for half an hour, you'll discover when you return that your IMAP connection (including all changes you've made since the last mailbox sync) is toast. My imapproxy solves that problem by NOOPing the IMAP server when Mutt doesn't for any reason (including if you outright suspend Mutt (^Z, for example)). I've tested it with over 24 hours in my editor, and the connection was still there when I returned. I strongly advise using it if you're going to use IMAP. > Sorry for the complete ignorance concerning imap and also for multiple > questions. I fought against Maildir format before it was implemented on > both servers...perhaps for exactly this reason in that I didn't know > anything about the protocol or how to configure stuff like this. As can > be seen I lost, but the file locking stuff and separate message files I > do now see the point of making the change. I gracefully admitted that > our IT cognocenti knew precisely what they were talking about, and my > /var/spool/mail habit/belief was ancient and inefficient. Yeah, the maildir format has a bunch of major advantages over the mbox format. (I still use mbox, of course, mostly because my IMAP server (UW-IMAPd) doesn't support maildir, and I don't want to switch to the Cyrus IMAPd.) > Thanks kindly for help and guidance that list gurus may wish to > contribute. Opinions ideas, knowledge are all joyfully received. /me ducks. - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpIap2OwL1bb.pgp
Description: PGP signature