[6482] in RedHat Linux List
Re: qpopper, imap3d, and UNIX mbox-format files
daemon@ATHENA.MIT.EDU (Wierdl Mate)
Wed Nov 27 15:20:47 1996
To: Tyson D Sawyer <tyson@rwii.com>
cc: redhat-list@redhat.com
In-reply-to: Your message of "Wed, 27 Nov 1996 13:23:47 EST."
<ML-2.3.849119027.9373.tyson@falcon.rwii.com>
Date: Wed, 27 Nov 1996 14:18:09 -0600
From: Wierdl Mate <matyi@wierdlmpc.msci.memphis.edu>
Resent-From: redhat-list@redhat.com
Reply-To: redhat-list@redhat.com
> > We've contacted Mark Crispin, author of ipop3d and much of the IMAP suite.
> > Mr. Crispin suggests moving to a mail system that doesn't store messages
> > in the standard UNIX "mbox" format. The mbox format is not designed for
> > modern day mail systems, and can't be manipulated very well. As a result,
> > you encounter programs like qpopper that make invalid assumptions about
> > how mail will be handled, or programs like ipop3d that require extreme
> > amounts of resources in order to work around the problems inherent in
> > the underlying mail system.
> >
> > Mr. Crispin suggests moving to an alternative mail system where messages
> > are stored in a different, more easily manipulated format, to improve
> > performance *and* security, and to reduce (or at least level-out)
> > resource demands. Unfortunately, this would result in incompatabilities
> > between the new mail system and older mail clients, such as "mail",
> > "Mail", and "elm", that don't support other mailbox formats and can't
> > retreive mail via POP or IMAP. The solution in these cases is to offer
> > wrappers that would retreive mail via POP3 or IMAP using "popclient"
> > or "fetchmail", store the mail in an mbox-format file, then invoke the
> > mbox-format-capable client to read the contents of that file.
> >
> > --
> > Steve Coile P a t r i o t N e t Systems Engineering
> > scoile@patriot.net Patriot Computer Group (703) 277-7737
>
> I would be very interested in a project like this. MH provides nice
> "scalablility" for large mail boxes but lacks the remote access
> features of POP or IMAP. I am now using an IMAP client for its
> intended client/server features but it really sucks with large
> mail boxes.
>
> If imapd, popd and procmail (or your favorite local mail handler) all
> used MH styles boxes that would be an improvment. I think that
> pine will use imapd so it will be OK. Elm would be the mainstream
> mail client I can think of that would need updating for this.
>
> I am beginning to think that a mail system built on an RDBMS (i.e. msql or
> Postgress95) with a Java client would be good way to handle large mail
> boxes efficiently, find what you want in the boxes and being able to
> access that information from a remote sight. The Java client could
> cache mail locally for improved performance online and to allow
> off line viewing as well. Java would allow for using the client
> on "other" OSes. I am frequently at conventions where there are
> Mac or Winblows machines availble for net access. They invariably
> have a Java capable browser available on them. With this senario I
> wound't need to loose the effective GUI interface when on the road.
>
> I have nearly no RDBMS knowledge, but I think that this could be done
> with a utility on the mail server that sucked mail from your inbox
> periodically or on demand and put in a database.
>
I may be wrong but I have heard a lot about Maildir lately, which
seems to solve the original problem. Qmail supports maildir.
Mate
M\'at\'e Wierdl
Department of Mathematical Sciences
University of Memphis,
E-mail: matyi@moni.msci.memphis.edu
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
________________________________________________________________________
http://www.redhat.com/RedHat-FAQ http://www.redhat.com/RedHat-Errata
http://www.redhat.com/RedHat-Tips http://www.redhat.com/mailing-lists
------------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe redhat-list-request@redhat.com < /dev/null
