Hello,
There are a few other points in James I wanted to comment upon. I don't know exactly
what your plans for changes are, but these are some ideas that came to my mind. Sure,
this is nothing for an 2.1.1 release, but nevertheless ..
I've read about the way James supports Virtual Hosting so far. One question came to my
mind:
Why do users need to have a unique name ?
You could just request that they have a unique username / password hash combination.
Another thing that left me wondering was the database format. As far as I know, it's
not very efficient to have
non-numerical primary keys.
Give each user an unique numerical primary key,
and create another table which just maps eMail Adresses to user-ids. And at once, you
have a very flexible and fast database structure which would support virtual hosting,
multiple eMail Addresses per user and so on.
Of course another table with local domains would help a lot as well. In that table I'd
have at least 3 fields:
domain-ID (numerical, primary key)
domain-Name (varchar)
catch-all-user (numerical reference)
Also I'd possibly include the user id for domain-administrator users.
Of course I do not know about the file based repositories, but from a database
perspective that's how I'd do it.
In the inbox table, I'd give every message a unique numerical id, and associate it
with the recipients user-id. Also I'd add another field specifying the name of the
folder (POP3 could just ignore that, but for IMAP this is just as well a neccessity as
the numerical ID).
To make it even more scalable I'd add another table with folders, associating unique
folder-ids with folder names, parent folders and user-ids.
I guess this would require writing an alternative JDBC Repository, but it would make
virtual hosting and IMAP much easier, and could improve the performance and
scalability for larger systems a lot.
Some more ideas:
Add a size-field to every message.
Add message count/mailbox size as well as quota fields to every user.
Add a timestamp to every received message to be able to filter by date. (Like "delete
all mails older than XX days" or "show all mails from 3 to 10 january").
Add an extension-header field to messages in the db, so they can be marked somehow.
(You could for example give them spam-levels from statistical analysis, or mark them
as likely containing a virus, or as having been modified by a virus scanner/filter)
For powerful search capabilities, add full-text indices to the message-bodies, so they
can be searched (using text fields instead of blob in MySQL).
I hope this wasn't too chaotic. It's late :)
bye,
Kai Londenberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
