On Thursday, 09 December 1999 at 10:45, Chris Green wrote:
> IMAP4 - typically corporate or university 'intranet' with fast,
> reliable links to your IMAP mailboxes. Thus it makes
> sense to use IMAP4 maiboxes for everything.
>
> POP3 - typically used by individual (sometimes family) dial-up
> internet users. Slow, intermittent, unreliable link
> to mailbox. It doesn't make sense to store any mail in
> the POP3 mailbox.
>
> If you reverse the above scenarios, i.e. if you have a reliable,
> permanent connection to one (or more) POP3 mailboxes it makes perfect
> sense to use it in the same way as one would an IMPA4 mailbox.
> Similarly if you have a dial-up link to an IMAP4 system it makes
> little sense to leave any mail on the IMAP4 system, you download it
> all to your local system just as you would with a POP3 mailbox.
I'd just like to say that I have my IMAP account on a server that I
access over a modem. I still use IMAP as the server access protocol it's
supposed to be. When I downloaded my mail, I used POP. Of course, that's
why I like to do speed optimisations - when I get my DSL line, things
may change :)
> > The point about POP3 support is that fetchmail can do really
> > everything mutt's own POP3 support gives. However, you won't be
> > able to put reasonable IMAP support into an external program, unless
> > maybe you design it as a filesystem kernel module which presents
> > maildir-style folders to the user. ;-)
> >
> I (and a lot of other people) keep saying that fetchmail _can't_ "do
> really everything mutt's own POP3 support gives", or it can't do what
> mutt's POP3 support _could_ do. In particular fetchmail doesn't allow
> the user to selectively download and delete messages from a POP3
> mailbox having been shown the headers.
yes, but this should be trivial to add to fetchmail. I hope to get it
done. Note that if we could put full IMAP functionality in an external
program and have a simple interface to it from mutt, I'd be more than
happy to do things that way. But IMAP is much more complex, so that
scenario isn't realistic.
> I really think that mutt should either support both POP3 and IMAP4 or
> neither.
they aren't equivalent. POP is an MDA protocol, IMAP is an MUA protocol.
Ideally, fetchmail wouldn't support IMAP (not that I object in practice
- in fact I enhanced some of fetchmail's IMAP support), and mutt
wouldn't support POP. But since that would make things less convenient,
I like the fetchmail-enhancement proposal...
In short, as David says, the bulk of fetchmail's code is dealing with
weird, quirky POP servers reliably. I for one don't want to try to
recreate fetchmail's years of experience in mutt. On the other hand, the
IMAP code is almost entirely just support of the base protocol. If weird
servers become a problem, I would actually prefer to see the caching
IMAP server I was talking about in between mutt and the actual server
over adding workarounds to mutt. Of course the caching IMAP server has
to exist first...
-Brendan
