Hi, Something getting lost here in the discussion of the installation GUI is the request from time-to-time for an end-user GUI.
I feel the biggest drawback to our clients (we are hosting company) using our spam blocking is the total lack of any way for them to customize. Believe it or not, even trying to get them to use autowhitelist by putting entries in the WebMail addressbook is over their heads. Many of our clients simply can�t understand how using the WebMail addressbook can help them with their Outlook email and they are already confused between the contact/address list inside Outlook or other client software and the WebMail addressbook. We�re tired of trying to explain to a non-computer expert how to use the [EMAIL PROTECTED] IMail technique to see their spamhold folder. Expecting them all to switch to IMAP is simply not realistic, so for many users, the �middle ground� settings of sending suspected spam to a folder for review is not as viable as it may seem unless they are willing to use WebMail or learn these techniques. Having an easy way for users to change their spam settings � especially managing their own whitelists/blacklists would allow them to turn up the blocking to higher weighting level with less false positives would be very desirable � much more so than a cosmetic GUI for admin installations. PLEASE! I am not talking about unleashing the full internals of declude on end-users. I�m referring to a GUI that allows them to control reasonable things like whitelists and blacklists and perhaps turn on/off groups of tests or toggle some tests. The actual grouping of the tests or the toggles should be defined by each declude admin. Thus, we could abstract everything as we choose and give our users choices like �block non-US mail� or �enable non-US mail�; Set blocking level to �low�, �medium�, or �high�, block �using content rules� block �using dns rules only� or whatever we choose to define. Some folks have built some of this themselves. Although I admire the cleverness in piggybacking ontop of some existing Imail rules, config files, and Webmail menus, I think an end-user GUI should not be slaved to Imail internals/specifics. The goal should be something better than what Postini or Brightmail offer � as a hosted service, we wish we could offer similar easy-to-understand end-user tools for controlling the settings, reviewing the spam folder, etc. ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, July 12, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail Sharyn (and others that despise GUI's and learning new things at this stage in the game), I think that we must all recognize that the majority of Declude's market lies with those that aren't nearly as experienced with this stuff as we are, and they need a GUI in order to tap deeper into that market. Whether we like it or not, a GUI will happen and I'm sure it's a top priority for them. I think that at the same time we should be understanding of the need and the importance of this for their business even though it doesn't suit our needs. Scott already indicated that he planed on having a system where the GUI was just simply an overlay to the config files and not necessarily required. There is no reason why they can't do that if they set out to make that happen. So if they do this right, it will have little or no effect on us. We shouldn't complain about the proposition of a GUI as long as this is the case. IMO, new features like the one that they released would be best addressed in updates to the GUI interface as a separate executable. This GUI interface could enable the new test by way of a check box, and it could be highlighted on a 'What's New' tab/selection. I don't see any reason however for separate 5 MB installers that leave DLL's lying around, especially for these purposes when they should simply be having us register and log into a customer's section of their Web site so that we can get the downloads instead of doing this by way of an app. They certainly shouldn't assume that one-size fits all so far as the way that things are configured as they did this time. IMO, it was a bit premature for this to have been released in this way, the real GUI and the rest of the process should have come first. Matt Sharyn Schmidt wrote: Declude is not a simple thing to implement and configure. Those of us running it are more than capable of adding a line to our config files and deciding how to weight it/configure it/otherwise implement it. We don't NEED a "click OK to install" GUI that does something to our configurations that we're going to have to go change anyway. I have been quietly listening to this thread, before I threw in my 2 cents, but I have to agree here. The "old" system of just letting us manually add a line to our global config file worked great. A GUI is unnecessary and I, personally, do not like random dll's installed on my server that I can't uninstall. Having a pre-set "weight" configured is insane, as it is unlikely that all admins will assign the same weight to each test. My vote goes back to the old way as I prefer to be in control of what gets added to my global.cfg. That way, I have only myself to blame when it's not right :) Sharyn --- [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.
