Re: Threading Mail
dman wrote:
>
> On Wed, Dec 26, 2001 at 05:23:49PM -0800, Erik Steffl wrote:
> | dman wrote:
> | >
> | > On Wed, Dec 26, 2001 at 04:21:53PM -0500, Brian Nelson wrote:
> | >
> | > | Not true! I switched from mutt to gnus. It's IMAP support was too weak
> | > | for me,
> | >
> | > IMAP in mutt is actually somewhat controversial. The author doesn't
> | > really like it (mutt is _just_ a MUA), but there would be too much
> |
> | isn't it even more important for it to be a IMAP client? any other way
> | of working with email makes it a little bit more then MUA (or little bit
> | more then is neccessary).
>
> I don't get what you are saying here. Mutt doesn't really need IMAP
> since fetchmail already takes care of it.
no, IMAP is not equivalent of POP3. Instead of accessing email stored
in one or another format in files MUA accesses IMAP for all its email
storage needs. Instead of reading the file it asks IMAP server for a
message. etc... that way you can access the same mail account using
different tools (even at same time) and never worry about technicalities
of file locking, about which format they use and how well they support
it etc. (because all tools access email only via IMAP server)
> | mail storage - separate tool (IMAP)
>
> Right -- fetchmail. However, as I said, too many people would
> complain too loudly if the current IMAP code in mutt was removed.
email storage - where the email is stored. traditionaly this is just
files, mostly mbox or maildir. that's what is replaced by IMAP. that way
you have no email in /var/spool/mail/username or ~/mbox or wherever your
email currently is, the email is stored by IMAP (you don't care where)
and you just ask IMAP to performa various operations on mail.
btw some IMAP servers implemente mail storage in a way that makes
physical email really inaccessible to you (cyrus), other basically
consider you ~ a big bunch of mbox/maildir files (uw-imap, it's useful
to limit it's namespace to e.g. just ~/mail, otherwise you see
everything as mail, slightly confusing)
> | mail filtering - separate tool (sieve, procmail)
>
> I don't see 'sieve' anywhere in "apt-cache search". I did read the
> RFC though.
it's part of cyrus (maybe some other IMAP servers as well, not sure if
there's a standalone implementation). You can, of course, continue to
use procmail with IMAP server.
> | unix philosophy... as long as they all work together...
>
> Yep.
>
> | IMO mutt is already trying too be too many things at once (granted,
> | they are all email related:-)
>
> Which things (aside from POP and IMAP)?
it also filters email. then it has this way of 'processing' email -
scoring, doing various things between swtiching folders etc. not saying
it shouldn't be there but I would rather see a separate tools for
'post-processing' email, independent of MUA (it would be sort of
automatic MUA, something what sed is to vi).
btw IMAP is not one of those 'too much' that I had in mind, IMAP is
eesential, but not as download protocol (i.e. using it as if it were
POP3) but as real IMAP (that's how it's implemented, you see IMAP
folders as normal (sort of) folders.
this is how my system works:
<out> -> postfix -> cyrus deliver -> sieve -> IMAP (cyrus) -> MUAs
<out> -> fetchmail -> postfix -> see above
MUAs -> postfix -> <out>
that way I can use any IMAP MUAs (and still have email filtered the
same way), I can read my email from various places (mostly from one of
my home computers or from work), don't have to worry whether I closed
one MUA before opening another one (file locking funnies) etc. also much
less chances for screweup due to unstable MUAs (I change programs that
have user interface lot more often then programs that work in behind, I
guess that's true for most people). it's email paradise! if you don't
have your email set that way you owe it to yourself to try it (you don't
have to use the same components, of course)
erik
Reply to: