Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Count me in! Mike - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 16, 2002 7:49 PM Subject: [Declude.JunkMail] An optional web interface for Declude JunkMail? A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Guess it depends on the cost ? -- Original Message -- From: R. Scott Perry [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Mon, 16 Dec 2002 19:49:40 -0500 A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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 scanned for viruses by Declude Virus] --- [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.
RE: Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Sandy, I am very interested in your beta code (understanding it's beta). Thank you for your knowledge and contribution. Keith [EMAIL PROTECTED] -Original Message- From: Sanford Whiteman [mailto:[EMAIL PROTECTED]] Sent: Wed 12/18/2002 9:00 PM To: Tom Cc: Subject: Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail? Nobody seems to have acknowledged my message about REDIRECTing to PLAN.IMA for per-user actions, but I am using the method with great success to provide user self-management from *within* IMail Web Messaging. If I, no JavaScript guru, can do it, surely others could go this or similar routes and leave you free for developing Junkmail Ultra. :) I'm curious about this, would you send me a sample? I have, in defiance of the usual prohibitions, sent a screen shot of what I have running *within IMail*, since everyone but Tom seems to think this is a non-issue. I will send my beta code to anyone who's interested. -Sandy winmail.dat
RE: Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
I would like to give it a look as well. We have been working on an interface for quite some time. I would be happy to review your code then see where we can plug in some of what we have built. Thanks for the offer. And just for the disclaimer... I understand that the code is BETA and not guaranteed to do anything. :) rusty [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Sanford Whiteman Sent: Wednesday, December 18, 2002 9:00 PM To: Tom Subject: Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail? Nobody seems to have acknowledged my message about REDIRECTing to PLAN.IMA for per-user actions, but I am using the method with great success to provide user self-management from *within* IMail Web Messaging. If I, no JavaScript guru, can do it, surely others could go this or similar routes and leave you free for developing Junkmail Ultra. :) I'm curious about this, would you send me a sample? I have, in defiance of the usual prohibitions, sent a screen shot of what I have running *within IMail*, since everyone but Tom seems to think this is a non-issue. I will send my beta code to anyone who's interested. -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.
Re: Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Hi, Many people, including me, have asked IpSwitch to do something like this. Also because declude does NOT get called when e-mail in entered using the web interface. I have Declude scanning all mail using an undocumented technique. I will post it, if you promise not to ask Scott directly (seriously). Please pretty please. I have had one virus infetion on our PCs allready because one test was distributed by e-mail to all teachers containing a virus. It took me a while it was not caught by Declude because the e-mail was entered via the web interface and not via a normail mailclient. :-( I am very glad I have insisted in installing a virusscanner on all clients eventhough the mailserver and most other servers are allready protected. Nothing should have come through but.. IpSwitch will simply not include this because it would cost them in their virus version sales. :-( I believe it was actually a simple oversight on their part in IMAIL1 that hurts them as well, and I have faith that they will fix it the next time they work on that module. :) Let's hope so. Simply having Declude scann all mail for virusses, and pretty soon probably for spam as well, is simplicity itself and is pretty much an install and forget issue. Only once in a while do I check the logs and. see that Declude is still doing it's work. :-) Groetjes, Bonno Bloksma Back up my hard drive? How do I put it in reverse? --- [This E-mail scanned for viruses by Declude Virus using f-prot] --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Scott, In response to additional info and questions please see below. When could we anticipate an ETA? Snippet Is this something that others would find useful? It definitely would be easier for us to implement. ***Regarding end user spam control via e-mail subscribe method. This would be a nice option, but I would prefer Web interface for our customers and ability to modify that page with instructions, graphics, support info, etc. I know a lot of pros, cons, opinions here from others, but I am customer driven. How about the option of both methods? Snippet First, if we do this, it would initially be for the per-user settings, with two options: either a Basic configuration that would let people choose between several options (such as No spam control, Conservative spam control, Aggressive spam control), or an Advanced configuration that would let people fine-tune their settings (such as using specific spam tests, and whitelisting/blacklisting). Later, we would probably add a way to access held E-mail, and possibly per-domain and global settings. ***This would be great for us and our customers! Snippet What we would most likely not do is use a database..., use IIS, or any special technologies (such as dot NET, ASP, CF, etc.)... ***This also would be good for us even though we are a CF/SQL shop. We run IIS anyway on our mail servers to redirect older mail clients. -Don S. --- [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. -- Scanned by CompBiz for Viruses http://www.CompBiz.Net. Save 15 Percent on Virus Software by visiting http://www.compbiz.net/software_mcafee.cfm for details! --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
That's already there -- the configuration files are plain text files, and can be accessed with ASP, PHP, proprietary interface, etc. :) I'm not sure if the advantages of an API (not having to deal with the text files directly) would outweigh the disadvantages (less flexibility). -Scott Maybe a simple answer to this problem would be a seperate exe (decutil.exe(?)) that you could call via the command line (or perl/php/etc/etc) to edit the config files. Something that worked along the lines of: decutil.exe [mail_account][action][data], or for example decutil.exe [EMAIL PROTECTED] whitelist [EMAIL PROTECTED] This would: - Allow the ambitious coders to still just manipulate the text files directly. - not fatten/clutter/affect the declude.exe file - give a common interface that would not change as often - so that changes to file structure of the text config files would not require major rewriting of the web/email/whatever end user app. If major changes happened to declude.exe, a new version of decutil.exe follows with it. - allow admins to use any facility they wanted - IIS/PHP/Program Alias/Perl/Whatever they want. If we had at least that, I think there are several of us who could quickly put the rest together. It takes the most time consuming part of the coding - manipulating text files, file locking issues, etc. out of the equation of putting something together. My $0.03 :-), - Tony Gray Intouch Comm. --- [This E-mail was scanned for viruses by http://www.intouchmi.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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Hi, That's already there -- the configuration files are plain text files, and can be accessed with ASP, PHP, proprietary interface, etc. :) I'm not sure if the advantages of an API (not having to deal with the text files directly) would outweigh the disadvantages (less flexibility). -Scott Maybe a simple answer to this problem would be a seperate exe (decutil.exe(?)) that you could call via the command line (or perl/php/etc/etc) to edit the config files. Something that worked along the lines of: decutil.exe [mail_account][action][data], or for example decutil.exe [EMAIL PROTECTED] whitelist [EMAIL PROTECTED] Although *we* would probably not get the added option for manipulating the spam control, this would let us integrated it in our system quite easily. We are a school (post highschool and bachelors university) and have all our student info in a MS SQL database. However we decided to use the IMail database for all the e-mail box info so we use the commandline tool to create / change / delete new e-mail boxes. A similar tool would let us manipulate the spam controll. However, as a school I would simply enforce the spam control and too bad some legitimate mail gets caught. I will have a look at those mails once or twice a week and forward them if they seem legit. For THAT I would like a simple to use tool, either a small web interface or a gui tool to quickly look at those mails and hit a forward or a delete key. Groetjes, Bonno Bloksma Back up my hard drive? How do I put it in reverse? --- [This E-mail scanned for viruses by Declude Virus using f-prot] --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
However, as a school I would simply enforce the spam control and too bad some legitimate mail gets caught. I will have a look at those mails once or twice a week and forward them if they seem legit. For THAT I would like a simple to use tool, either a small web interface or a gui tool to quickly look at those mails and hit a forward or a delete key. THAT tool already exists: http://www.slsoft.com/spamreview.htm - Tony --- [This E-mail was scanned for viruses by http://www.intouchmi.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.
Re[4]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
I have Declude scanning all mail using an undocumented technique. I will post it, if you promise not to ask Scott directly (seriously). Please pretty please. The reason Declude cannot scan mail sent from IWEBMSG is that IWEBMSG uses IMAIL1 to encode messages, and IMAIL1 is hard-coded to transfer control to SMTP32.EXE, rather than reading the SendName key from the Registry. So, if IMAIL1 is going to use whatever's called SMTP32.EXE, you need a workaround: - First, make a backup of the Ipswitch SMTP32.EXE in a safe place. - Then, rename Ipswitch's SMTP32.EXE to IPSMTP32.EXE. - Next, make a copy of DECLUDE.EXE and call it SMTP32.EXE. - Finally, in your .CFG, add the undocumented DAISYCHAIN directive: DAISYCHAIN IPSMTP32.EXE (DAISYCHAIN tells Declude to transfer control to a delivery engine with a non-default name.) That's it. It has the added strong benefit of letting IWEBMSG benefit from Declude Queue. NOTE: I'm serious about not expecting Scott's feedback on this; DAISYCHAIN has been closely guarded, since it makes Declude look like much more of a kludge than we all know it to be, and I don't expect him to stand up for it beyond his very gracious parsing of the keyword. In the future, I'm sure Ipswitch will fix IMAIL1, and this will all go away. -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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
The program alias could be used effectively if it were a web generated email message. It could be hosted on another machine/os/programming language etc if it were all handled as a program alias. Create a couple of examples and Administrators could modify to their hearts content. David Could we take a lower tech route and use the program alias capabilities? Make changing your spam settings similar to subscribing/unsubscribing from a That's what we were originally thinking of a few years back, but the problem is that end users are well... end users. --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Not really. It could use Declude Confirm. Fill out a page add your email address. The web page mails a confirmation (make sure this is what you want) and mail it back to start the process. No login required. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of R. Scott Perry Sent: Wednesday, December 18, 2002 8:13 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] An optional web interface for Declude JunkMail? How are subscribers going to log into a web interface? Won't they need a password of some type to verify they are who they say they are? Will they need another password or will they be able to use their IMail password and Declude would tap into the IMail database to verify the password? They would need to log in, but with the same username/password as they already use with IMail. -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.
Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Nobody seems to have acknowledged my message about REDIRECTing to PLAN.IMA for per-user actions, but I am using the method with great success to provide user self-management from *within* IMail Web Messaging. If I, no JavaScript guru, can do it, surely others could go this or similar routes and leave you free for developing Junkmail Ultra. :) I'm curious about this, would you send me a sample? I have, in defiance of the usual prohibitions, sent a screen shot of what I have running *within IMail*, since everyone but Tom seems to think this is a non-issue. I will send my beta code to anyone who's interested. -Sandy spamanager.zip Description: Zip compressed data
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
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
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
A definite yes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of R. Scott Perry Sent: 17 December 2002 00:50 To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] An optional web interface for Declude JunkMail? A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Double yes and Christmas wish ! -- Original Message -- From: David Lewis-Waller [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 17 Dec 2002 09:54:58 - A definite yes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of R. Scott Perry Sent: 17 December 2002 00:50 To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] An optional web interface for Declude JunkMail? A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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. --- [This E-mail scanned for viruses by Declude Virus] --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
I'll be willing to publish mine (with source) but I'm not going to offer an installer. :) Here's how mine works.. All filter files and blacklists are kept in SQL tables. Actions (bounce, alert, etc) and Locations (mailfrom, subject, body) are also kept in SQL tables. The logic is pretty simple on this part. There's just an ASP front end but the catch is that it's dependant on ASPGrid by Persits Software so you'll need to purchase that COM Object to get this to work out of the box: http://www.aspgrid.com There's just more code involved to do the same thing in regular ASP but it's not that hard. The second part is a VB6 Application that simply extracts the tables, reformats, and writes them into the \declude directory. I chose to make this an actual application that has hooks back into IIS (using STDOUT) rather than an ASP or COM .dll because I wanted to be able to run it from a command line as well as the web interface. All you do is click on the publish link and IIS runs the .exe and the tables are written. Since there is currently no external whitelist, I've used a filter file that sets the weight to -100. If you know VB and ASP then it will be pretty easy to customize. You'll need: ADO 2.7 (MDAC 2.7) http://www.microsoft.com/data/ VB6 Runtime files ASPGrid http://www.aspgrid.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Avolve Support Sent: Tuesday, December 17, 2002 8:30 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] An optional web interface for Declude JunkMail? Double yes and Christmas wish ! -- Original Message -- From: David Lewis-Waller [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 17 Dec 2002 09:54:58 - A definite yes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of R. Scott Perry Sent: 17 December 2002 00:50 To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] An optional web interface for Declude JunkMail? A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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. --- [This E-mail scanned for viruses by Declude Virus] --- [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 scanned for viruses by F-Proto Virus Scanner] --- [This E-mail scanned for viruses by F-Proto Virus Scanner] --- [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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Monday, December 16, 2002 you wrote: A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. Yes, I thought about it again this morning as I was scrolling through 476 trapped messages from overnight. Actually it takes seconds but always irritates me, especially when I have a cold. Is this something that is important enough that it would be worthwhile? I've invested a good deal of time and effort in this already considering whether I might implement a user or domain based system and I'll share a bit that I've learned. In our case the application need not be tied to web messaging as we have very few web messaging users. Mostly it would be a domain administrator issue for us. Generally they would be more at home using an interface integrated into other applications we've written for them than in the IMAIL web messaging interface. In thinking how I'd implement a system I decided that first I'd sort the existing hold directory messages by domain. This seemed rather easy to do but was complicated by the domain alias issue. It was further complicated because we do trap certain outgoing messages so there has to be a distinction. We already had methods to delete and re-spool. However, I did change delete so that it really only compresses and archives and the archive is cleaned periodically. One interesting fact that emerged from this was that only a few domains account for the bulk of our spam. So we think that the most reasonable course is likely to force the high spam domains to self-management and leave the others under our central management. We devised the Sql2000 system for managing all rules and combined every filter into one sql rule table. This alone has helped us immensely. The next obvious step in that regard is to add a flag for rules that determines global or domain use so that the domain admin can work with his own set. I think this is pretty easily managed and well within the scope of our domain admins competence. So I think that a working system for the domain is really not that difficult. However, I am concerned about the actual use of the system by the domain admin. We have a lot of trouble getting them to clean up mailboxes now so I think we'll have to add some sort of system for auto cleaning their respective held message folders. I am more pessimistic about moving to the individual user level. I think the benefit is not really worth the effort on that level. I don't think we'd purchase the system in any event. Terry Fritts --- [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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
I'm with Joe with this. Being a local ISP, it's great to offer spam blocking to our customers, and even tho Declude can be set to per user settings for us, I'm not sure I want to go that route yet. Half can't make a simple dialer work right, I cringe to think what damage they would do with a Declude web interface =) I can't get any mail, I didn't DO anything! Honest! Paul - Original Message - From: J Porter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 16, 2002 9:46 PM Subject: Re: [Declude.JunkMail] An optional web interface for Declude JunkMail? Admittedly, we're a small ISP and may not be representative of the entire group, but I'm not convinced we would even use such a product. Every so often I feel as though I'm a censor and I get an uneasy feeling. If we allow individuals to control their own destiny with antispam parameters, wouldn't we also have to allow them to control the kill.lst and domain processing rules?? I'm often tempted to delete the kill.lst, erase the domain processing rules, stop Declude and just let the floodgates wide open. Then our customers might realize the impact of what we do for them. (We can approx 1/3 of our 24,000 incoming emails each day). I'm not sure I'm ready for such a product and I certainly don't think our clients are. ~Joe~ --- [This E-mail scanned for viruses by Declude Virus] --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
As far as users, I am against it. Like others have said, allowing a user to make configuration changes will be an invitation to a migraine headache. What I do like is how some have the idea of allowing a user to make a choice of 3-5 options: No blocking, minimum blocking, aggressive blocking, and block all except on white list. However, that is not done through a configuration GUI, but choosing one of a couple of pre configured options. Personally, I think an admin GUI should be left to a 3rd party, as some are already in some stage of development. I did like some ones post that maybe those that have developed on in process of developing an admin GUI can get together and collaborate. However, the logistics of that can be its downfall. John Tolmachoff MCSE, CSSA IT Manager, Network Engineer RelianceSoft, Inc. Fullerton, CA 92835 www.reliancesoft.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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
The users are asking me to make these decisions as they don't want a lot of the crap coming in. I will do the best I can but I also feel they need to be responsible and quit going places and signing up for all this stuff and then expect us bail them out when they get overloaded with it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Tolmachoff Sent: Tuesday, December 17, 2002 10:03 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] An optional web interface for Declude JunkMail? As far as users, I am against it. Like others have said, allowing a user to make configuration changes will be an invitation to a migraine headache. What I do like is how some have the idea of allowing a user to make a choice of 3-5 options: No blocking, minimum blocking, aggressive blocking, and block all except on white list. However, that is not done through a configuration GUI, but choosing one of a couple of pre configured options. Personally, I think an admin GUI should be left to a 3rd party, as some are already in some stage of development. I did like some ones post that maybe those that have developed on in process of developing an admin GUI can get together and collaborate. However, the logistics of that can be its downfall. John Tolmachoff MCSE, CSSA IT Manager, Network Engineer RelianceSoft, Inc. Fullerton, CA 92835 www.reliancesoft.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. --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
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. ODBC for text files? :) 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 Interesting. Another thought... Is there any hook into the iMail web interface/server? If so, could it run your scripting engine? --- [This E-mail scanned for viruses by F-Proto Virus Scanner] --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
FWIW, we've offered a free value add optional email service. When we create the email account for the user we use [EMAIL PROTECTED] we also create a [EMAIL PROTECTED] alias for the first_last where XX is a number. We instruct users to use the first_last email address for user to user communication only. IOW, only tell people (not online sites, stores, etc) this address. For online accounts/stores/etc we tell them to use the alias. When their spam gets really bad they just kill the alias account and we increment the XX number. They go back into their Amazon accounts, etc and change their alias email address. We used this before Junkmail and it seemed to work well. This, with Junkmail works even better. Of course it only works with the users who understand which email address to use where. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Tolmachoff Sent: Tuesday, December 17, 2002 10:27 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] An optional web interface for Declude JunkMail? The users are asking me to make these decisions as they don't want a lot of the crap coming in. If you have to provide hands on service for users, make sure you charge for such. I will do the best I can but I also feel they need to be responsible and quit going places and signing up for all this stuff and then expect us bail them out when they get overloaded with it. Amen. (You forgot to mention to quit asking to be removed from lists, which only adds them to more lists.) John Tolmachoff MCSE, CSSA IT Manager, Network Engineer RelianceSoft, Inc. Fullerton, CA 92835 www.reliancesoft.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. --- [This E-mail scanned for viruses by F-Proto Virus Scanner] --- [This E-mail scanned for viruses by F-Proto Virus Scanner] --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
I don't mean to cross you and it is a question out of it's time seeing as you haven't made any decisions yet but what about functionality and extensibility of your proprietary platform? Are we in for another IWEBMSG and are you going to hire a whole new team to support coding features/upgrades for this? I see this as being your expense where you would have almost none using existing free technologies such as IIS. Remember that you are dealing with Win32 admins here and yes you can't please all the people all the time but you can sure come close by injecting your new project into our Win32 subset of experience. What you could do is just forward to the list the new found bugs and patches for IIS from Microsoft and other 3rd party security companies for those who don't keep up-to-date. *guilty* Craig. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of R. Scott Perry Sent: Tuesday, December 17, 2002 11: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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
My preference would be for IIS/ASP. PHP adds another installed application into the equation on a box that really should only be running IMail. However, I would trust a webserver app from Declude that would do the job - it would be less prone to vulnerabilities than IIS/Apache/CF etc. as the internal workings wouldn't be known outside of Scott's team - i.e. not common and not open source. My 2p's worth. David WiSS LImited -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Craig Gittens Sent: 17 December 2002 16:10 To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] An optional web interface for Declude JunkMail? I don't mean to cross you and it is a question out of it's time seeing as you haven't made any decisions yet but what about functionality and extensibility of your proprietary platform? Are we in for another IWEBMSG and are you going to hire a whole new team to support coding features/upgrades for this? I see this as being your expense where you would have almost none using existing free technologies such as IIS. Remember that you are dealing with Win32 admins here and yes you can't please all the people all the time but you can sure come close by injecting your new project into our Win32 subset of experience. What you could do is just forward to the list the new found bugs and patches for IIS from Microsoft and other 3rd party security companies for those who don't keep up-to-date. *guilty* Craig. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of R. Scott Perry Sent: Tuesday, December 17, 2002 11: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. --- [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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Tuesday, December 17, 2002 you wrote: P What we would most likely not do is use a database (the flat files P seem to work very well, and are very efficient), use IIS (a lot of P people don't want to use it, for security reasons), or any special P technologies (such as dot NET, ASP, CF, etc.). We would need to P create something that would work on all servers, and not have any P special requirements. I think that's all very reasonable for what it's worth. There is such wide divergence in the IMAIL community. I'm using perl CGI myself with DBI. Terry Fritts --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Say the word and I'm sure that we'll be more than happy to start campaigning Ipswitch to do it! :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of R. Scott Perry Sent: Tuesday, December 17, 2002 11:06 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] An optional web interface for Declude JunkMail? Is there any hook into the iMail web interface/server? No. With about 10-20 lines of code, IMail could do it, but they don't seem to think there is a need. :( If they had, we likely would have had a web interface within a week or so after they added the interface (yes, it would be very easy if they had a web interface). -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 scanned for viruses by F-Proto Virus Scanner] --- [This E-mail scanned for viruses by F-Proto Virus Scanner] --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Could we take a lower tech route and use the program alias capabilities? Make changing your spam settings similar to subscribing/unsubscribing from a mailing list. I picture something along the lines of sending a change request to [EMAIL PROTECTED] I get back a form where I can change the settings and reply. It's not nearly as slick as a web interface, but it would work for everyone (except maybe Imail gateway users) and not require adding any web server apps to the mail server. -Bill Naber Kitchin Hospitality, LLC --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
The Declude users lobby group!!! Count me in. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Smith Sent: 17 December 2002 16:56 To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] An optional web interface for Declude JunkMail? Say the word and I'm sure that we'll be more than happy to start campaigning Ipswitch to do it! :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of R. Scott Perry Sent: Tuesday, December 17, 2002 11:06 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] An optional web interface for Declude JunkMail? Is there any hook into the iMail web interface/server? No. With about 10-20 lines of code, IMail could do it, but they don't seem to think there is a need. :( If they had, we likely would have had a web interface within a week or so after they added the interface (yes, it would be very easy if they had a web interface). -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 scanned for viruses by F-Proto Virus Scanner] --- [This E-mail scanned for viruses by F-Proto Virus Scanner] --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail ?
And on the gripping hand... LOL, Niven rocks! --- [This E-mail scanned for viruses by Declude Virus] --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail ?
One problem I see (Sandy and others, please jump in) is that whitelisting is easy to mess up, and a crack that the law of unintended consequences will exploit. Two examples: the example in Scott's manual that says whitelisting mail.com is probably a bad idea, and whitelisting postmaster@[yourdomainhere.tld] gives a free ride to any spam that sends to postmaster while cc'ing everybody else at your domain. I agree. The battle goes on. John Tolmachoff MCSE, CSSA IT Manager, Network Engineer RelianceSoft, Inc. Fullerton, CA 92835 www.reliancesoft.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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
On reflection ... you're probably right that it would just shift the support burden from making configuration changes to explaining how to make configuration changes. And, I think the later would actually be more work. John Tolmachoff MCSE, CSSA IT Manager, Network Engineer RelianceSoft, Inc. Fullerton, CA 92835 www.reliancesoft.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.
Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Mark, 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. ODBC for text files? :) I fear you've been in the MS world too long. When ODBC is used without good reason (i.e. the real functional demand for SQL language support), it adds crippling overhead with no appreciable return. Skilled programmers can get a lot more done in less time with low-overhead databases, both proprietary and open (VB/ISAM, CodeBase), and with text files. IMail itself uses text files, and has to tolerate *many* more concurrency issues than the rarely-modified Junkmail files! Unless you can show that Declude needs an RDBMS on the back end, you're choosing comfort over performance, and I think that's the wrong priority for a mailserver. Interesting. Another thought... Is there any hook into the iMail web interface/server? If so, could it run your scripting engine? Of course not. This has been discussed at length on the IMail forum. Say the word and I'm sure that we'll be more than happy to start campaigning Ipswitch to do it! :) Uh...yeah. They always jump at the chance to implement functionality that benefits a third party. :)) -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.
Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Chuck, Ok, I just have to say it. As Declude evolves, I think their dependance on Imail needs to lessen (another good reason for Declude provided HTTP service). See my earlier post for some thoughts on this. -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.
RE: Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Mark, 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. ODBC for text files? :) I fear you've been in the MS world too long. When ODBC is used without good reason (i.e. the real functional demand for SQL language support), it adds crippling overhead with no appreciable return. Skilled programmers can get a lot more done in less time with low-overhead databases, both proprietary and open (VB/ISAM, CodeBase), and with text files. IMail itself uses text files, and has to tolerate *many* more concurrency issues than the rarely-modified Junkmail files! Unless you can show that Declude needs an RDBMS on the back end, you're choosing comfort over performance, and I think that's the wrong priority for a mailserver. This is true. It's been many days since C++ on the VMS system. :) Then again, my requirements for this web interface are drastically different from the others. VB and SQL is extremely easy to crank out my solution. I simply wanted an easy interface for admins and not for my end users. That seems to be a different requirement than the ISP admins need. :) --- [This E-mail scanned for viruses by F-Proto Virus Scanner] --- [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.
Re: DSN:RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
E-mail is sent to entered e-mail address for conformation Well, I guess we know what you're doing with the bounces. :) -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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Hi, Say the word and I'm sure that we'll be more than happy to start campaigning Ipswitch to do it! :) Many people, including me, have asked IpSwitch to do something like this. Also because declude does NOT get called when e-mail in entered using the web interface. IpSwitch will simply not include this because it would cost them in their virus version sales. :-( So unless we actually pay for those 20 lines I don't think we'll get it unless.. everybody refuses to upgrade untill they DO put those few lines in. That's my policy so far. There is no sense for me in upgrading until they ad features I WANT and not features IpSwitch thinks I need. Groetjes, Bonno Bloksma Back up my hard drive? How do I put it in reverse? -Original Message- Is there any hook into the iMail web interface/server? No. With about 10-20 lines of code, IMail could do it, but they don't seem to think there is a need. :( If they had, we likely would have had a web interface within a week or so after they added the interface (yes, it would be very easy if they had a web interface). -Scott --- [This E-mail scanned for viruses by Declude Virus using f-prot] --- [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.
Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Many people, including me, have asked IpSwitch to do something like this. Also because declude does NOT get called when e-mail in entered using the web interface. I have Declude scanning all mail using an undocumented technique. I will post it, if you promise not to ask Scott directly (seriously). IpSwitch will simply not include this because it would cost them in their virus version sales. :-( I believe it was actually a simple oversight on their part in IMAIL1 that hurts them as well, and I have faith that they will fix it the next time they work on that module. :) -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.
[Declude.JunkMail] An optional web interface for Declude JunkMail?
A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
If I could give users granular control over their own spam settings, that would get me off the hook for doing it for them. What you're describing, though, sounds almighty complex. On the surface (admittedly :D) It would be fairly straightforward to write in ColdFusion, if all we're talking about is modifying a user's config file. Maybe a reduced feature set and price (a Lite) that just deals with basic per user or per domain settings? Always wanted to do this but never had the time to spare. How much $$$ are we talking about? That'd be the kicker. --- Matt Robertson, MSB Designs, Inc. http://mysecretbase.com - Retail http://foohbar.org - ColdFusion Tools --- -- Original Message -- From: R. Scott Perry [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Mon, 16 Dec 2002 19:49:40 -0500 A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Scott, I think that this would be a great addon to JunkMail. A very small percentage of our user even use web messaging (possibly because they don't know it's available--we don't currently advertise it), so it would not be a burden to most of our customers. Also, once you bookmark the link, it should not be a big deal to reconnect to the spam administration site. I vote yes! Bill -Original Message- From: R. Scott Perry [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 4:50 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] An optional web interface for Declude JunkMail? A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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 Pointshare's Virus Scanning Service] --- [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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Is this something that is important enough that it would be worthwhile? I don't think it's worth the effort technically, though it may well be so in a financial sense. Nobody seems to have acknowledged my message about REDIRECTing to PLAN.IMA for per-user actions, but I am using the method with great success to provide user self-management from *within* IMail Web Messaging. If I, no JavaScript guru, can do it, surely others could go this or similar routes and leave you free for developing Junkmail Ultra. :) -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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Several contributors to this list have talked about or have shown preliminary tools. We started working on something as well a few wekks ago as well. It might be worthwhile to pool the work already begun or take something that has a promissing start. David Is this something that is important enough that it would be worthwhile? --- [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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Admittedly, we're a small ISP and may not be representative of the entire group, but I'm not convinced we would even use such a product. Every so often I feel as though I'm a censor and I get an uneasy feeling. If we allow individuals to control their own destiny with antispam parameters, wouldn't we also have to allow them to control the kill.lst and domain processing rules?? I'm often tempted to delete the kill.lst, erase the domain processing rules, stop Declude and just let the floodgates wide open. Then our customers might realize the impact of what we do for them. (We can approx 1/3 of our 24,000 incoming emails each day). I'm not sure I'm ready for such a product and I certainly don't think our clients are. ~Joe~ - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 16, 2002 6:49 PM Subject: [Declude.JunkMail] An optional web interface for Declude JunkMail? A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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 scanned for viruses at HNB.com] --- [This E-mail scanned for viruses at HNB.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.
Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Admittedly, we're a small ISP and may not be representative of the entire group, but I'm not convinced we would even use such a product. Okay, makes sense. Many admins would quite sensibly not want to surrender control, and server resources, to a chaotic--not to say ignorant--user base. And yet... Every so often I feel as though I'm a censor and I get an uneasy feeling. ...this appears to be a very Pro sentiment regarding user-level control! Let me try to figure you out. :)) If we allow individuals to control their own destiny with antispam parameters, wouldn't we also have to allow them to control the kill.lst and domain processing rules?? I don't think so. The reason one moves to per-user rules is because some users can't help getting involved with people who send through compromised, blacklisted, mismanaged servers, et al. It's not that any users want *unsolicited* mail, in my experience; some are just willing to accept more of it in order to get more of their frustratingly shady, yet admittedly consensual, correspondence. (I'm leaving out those who are unable to find l o n e l y h o u s e w i f e webcams on their own and truly need spammers to feed them their leads.) If you think your KILL.LST is killing false positives, you've got a problem; I believe the KILL.LST should be for sure things only, as it's not weightable. Likewise for domain-level rules: though you haven't given examples of what you're doing in IMail as opposed to in Declude, I don't see the syllogism that leads to opening everything up. I'm often tempted to delete the kill.lst, erase the domain processing rules, stop Declude and just let the floodgates wide open. Then our customers might realize the impact of what we do for them. This sounds like a very dangerous concept: it'll surely instill confidence for many and get you their thumbs-up, yet it's bound to create fear in others and a sudden demand for user-level controls. I'm not getting your overall thrust (though it's perfectly reasonable to be ambivalent!). If you fear that you're a censor, which could apply if your EULA does not sufficiently detail what people are paying for, you need to either change your published policies or change your real actions. If you simply want to come clean about some strict measures you're taking that aren't sufficiently explained, then create a revised document with minor changes and send a unruffling, innocent message to your users with a link to the URL. If you really feel guilty and want to start offering those features to some, but not without user permission, well, it's time to get on the per-user bandwagon. And if you want to stop taking those measures outright, just do--and don't bother telling anyone, IMO. I'm not sure I'm ready for such a product and I certainly don't think our clients are. Sounds like you're definitely unsure. There's a bunch of uncertainty in your writing! -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.
Re: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Scott, I've spent thousands of hours (as many of us have) perfecting a universally applicable configuration (as diverse as my client base allows). On the server side, when there's a flaw in the system revealed by an FP, changing the entire system means all other clients benefit from the change. Creating an individual exception (like a whiltelist entry) is a last resort used only when fixing the system would weaken it to much. If users are making their own changes and not reporting problems, no one else is benefiting. On the client side, every time users get ahold of anti spam systems, they invariably over use them, marking as spam even a newsletter they no longer want. A user customizable system then, would need to be more focused than domain specific, it would need to be user specific. In my store forward configuration, that would mean tracking which aliases belong to which user, lest they make a change on account A1 and not have it affect A2. My itself, this one issue may take more time than this solutions aims to solve. Whatever you do, don't make an admin GUI for Declude. Nothing ruins an infinitely customizable (and useful) program faster than a limiting interface. Others may be facing a gauntlet of user requests that this would remedy, but IMHO, technical improvements that give more tools to stop spam are more useful and should have greater priority. Dan On Monday, December 16, 2002 16:49, R. Scott Perry [EMAIL PROTECTED] wrote: A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Scott, I vote yes. Our users would love it! If you or another does not create it - we would eventually work on something for our customers based on repeat requests. It's either I pay my guys, another, or you. Several months ago another Decluder here shared files they developed of end user filter tools working with Declude. It was simple for the end user and well thought out. If I remember correctly there were limits or you had to go the long way around because of some JM per user/per domain issues. I was going to try and work on it some more and use, and then share back, but other more pressing dev came up for us and not had a chance to revisit. I will look through my files and try and get you a name. He is a user here and it fitted the bill nicely. Hopefully he will see my post and reply. It was basically select your Spam settings High / Low (predefined filters) or configure yourself from a list. What would you write it in? Keep us informed of your plans. Sounds great and I really like the idea of it being developed by your team to work directly with Declude JM! Even something very simple to turn on/off certain filters or groups of filters (i.e. high/low) to start would be nice. I would want to be able to define a default when setting up new accounts. -Don S. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of R. Scott Perry Sent: Monday, December 16, 2002 7:50 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] An optional web interface for Declude JunkMail? A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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. -- Scanned by CompBiz for Viruses http://www.CompBiz.Net. Save 15 Percent on Virus Software by visiting http://www.compbiz.net/software_mcafee.cfm for details! --- [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.
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
I agree with what you are saying and especially no need for GUI for Declude administrator. Not sure I read Scott's original post correctly? I was thinking he meant end user on/off/select/remove filters tool. Filters set-up, defined, and made available for selection by the Declude administrator. Simple non-admin level type on/off Spam control tools to end users (simplicity similar to Hotmail and Yahoo) would be well received by my customers anyway. It would actually help me feel better to put the on/off part in the end users hands in response to the previous poster (Joe) who described being uneasy filtering Spam. -Don S. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dan Patnode Sent: Tuesday, December 17, 2002 12:05 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] An optional web interface for Declude JunkMail? Scott, I've spent thousands of hours (as many of us have) perfecting a universally applicable configuration (as diverse as my client base allows). On the server side, when there's a flaw in the system revealed by an FP, changing the entire system means all other clients benefit from the change. Creating an individual exception (like a whiltelist entry) is a last resort used only when fixing the system would weaken it to much. If users are making their own changes and not reporting problems, no one else is benefiting. On the client side, every time users get ahold of anti spam systems, they invariably over use them, marking as spam even a newsletter they no longer want. A user customizable system then, would need to be more focused than domain specific, it would need to be user specific. In my store forward configuration, that would mean tracking which aliases belong to which user, lest they make a change on account A1 and not have it affect A2. My itself, this one issue may take more time than this solutions aims to solve. Whatever you do, don't make an admin GUI for Declude. Nothing ruins an infinitely customizable (and useful) program faster than a limiting interface. Others may be facing a gauntlet of user requests that this would remedy, but IMHO, technical improvements that give more tools to stop spam are more useful and should have greater priority. Dan On Monday, December 16, 2002 16:49, R. Scott Perry [EMAIL PROTECTED] wrote: A lot of our customers seem to want a web interface to Declude JunkMail, mostly so that customers can turn their spam settings on or off. We haven't come up with something in the past, because it is very complicated without a hook into web messaging, and it doesn't look like Ipswitch is planning to add an interface to web messaging any time soon. However, we are at the point where we are considering a web interface. If we do it, it would probably need to be done as an addon to Declude JunkMail, mainly because the development and support costs would be fairly high. It would also have some drawbacks, being separate from web messaging. For example, it would require installing a separate service, using a different port than 80 or 8383 for web access (which may cause firewall problems), and having users enter their username/password a second time (if they are already using web messaging). Is this something that is important enough that it would be worthwhile? -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. -- Scanned by CompBiz for Viruses http://www.CompBiz.Net. Save 15 Percent on Virus Software by visiting http://www.compbiz.net/software_mcafee.cfm for details! --- [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.
[Declude.JunkMail] An optional web interface for Declude JunkMail?
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
RE: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Nobody seems to have acknowledged my message about REDIRECTing to PLAN.IMA for per-user actions, but I am using the method with great success to provide user self-management from *within* IMail Web Messaging. If I, no JavaScript guru, can do it, surely others could go this or similar routes and leave you free for developing Junkmail Ultra. :) I'm curious about this, would you send me a sample? Regards, Tom Image`fx --- [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.
