Decjunkmail, I have a few comments on your post.
> The lack of a web-based GUI is probably the one main feature that > keeps some of your competitors in business. I disagree strongly. I can't say what Scott's competitive research has shown, but the fact that Declude is a third-party add-on to a "horizontally integrated" mail suite must be a much stronger factor than its lack of GUI. Without built-in MTA capabilities, it is of course relegated to downstream filtering and must suffer the consequences of IMail's evolving, but still far from enterprise-class, SMTPD/SMTP architecture. Being an MTA is just one of IMail's features, so we don't judge the product a failure for not being a powerhouse in that area; in fact, it's our firm's most frequent recommendation by far, driven by price, features...and Declude. But you have to call a spade a spade. MS SMTP, and Exchange 2K, are faster MTAs than IMail. PostFix, Sendmail, QMail: no contest. The MTA components of the Norton Gateways are more efficient, again unsurprisingly. Declude is absolutely the most feature-rich product in its class, and IMail the best of the Win32 suites, but without access during SMTP envelope transmission, Scott's heroic trick-turning and encyclopedic knowledge of MIME, SMTP, and DNS still can't get the product out of the catchup mode it inherits from its parent platform. If there's one thing that's the deal-killer you describe, sadly, that's it. I think a built-in GUI would be cool for many of us and advantageous for Scott. However, I think that, as a Declude product, it should exist only within IWEBMSG, which of course requires the (re)opening of the IMail API after a false start this past year. If it exists outside IWEBMSG, I believe it's a concession of defeat for the product to come from Computerized Horizons, and a wasted effort if IWEBMSG becomes programmable relatively soon. On the other hand, the case for *someone* stepping up to write such a helper application is very compelling. > 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. This is already doable within IWEBMSG if you follow my lead from the other week; we're doing this at a couple of clients already. > 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. As above. > 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. Ditto. > 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. Allow me to start the flak on the platform front. :) Many have mentioned on the IMail Forum their opposition to being forced to run IIS, with its history of catastrophic vulnerabilities, and their preference for IMail's customized Apache on those grounds alone. I don't think any full-fledged HTTP/application server platform is necessarily superior, mind you. But special-purpose, proprietary HTTP servers are easier to secure in the first place, less likely to have widely exposed vulnerabilities, and self-definitively easier for vendors to fix on their own. (And just imagine how juicy a target an unsecured IIS server running anti-spam management software would be for an angry spammer!) I agree that CF is an even worse choice than IIS, since it would require CF Express or suchlike to ship with the product. > 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. That's not quite correct. IWEBMSG fully supports host headers, in fact using them for virtual hosting. It does not, naturally, support another HTTP server binding to the same IPs on the same port. Using techniques I have documented on the IMail Forum, it is possible to bind IIS to different IPs from IMail. All you'd be doing by running a Declude GUI on IIS is forcing yourself to use those workarounds, there's nothing simpler about IIS vs. other HTTP servers; if anything, it's a bit *harder* to wrangle IIS into coexisting than is any other HTTPD that I've done it with. > ...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. Ugh. Yes, easier to manipulate, and many, many, many times slower in return. I hope you're not also implying that MSDE run on the same server as IMail/Declude, a certain no-no. > ...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. Not by those who value performance. IMO, a dedicated anti-spam gateway should not be saddled with such overhead if it is otherwise avoidable, let alone anti-spam services running on a mailbox server. I think Scott's use of flat files is to everyone's benefit, and forcing Declude to use SQL would have a strong impact on performance--not to mention that it would force him to reengineer the product itself, which is not part of the Add-a-GUI project as he presented it. Take 'em or leave 'em, per usual. -Sandy --- [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.
