suggestions for web pop email system

archon has asked for the wisdom of the Perl Monks concerning the following question:

I am creating a web based system for users to check their mail. this involves three separate machines (ldap, web, pop). so far what i have is:

a user authenticates through apache mod_auth_ldap to access the directory.
the script takes their username from %ENV and asks the ldap server what their mail password is.
the script checks their mail headers from the pop server and shows the user a list of from/subject etc for them to click on
clicking on an email calls a new script that starts the process all over again, grabbing the email password from ldap and the complete mail that the user wants to read.

potentially there could be ~150k users of this system, though i figure the actual usage will be MUCH lower. at this point i'm only being asked to produce something that 'works,' e.g. i am supposed to worry about scalability later. i have something that works, but i would like to worry about scaling now to save myself future troubles.

the first major problem i saw is that i have to grab the password from ldap every time i want to do something. i'm not sure of the best way to avoid this. the second script isn't called from a form. it's just passed a message number to download. i could hack mod_auth_cgi to put the password in the environment, but that seems like a bad idea for some reason.

i've used zope before and i think it solves some of my problems, but i didn't really like using it at all. maybe it has improved or there is something better out there.

i am wondering what potential problems/solutions you might know about from experience with such a system.

Comment on suggestions for web pop email system

Replies are listed 'Best First'.
Re: suggestions for web pop email system by btrott (Parson) on Jun 15, 2001 at 21:32 UTC
As you imply, probably your best bet is to introduce some form of caching of the POP password that you get back from the LDAP server. The manner in which you do this is the question. Like you, I would shy away from putting the password into the environment :), but I think you've got the right idea: you want to cache the password on the web machine so that you don't have to keep asking for it from the LDAP machine. For security reasons, you should definitely encrypt the passwords that you cache; probably your best bet is to just encrypt them using a symmetric cipher, like Crypt::Blowfish, used in CBC mode (Crypt::CBC). You have to be careful with the key you use as the encryption/decryption passphrase; if you store this key in a file anywhere, you're basically negating the benefits of encrypting in the first place. So you need to find a way to store the passphrase w/o storing it in plain text on disk; one way to do this might be to store it in shared memory or something like that. The question then becomes: how do you cache the passwords? Several options that I can think of: Use something like Cache::Cache to cache the encrypted passwords on disk, in memory, etc. You can set the cached passwords to expire after some amount of time. Use something like Apache::Session for the caching; treat the transaction w/ the user as a session, which means that when the user enters, he/she gets a unique session ID. The encrypted mail password then is stored as part of the session data, and you can store that session data in any place that Apache::Session supports: database, filesystem, etc. This scenario works well if you already have the concept of a "session" while the user is actively in the system; the session expires when the user logs out, for example, and then you can get rid of the session file/record/etc. Either of these options will help you in terms of efficiency, because you're effectively cutting out one of the steps from each request (ie. getting the password).	[reply]
Re: suggestions for web pop email system by Spudnuts (Pilgrim) on Jun 16, 2001 at 01:29 UTC
If you would not mind spending time using something else (not perl; gasp), you might enjoy what you see from the IMP project. They have a fairly complete, solid, and free web mail system that scales nicely. I believe that it meets most of your requirements.	[reply]