Re[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
Reply to: [EMAIL PROTECTED] Re: [Declude.JunkMail] An optional web interface for Declude JunkMail? on Monday 8:34:08 PM Yes this would be valuable. It could be launched into IIS from an actual link in the Imail web templates going to an alternate port, so it would not seem so seemless. The second password system would be good because access to spam filter management would exist as a privilege independently. Sounds very interesting to me, especially if it enabled me to managed captured or HOLD mails remotely. I saw the utility uploaded to this list for this purpose, but I have not tried it and would be curious if any one has? -- Roger Heath [EMAIL PROTECTED] www.rleeheath.com - Copy of Original Message(s): - H> Count me in! H> Mike H> - Original Message - H> From: "R. Scott Perry" <[EMAIL PROTECTED]> H> To: <[EMAIL PROTECTED]> H> Sent: Monday, December 16, 2002 7:49 PM H> 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 H> 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 H> (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. >> >> H> --- H> [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] H> --- H> This E-mail came from the Declude.JunkMail mailing list. To H> unsubscribe, just send an E-mail to [EMAIL PROTECTED], and H> type "unsubscribe Declude.JunkMail". The archives can be found H> at http://www.mail-archive.com. H> -- H> ActivatorMail(tm) ver.122102 Scanned for all viruses by H> www.activatormail.com intelligent anti-virus anti-spam service -- ActivatorMail(tm) ver.122102 Scanned for all viruses by www.activatormail.com intelligent anti-virus anti-spam 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[2]: [Declude.JunkMail] An optional web interface for Declude JunkMail?
> Elegant solution Sandy. > Very nice work. Thanks!Theclient just got interested in some major improvements--well, honestly, one department of insufferables demanded that they be able to turn off our "insulting" alerts to their moronic contacts--so I should be coding a blue streak on this and will repost soon. -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?
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?
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 <>
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: 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[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.
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[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[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?
> 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.
