[plug] client-server e-mail query system?

[indy at THE-TECH.MIT.EDU]

Interesting question.
At a company where I used to work, we ended up creating a small app
that took incoming mail into a DB and had search and display functions.
This was for mail to $address from domain registrars that various
staff needed to read and search through.

At that time, when I looked around, email wasn't really
used in a "paper trail" fashion so there weren't many apps
to handle it, but maybe someone has come up with one since?


Indy



On Wed, Jul 09, 2003 at 11:47:14PM +0800, Denis Brown wrote:
> Dear PLUG list members,
> 
> Maybe I'm not getting my terminology correct or my search terms, or maybe
> this hasn't been done before???
> 
> I'd like to search for, retrieve and display only selected e-mails from a
> large mail spool rather than use a more conventional IMAP+browser or
> MTA+text client like pine, elm, ...   I'd like to do this over a low
> bandwidth link.   Consider this example:
> 
> I have thousands of e-mails on a server.   I'm at a remote site, perhaps
> with a dial-up connection (low bandwidth) and I want to access the one or
> two e-mails from Joe Bloggs, relating to a widget order, received some
> time in 2002.   With a POP style solution employing a client like Pegasus
> or Eudora, or... I'll be sitting there for hours downloading the stored
> mail to my local client, in order to do the search and display locally.
> No thanks.
> 
> Using IMAP plus a browser is probably better but I'm still going to have
> to grab down a lot of unwanted stored mail - no?  Using a client like pine
> or elm certainly gives me the option of doing a find (a "Whereis" in
> pine-speak) but again I get to grab a lot of superfluous mail in the
> process.
> 
> Hence the thought: compose an SQL-like query on the remote,
> thinly-connected machine, send it to the server and just get back the
> search results, the e-mail message(s) and attachment(s) if any.   I dare
> say this isn't a unique thought but cannot see it talked about anywhere.
> So maybe it's a Bad Idea (tm) for a variety of reasons.  Thoughts /
> comments please?
> 
> TIA,
> Denis
> 
> 

-- 
Indranath Neogy
<indy at the-tech.mit.edu>