Absolutely! Given the already vocal comments on this list, here's my few cents worth:
The lack of a web-based GUI is probably the one main feature that keeps some of your competitors in business. Given the relatively low-cost of Declude, even the Pro version compared with the multi-thousand dollar prices of other products or the $1-$5 PER USER prices of services such as Postini and Brightmail, making it a separate product is very reasonable. (It also doesn't penalize the command-line jockeys that have already said they aren't interested). There are several types of admin interfaces that are desirable. You could implement one or more of them, possibly even one at a time: System Admin - a GUI interface to simplify the configuration/management of the whole system - this would be used only by current administrators. Domain Admin - a GUI interface to control settings that affect one email virtual domain. Similar to IMAIL Webmail, many of us delegate control over each email domain to the "owner" of that domain. This is twofold - to offload administrative tasks and to empower the domain owner to be able to perform tasks quickly when they need to (reset a user's password, etc.) User Admin - a GUI to allow individual users to adjust their own per-user settings only. User Mail Review - a GUI to review "held" or "suspect" SPAM and either delete it or allow it to be delivered (I'm thinking a la Postini or Brightmail and how they provide this feature to their OEM ISP and corporate users.) Some general guidelines: The System Admin GUI could be a simple front-end around editing the actual existing text configuration files, but that might not be worth the trouble. (If an Admin knows enough to edit config files, they don't need a GUI wrapper around it, but there are many corporate Admins that could use hand-holding system admin GUI.s) For the other admins, the WebMail interface should provide a nice, form-based high-level conceptual interface. The user should never see the low-level real config confiles nor should they see all the syntax and options in gory detail. A really cool feature would be to allow us (The system admin) to define pre-created "sets" of settings and then, if we choose, to only allow the Domain or User GUI to select among them. For example, we offer our clients today a choice of "no blocking", "conservative/safe blocking", and "aggressive blocking" and use differnet configurations for each. If we had a GUI that allowed our users to select between these three levels any time they want, determine what to do with failed email (delete, mark it, move it to a spam review folder), that alone would do 60% or more what we need to make our admin lives easier and empower our users to control the system with as little or as much filtering as we let them. If the GUI let's users or domain admins configure individual tests, it should present the tests through a "translation menu". In other words, let us set up a mapping between the real test and a user-friendly test name for the GUI. I can see that we might want to give our users a list of tests to choose from, but listed in simple terms/names "non-US Mail", "Bad Message Structure", "Known spammers - strict", "Known spammers - loose", etc. where we control what tests we put underneath, the weights, etc. Implementation: This is probably where you need to make some tough decisions. You won't be able to please everyone. I strongly advise against using anything that requires the purchase of 3rd party software. Specifically, do not use Cold Fusion, or other proprietary web application. Since Imail runs on Windows servers, being compatible with IIS is not only reasonable, but is synergistic with what most of us do. If you do use IIS, then we can all use host headers/IP mapping and control easily what URL or port the admin site uses instead of fighting the port 8383 problems we have had with Imail for so long because they use their own proprietary web server that does not support host headers. Putting on my programmer hat, I think that you should consider using Microsoft dot NET technology. The dot NET framework is FREE, and available now, and the server controls/user controls and XML architecture makes programming a lot easier. The Microsoft Mobile Controls would even allow the GUI to run on portable devices such as Pocket PC, Cell Phones, and Palm Pilots for us "admins on the go". Although you would need to invest in a copy of Visual Studio for development, the customers (us) would not need anything special other than IIS and the FREE dot net runtime. (And the single-language development tools such as Visual Studio c# or VB are only $99 retail anyway.) With Dot NET and VS, you can easily include the MSDE database which is a royalty-free version of SQL Server 2000 that the application could use to store configuration files and settings in an easier to manipulate way than flat text files. By making everything databse driven underneath, anyone could supplement the GUI easily simply by reading/writing database tables just like the IMail external ODBC link is used today by many IMail admins to automate creating users and settings for IMail. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
