On Thu, Dec 09, 1999 at 10:53:17AM +0100, Thomas Roessler wrote:
> On 1999-12-09 00:54:26 -0700, Kim DeVaughn wrote:
>
> >> You are free to write such a program, and you are also free to
> >> design a generic interface between mutt and external mailbox
> >> backends. Note, however, that just downloading messages into
> >> some local folder and using the usual mbox/maildir code is not
> >> an option.
>
> > Why not ...? That is exactly what folks using POP3 are being
> > told to do with fetchmail. Why the "double standard" for IMAP
> > support?
>
> It's not really a "double standard". All you can reasonably do with
> POP3 is fetching messages to your local spool. With IMAP, you can,
> for instance, store messages in server-side folders, you have
> support for (and problems with) concurrent folder updates on the
> server, etc.
>
That isn't "All you can reasonably do with POP3", it's perfectly
reasonable to treat a POP3 server as a single mailbox much the same as
a local mailbox file. You can see a list of the E-Mail messages in a
POP3 mailbox, you can selectively view messages in a POP3 mailbox and
you can selectively delete messages in a POP3 mailbox. IMAP4 just
adds the ability to have multiple mailboxes (possibly a hierarchy too)
and probably makes the MUA's job a bit easier.
> POP3 is some kind of kluge to get around the "last mile" when the
> end user's system doesn't have a full-fledged mail transport system.
> With IMAP, no mail folders on a local system are necessary.
>
Neither are any local mail folders _necessary_ with a POP3 mailbox if
you're happy with a single folder to store mail. POP3 can store mail,
IMAP4 just adds the ability to have multiple, differently named
folders. Both are quite similar from a user's point of view, you can
get a list of mail headers, you can download individual messages to
the local system.
It's only when IMAP4 is provided _locally_ that it really allows the
MUA to use it for storing much mail. When it's not local the delays
(in my experience) make it not really usable for storing and
retrieving lots of mail. IMAP4 over a slow link is *very* similar to
POP3. The major difference is more to do with the environment where
IMAP4 is commonly found compared with the typical POP3 environment:-
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.
> 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.
I really think that mutt should either support both POP3 and IMAP4 or
neither.
--
Chris Green ([EMAIL PROTECTED])
Home: [EMAIL PROTECTED] Work: [EMAIL PROTECTED]
WWW: http://www.isbd.co.uk/
