the U of W MBX format that uses INBOX, is what the library uses, the actual
but it can be forced to use any location you want.
Actually Pine, qpopper, and UofW IMAP4 and POP3 servers all use
/var/spool/mail for their mbx location. (all of these use the UofW library)
And so do many of the mail servers, and the only one that doesn't is really
qmail, and qmail well it qmail.. good idea, just a little clutsy.
The Maildir format is well clumsy in that it's very wasteful, even Fidonet
figured that out a long time ago, that a message/file is wasteful (though
especially on DOS with large Hard Drives, but ext2 is a little better for this)
MBX isn't bad except that it's really hard to get multiple sessions to access
the same file, also when 2 processes get write access you could screw up
the spool file, this problem is inherent in most of the message base formats
too.
This leads to the ultimate user spool. Using a database for the storage. This
is actually an idea fidonet uses. I am working on something like this, for me,
because I have 6 accounts that are accessed by 5 people, and if we use
IMAP4 most implementations using MBX will disconnect each user in turn.
The other problem with mbx, if you have a large number of messages it takes
a long time to parse, and with POP3 this is actually bad. because you can
cause POP3 sessions to die (this has happened to me with folders with
10,000 messages)
Pros:
Session Safe - multiple processes can write to the same message area,
without corrupting the message area
Faster Access Times
Cons:
Processor Time - remember you still have to write a more complex
message.
Nothing able to access this as of yet.
This leads to the ultimate method of storing messages. SQL based
message area, such as using Postgres, or Mysql to store messages.
Pros:
Security - Multiple servers can access the database without using NFS,
and the benefit would be that locking is possible without playing with special
files.
Safe - Hard to corrupt the message base.
Fast - Hey it can be indexed, and especially if you only had one delivery
process, you could use persistant connections.
Cons:
Processing Power - the more mail incoming the more you will need
Hard Drive space - the more mail the bigger it is, upto 4 times.
Software - or lack there of.
Again there are no standards that really cover all a person's need, I do think
it's time to create new standards. Also to just make it simpler, just look at
the driver.txt with UofW IMAP libraries.
On 18 Sep 2000, at 13:02, j.linn wrote:
>
> In the light of some of comments on this list regarding Eudora
> and UNIX UCB mail formated INBOXes with Washington IMAP, I decided
> to have a look at the Washington MBX format.
>
> The configuration of EXIM was straightforward but the Washington
> IMAP model (driver.txt) is not the way we plan do it. It copies all the
> messages in INBOX to ~/INBOX whereas we just want it to work on the
> INBOX on the mailserver.
>
> What do others do who use the Washington software and MBX format.
>
> (As this is not strictly EXIM perhaps you could mail only Bme and
> not the list)
>
> John Linn
>
>
>
---
Jason Robertson
Network Analyst
jason@???
http://www.astroadvice.com
