Well, on that topic... I've taken note of your FP reporting procedure and it doesn't mesh well with my environment since I capture to accounts that I only access through Web mail (and so do a lot of people here). Your system requires that users send reports from their registered addresses. Now, being a trial user, I'm not certain about the details since it's not available to me. Even if I was to download messages to my client, I use Netscape Mail, and replies and forwards don't include the header information, and my thought is that this is important for your system to track. I noted a false positive recently in my capture account for an opt-in members dieting newsletter and I forwarded it to the intended recipient to ask if it was in fact wanted/requested, and it was, but even on my forward, Message Sniffer tagged it because of the URL in the body. I think that this exposes a weakness of just simply tagging URL's as a one-to-one match, and maybe that weakness is related to how you gather information from your customers, or rather the limitations of how you gather. Having the headers would allow matching senders to URL's on a lot of spam and avoid many false positives, and simplify tagging of some static spammers by just doing IP's and avoiding the content. Because URL content alone can trigger your system, I must weight it lower than Declude's default settings, but in my environment it is still effective enough to have a noticeable impact, but I expect to see a few more FP's as a result. Declude's WHITELIST AUTH should stop the FP's on intra-server traffic when I upgrade to IMail 8, but there will still be some coming from individuals forwarding banned content from other servers. I'm not a SpamCop member, but someone here referenced a plug-in for Outlook which makes reporting spam to them just a simple press of a button. I would imagine that they can capture the full message that way and not just the body, and because it's simpler to do, they probably get a lot more submissions. That was the basis for that part of my original comments. One thing that I have been exploring on my service is to embed something in the messages, headers or otherwise, which gives a reporting mechanism with some details of the message, though this would be limited to just some header information in this environment. I would need to set it up so that only certain users could access this functionality, and if I could do it HTTP based, I could create a non-published domain which would need to be configured on a local DNS server or in the Windows host file so that resolution would work. I could also If I wanted to, send non-customers to a different version of the site, which would be effective for bounce messages for instance. I suppose that embedding a script by way of a URL might be a way to go, displaying some buttons in the event that DNS resolution works on these specially configured networks and machines. I'm just tossing that out in case it inspires you in any way. The gist of what you were floating originally though seemed to be remote management of Declude, and I just don't know that an app such as Declude, which is so customizable, and changes so frequently, has a realistic opportunity for full admin functionality without Scott providing the framework, and per user settings seem to be best done by way of an interface to IMail's rules and tagging the headers with Declude, which is a kludge with no standardization (though it most definitely works and it overcomes the multiple recipient shortcomings of the environment). Maybe I'm still misunderstanding you though, so if there was some specific feedback that you were after, feel free to ask again :) Thanks, Matt Pete McNeil wrote: If I read you right, you might be interested in a java applet that can be tied into KWM or even built into a web page you develop... perhaps using page based JS to gather message details to feed to the applet... It sounds like a lot of complexity but it's worth looking in that direction. The applet would be able to make specialized HTTP calls back to the same server (security restrictions) - and that server could respond using IIS, CF, or whatever was handy. We do http tunneling like this all the time - so the question then would be, if a toolbox applet like this existed, with a well published API, then what tools should/would it contain? --- [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] OT: ... Pete McNeil
- Re: [Declude.JunkMail] OT: Do y... Matthew Bramble
- Re: [Declude.JunkMail] OT: ... Sheldon Koehler
- Re: [Declude.JunkMail] ... Pete McNeil
- Re: [Declude.JunkM... Matthew Bramble
- Re: [Declude.J... Sheldon Koehler
- Re: [Declude.J... Matthew Bramble
- Re: [Declude.J... Webmaster Oilfield Directory
- RE: [Declude.J... Craig Gittens
- Re: [Declude.JunkMail] OT: ... Pete McNeil
- Re: [Declude.JunkMail] ... Matthew Bramble
- Re: [Declude.JunkMail] OT: Do y... Sheldon Koehler
- Re: [Declude.JunkMail] OT: ... Pete McNeil
- RE: [Declude.JunkMail] OT: Do you use Co... Keith Purtell
- Re: [Declude.JunkMail] OT: Do you use Co... Frederick Samarelli
- RE: [Declude.JunkMail] OT: Do you u... ISPhuset Nordic / Benny Samuelsen
- RE: [Declude.JunkMail] OT: Do y... Matt Robertson
- Re: [Declude.JunkMail] OT: Do you use Co... Webmaster Oilfield Directory