Evolution sucks??

[Ben Scott]

On 2/13/07, Paul Lussier <p.lussier at comcast.net> wrote:
> Well, technically I think the question was something along the lines
> of "Why do you require the mail storage to be physically co-located
> with the mail client?" or something to that effect.

  That sounds like something I would say.  :)

  And technically speaking, the use of MH *as part of a filtering
mechanism* doesn't require that.  That is to say, one could use MH as
a storage format, and do processing with the MH tools, but still use
IMAP to access the mail.

  Of course, there are obvious  advantages to using the same tools for
both filtering and reading.  Aside from knowledge and software
maintenance factors, that would make it easier to do ad hoc, one-off
processing operations.

  But like I said with your previous example, I can now see some
advantages to using the MH family for storage/filtering, even if I
don't use it as the MUA.  I missed that in the past client-centric
discussions.  So I still think assuming mail storage *has* to be
physically co-located with the mail client is sub-optimal.

> >   But, since they aren't related,
>
> But unfortunately, they're very intertwined from the perspective of
> IMAP and most IMAP clients.

  Poor word choice on my part.  Of course they're related/intertwined.
 :)  I was still trying to mean "not the same step in the process".

>> I've always applied different tools to the question of filtering.
>> I've always combined my use of IMAP with server-side
>> filtering/scripting.
>
> Unfortunately approach fails miserably in the
> my-mail-server-isn't-controlled-by-me universe.
>
>>  I use the mail "server" to do all my mail processing, and my mail
>> client(s) to do my mail reading.  (In my case, the IMAP server has
>> sometimes been my own PC.)
>
> Great solution for a system where you own or otherwise control all the
> pieces from the receiving MTA and the MUA.

  The thing is, if you're using (say) fetchmail to suck all your mail
off the "real" mail server, and storing it on your PC, you're
essentially turning your PC into part of the mail delivery chain.  The
"real" server is no longer the final delivery point.  Like I said, at
times, my "IMAP server" has been a PC under my direct control.  For
example, at one time, I was POP'ing mail from a couple ISPs with
fetchmail onto my own home "server", which I then of course used IMAP
with (which let me read my mail from either 'doze or 'nix).

  Of course, none of that works in a crappy-mail-client-is-mandated
environment, but we're all equally screwed, there.  :)

>> Hmmm, come to think of it, are there IMAP servers that properly
>> support the MH format?
>
> I think cyrus does, but it's not simple.  cyrus uses a very mh-like
> store to begin with, but it's not entirely the same.

  I'm no expert, but I don't think Cyrus supports anything but the
Cyrus mail store.  Their approach has always been, "Hey, we're
designing a tool for a specific purpose, if you want something else,
use something else."  There's something to be said for that.  Maybe
there are patches or import tools or something...

> > (I know UW-IMAP claims to, but UW-IMAP claims a lot of things....)
>
> Yeah, like being an IMAP server ;^P

  Yah, I was thinking of that... :)

[re: gnus]
> For me, the "killer feature" is that it's in emacs.

  As with the "MH everywhere" approach, there's a lot be said for that
sort of thing.  Emacs is considered by many to be an excellent text
processing tool, and it has many, many features in that area.  Email
is mostly text.  It makes sense that they go well together.  Plus I'm
sure it's all nicely capable of being controlled/scripted/programed,
like everything Emacs.  :)

-- Ben