Chacham's Journal: Verbiage: Setup email server, front-ends, coding our own.

Well, a friend and i decided to setup up his and my email system.

For email, we're using Exim 4. For me, a rule rejects all email at the smtp level for the base domain, rewrites the envelope header ignoring the username, and puts the subdomain as the user. Between that and aliases, i have three subdomains where the email comes to the same email address, but the header (in the email, not the envelope) is not changed. For him, he expects a dot in the email address, and ignores the data after the dot.

For example, for me:

1) [e-mail]
2) [e-mail]
3) [e-mail]

Case 1 is ignored, case two gets sent to [e-mail], case 3 gets sent to [e-mail].

For him:

[e-mail]

gets sent to [e-mail].

In either case, the header can be used for identification. And that all works fine.

Next comes the server. We chose Cyrus because its supports virtual users, IMAP, and Sieve. It's documentation is basically non-existent, but it can be done with some effort.

For the front-end we tried SquirrelMail, Horde /Imp, and IlohaMail.org. We found them hard to use or inconsistent in design, but we're using SquirrelMail in the meanwhile.

So, we decided to write our own web front-end. We brainstormed this Sunday for an hour or so, and decided to make a read only version (at first). We'll use Ajax so we only update the apropriate parts of the page, the Yahoo! UI libraries so it looks nice, javascript all over the place for automation (and AJAX), and Perl with CPAN's libraries for IMAP and the like. We'll skip mod_perl for now, and do straight CGI unless there's a reason to use mod_perl.

We discussed password storing. A persistent IMAP connection may not make sense, though even if it did, storing the password seems optimal. Cookies are usually used, but we'd like to skip those. I despise cookies. (I also despise flash, but my despisal for Javascript has gone down since Netscape stopped crashing on me. :) ) Saving it in the session seems like not a good idea, and in the user's HTML page too. So, for a basic encryption scheme we decided to use a crypt key (bi-directional, one key) created by the server on a per session basis. The encrypted password is stored in the session, and the key is stored in the user's webpage.

So, the order is:

1) User connects.
2) Check username/password.
3) Create session key.
4) Create crypt key.
5) Encrypt password with key, store is session var.
6) Store session key in a HIDDEN HTML INPUT tag.
7) Store crypt key in a HIDDEN HTML INPUT tag.

This way, the password is stored, but is only in clear-text in memory. It's not bulletproof, but we think it'll do the job.

We hope to design it to use CSS, so it can be made pretty later. Being neither of us really knows it, however, we may not get it perfectly.

I had started Learning Perl (actually, i have the third edition) some time back, but stopped when the need dropped. I just picked it up again, and even put it in the (coveted) bathroom--where most reading gets done--replacing Daughters of England (temporarily, i'm sure!). Needless to say, i hope to be hacking out some Perl soon.

I actually am not sure if this whole thing will work out. But for now, i'm going to enjoy being "involved" in a project.

Perlmonks

[IpalindromeI]

In case you don't know about it, check out Perlmonks [perlmonks.org] if you need any Perl help. One of the best Perl communities there is. If email is more your thing, there are also about a bajillion lists [cpan.org], but I believe the beginner list [cpan.org] is the best for new Perl users asking for help. I've never used or read that list, but I hear the helpers are very friendly.

Re:

[Chacham]

Thanx!