>>MS Exchange... one big Database Exactly...
And that is one reason why I wouldn't touch this SQL idea with a 10 foot pole.. the fact that Exchange works this way only proves my point... I hear all the time about Exchange servers crashing and the administrator having to rebuild the database while the mail server is down for the next 10 hours. The bottom line is that using a SQL DB backend as mail storage is putting all your eggs in one basket. I have a much simpler solution to accomplish the problem that this was idea was originally attempting to solve... simply place the spams that are caught in a folder on the mail server that is accessible via webmail. Then create a separate program to periodically enumerate through the spam folder in all the accounts on the server to delete spams over X days old. If needed, you could still have a database with the basic info about the spams (date received, subject line, recipients, from, message file name, etc) to use for e-mailing "digests" to the user... and this DB's stability wouldn't then have to be tied to the overall reliability/stability of mail services. Also keep in mind that SQL doesn't always mean better performance... I've seen many web sites that deliver content dynamically from a SQL database backend where there were noticeably large delays between page loads, for example. Rob McEwen PowerView Systems [EMAIL PROTECTED]
