Virtual Hosts, Database Structure and IMAP-Folders

[ka...@my-vwclub.de]

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

RE: Virtual Hosts, Database Structure and IMAP-Folders

["Noel J. Bergman" <no...@devtech.com>]

Kai,

You have a lot of reading to do in the archives.  :-)

Your comments are based upon James v2 repositories, and we're looking at
replacing the user repositories with JNDI, and using JavaMail interfaces for
stores in James v3.  And, yes, we'll have to implement optimized service
providers, as well as support the current formats.

Virtual hosting is something that still needs to be resolved, but it ought
to be in the context of the rest of what we're doing.

> Why do users need to have a unique name ?
> You could just request that they have a unique username / password hash
combination.

When e-mail comes in we need a unique mailbox.  We don't need have their
password; we need a unique SMTP -> mailbox mapping.  And what if two people
with the same name chose the same password?  What do you do if someone loses
their password?  You want a unique mailbox ID, although it does not have to
be their e-mail name.

> Give each user an unique numerical primary key, and create another table
> which just maps eMail Adresses to user-ids.

You might want to look at the JDBCVirtualUserTable mailet.  Does that and
more, except we don't need a nuberical key.  Non-numerical primary keys
aren't actually that bad, and we don't do much more than a straight lookup.
If we were doing a lot of database manipulation, I would agree with you.

FWIW, I'm hoping that in James v3 we will include hsqldb, so that we can
always assume the presence of a database, although there is a need to allow
some things to be in the file system if user want to configure it that way.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org