On Mon, Mar 01, 2004 at 05:33:34AM EST, Raúl Núñez de Arenas Coronado wrote: > * David Yitzchak Cohen <lists+mutt_users@xxxxxxxxxxxxxx> dixit: > Nice to hear from you again :) right back at ya, dude :-) > > > The problem is the connection: will Mutt keep the IMAP > > > connection open if I switch to a local mailbox? I want to know what > > > would happen if I switch to any of my local mailboxes to reply to an > > > email stored there. If the connection is still open at that time, the > > > outgoing email will be accepted, otherwise it will bounce back. > > Empirically, I just found that to be the case. In other words, the > > connection is not closed down by Mutt. Will the connection eventually > > timeout if you don't return to an IMAP folder? I don't know the answer > > to that question, and since my imapproxy [1] would prevent the server > > from timing out the connection, I have no easy way of testing (short of > > disabling imapproxy, which I'm obviously not about to do). > > I'll take a look at imapproxy ;) Should I use it like a > '$tunnel'? Yes, it's invisible to Mutt. You simply launch it as if it were your imapd, and it'll take care of everything else. In its current form, though, it only supports local IMAP and SSH-tunneled IMAP connections. If you give me an hour or so, I'll add TCP-based IMAP support. . . > > > OTOH, I would like to know what will happen if I go to my IMAP > > > folder, go to a local mailbox and back to my IMAP folder: will a new > > > connection be opened or will the last one used instead? > > I have an empirical answer there, too. The connection is wisely > > reused by Mutt :-) > > Which Mutt version? I've tested this morning and a new connection > seems to be opened :( (I'm using 1.4.2.1) At first Mutt opens a > connection from local por 58885 (or something like that, you know...) > to remote port 143, and when I switched to a local mailbox and back > to my IMAP connection, a new connection was opened, my /proc/net/tcp > showed two connections (I didn't remember to look the state of the > first one, sorry). I'm on current CVS (a few days behind, but nothing's changed) with no patches. (The actual source tree that I use is online [1], along with an autogenerated tarball [2] and an autogenerated diff from CVS [3].) When I switched from my inbox (IMAP-based) to a local mbox and then back to my inbox, the imapd that had been used before was reused, as evidenced by the PIDs, process start times, total CPU time used, etc. > Anyway I'm having problems with IMAP and my ISP, so I don't know > if I will be able to switch to IMAP :(( If your ISP supports IMAP but you don't want to have to deal with it, the easiest thing to do is to run a dumb IMAP client that logs into the IMAP server, and then just hangs around doing nothing. You can then use email however you want (POP, IMAP, whatever), and SMTP will be fine. The other option is to give up on IMAP and use fetchmail to get your mail by POP2/POP3/whatever. If fetchmail is running in the background with a short polling interval (1 minute in my case, for instance), you should be able to send mail any time you want, since you'll always "have just finished checking your mail via POP" :-) - 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:
pgpj4nBNADZUU.pgp
Description: PGP signature