[6463] in RedHat Linux List
Re: qpopper, imap3d, and UNIX mbox-format files
daemon@ATHENA.MIT.EDU (Tyson D Sawyer)
Wed Nov 27 13:25:56 1996
Date: Wed, 27 Nov 1996 13:23:47 -0500 (EST)
From: Tyson D Sawyer <tyson@rwii.com>
Reply-To: Tyson D Sawyer <tyson@rwii.com>
To: redhat-list@redhat.com
In-Reply-To: <Pine.LNX.3.91.961127122003.25815C-100000@washington.patriot.net>
Resent-From: 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.
Ty
--
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
