On Tue, Oct 03, 2006 at 01:02:21PM +0200, Sturla Holm Hansen wrote: > This guide: http://workaround.org/articles/ispmail-sarge/ helped me a lot > setting up my mail-server. > Squirrelmail is a GREAT webmail sollution IMHO, I love it... > That is an excellent guide. But, IMHO, it has some serious shortcomings: * The database schema has zero relational integrity. (Want to add an email address for a domain that your mail server know nothings about? Go ahead. Want to delete an entire domain with 200 associated email accounts and not have the database cascade delete the email accounts? Go ahead.) * Uses MySQL. (please see previous point about relational integrity) * Uterly fails to use stored procedures to maintain consistency (e.g., tell the database that someone's mailstore moved, but it doesn't actually also move it for you). * Stores maildirs in a way that makes quota tracking more difficult. (It really should store mail in /home/username/virtualmail, or something like that, so that you only need quotas enabled on /home if that is what you want. It also makes privacy much easier to maintain as you don't have mail from different customers in the same mail store tree. * Stores passwords in **********plaintext********** !!!!!!!!!! * Let me repeat, passwords are stored in *plaintext*. * One more time: passwords in plaintext. * That is very bad. Anyhow, I have done to the trouble of "correcting" these shortcomings and others. I have some notes jotted down on how to take a server with a base Sarge install to an improved version of the sarge-isp-mail howto's setup. This includes encrypting passwords, using a real database (PostgreSQL) and basic things like relational integrity, consistency and some other neat tricks using stored procedures. For example, when you add a new email account, my setup will have the database automatically email the new user a welcome message with some helpful information and instructions about their email account. While I would recommend reading that HOWTO, I would say that anyone should also steer clear of implementing any sort of setup that stores passwords in plain text. That is asking for so many problems that it is not even funny. All it takes is one breach of the database and someone instantly has all the user passwords in plain text. At least with an md5 password setup, the situation is no worse than if you were using NIS or someone got a hold of your shadow file. Ideally, it would take so long to crack that it will not matter. Anyhow, I will have this written up in a real howto and posted Real Soon Now (TM). Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com
Attachment:
signature.asc
Description: Digital signature