Writing an email server that delivers to a SQL database

Message

sp1nm0nkey · Post by **sp1nm0nkey** » Thu Mar 18, 2004 3:38 am

As the title says, I am thinking of writing a simple mail server that delivers user's email to a SQL database. I am going to write this in Java for portability and security. I'm going to start out with a simple SMTP server, and then add a POP3 and then an IMAP server. Eventually, I hope to impliment sub-mailboxes (extra email addresses that people get that filter into certain folders i.e. user foo could have mailboxes bar and quux. foo-bar@domain.dom would deliver to foo's bar folder, and foo-quux@domain.dom would filter to foo's quux folder, and foo@domain.dom would filter to foo's MAIN box). What additional features would you like to see in this project? What do you think would be a good name? Thanks in advance.

Kihaji · Post by **Kihaji** » Thu Mar 18, 2004 4:17 am

Why? The overhead of a Database is un-needed on a mail server. A mail server is nothing but a store and forward system, there are no searches or need to sort/selectivly query, all searching is done on the client side, after the mail is off server.

You could try to do all the searching/indexing stuff on the server side, ALA Exchange servers, but then your CPU power needs to scale as well as your storage as you get more users, as you are now storing and searching mail all on the server.

sp1nm0nkey · Post by **sp1nm0nkey** » Thu Mar 18, 2004 4:24 am

Well, the idea is mainly for my site (another free e-mail site) and I really dislike all of the mysql auth with postfix/exim/qmail, they've never worked. So I figured I'd just roll my own. I also figured that someone else might find it interesting, that's why I'm releasing it. Who knows, it's just in the planning stages right now and I might just auto-magicly get qmail+mysql working and I won't even need to do this. Of cource, if enough people show an intrest, I'll make it.

mavar · Post by **mavar** » Thu Mar 18, 2004 10:51 am

Just checked Sourceforge, and there (from a very quick glance) seems to be a project called dbmail which seems to be kind of similar to what you're aiming to do.

Check out the link at http://sourceforge.net/projects/dbmail/

But it's not in Java...

Regards,

/Magnus

nevynxxx · Post by **nevynxxx** » Thu Mar 18, 2004 1:16 pm

Kihaji wrote:Why? The overhead of a Database is un-needed on a mail server. A mail server is nothing but a store and forward system, there are no searches or need to sort/selectivly query, all searching is done on the client side, after the mail is off server.

One word for you, IMAP. Yes I know it's not a word, and yes I know your point is valid for IMAP too, since the client, copies all the mails off the server then does searches. But for slow connections this is not a good thing. Yes it would take some serious cpu power if you had thousands of users, but by that time you could have replicated databses on more than 1 server etc.
This seems like a sensible extension to imap to me. For some people. I wouldn't want to be the ISP running it, but then again, someone needs to find a use for the quantum computers they are trying so hard to make.

mtj · Post by **mtj** » Fri Mar 19, 2004 6:49 am

If you absolutely want to do this, consider tacking something on existing software. The first intuition I had when I read your post was: use normal mailfile delivery via an existing mailserver and write a process that starts from these mailfiles and pushes them into the database.
As for why:
- Mailservers are a complex piece of software and not only much work, but much security-critical work. Why start over when you have dozens of man-years of development time done in programs like sendmail, procmail, or exim?
- Design philiosophy: real hackers don't write from scratch, but extend what is there

Good reading: The Art of Unix Programming

On second thought: using exim (ok it's the one mailserver where I halfway find my way around the config), you can use external programs as transports. Intergrating a "push to database" transport shouldn't be that hard...

Bye, Marc.