I like the idea, even though I spent time devloping my own solution (yes, I am going to plug it again), I know it could be better. It was the best solution within my time contraints and programming skills. Scott's approach would have the benefit of smaller footprint and faster perfomance than relying on external services that do a lot more than you need. My biggest goal in developing my own solution was to give customers the chance to choose the level of control, and to allow them to remedy their own false positives by whitelisting (many false positives are user specific, not global).
Here's the plug. Big benefit is it stores mail in a separate POP3 server so you can age the held mail seperately from Imail. (we hold mail indefinately, but limit capacity on Imail, and delete held spam after 7 days) It also has user management of spam settings like the ones Scott is proposing, Declude's solution would mean I would be able to cut it back to only held mail management. http://spamreview.argolink.net/doc for info and download http://spamreview.argolink.net for the app User [EMAIL PROTECTED] Pass demo I'm still wonking on it, I need to add more error trapping, and would like to add things like message sorting, but I think I will await a decision from Declude. Thanks, Chuck Frolick ArgoNet, Inc. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of R. Scott Perry Sent: Tuesday, December 17, 2002 9:47 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] An optional web interface for Declude JunkMail? >I agree that the flat files work well for Junkmail itself. However, a >web GUI will be very hard to do without the 'masters' kept in a database. >Without a database you'll run into file locking problems and it will be >harder to deal with single records. That's why we try stay away from the bleeding edge technology -- there's a reason they use the word "bleeding". It will actually be easier for us to use a flat file than to use a database. > > use IIS (a lot of people don't want to use it, for security reasons). > >This is pretty much a moot point as both IIS and Apache have the same >security risks. IIS just gets more press. <G> We won't use Apache either. > > or any special technologies (such as dot NET, ASP, CF, etc.). We > would need to create something > > that would work on all servers, and not have any special requirements. > >That's going to be hard. Not for us. <G> >You really only have two choices that could cover most of the bases. >ASP or PHP both are available in the Win and Unix worlds. Win32 admins >will prefer ASP. Sorry, I should have included PHP in that list (which is amazingly flexible, BTW). We're not talking about something the typical pre-bubble "We need to show them something to collect our $10 million funding" company would produce. We actually wrote a web scripting language well before ASP was available, and wrote our first web server back when people thought that dynamic content on a web page was a web page that was updated by hand every few hours. If we require ASP or PHP, we're going to require something that a number of our customers either don't have or won't have. Many of our customers would not even think of installing IIS or Apache on a mailserver. -Scott --- [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. --- [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.
