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 is getting far, far off topic unless it quickly leads to a list of Declude centric adjustments that might be supported in the applet provided UI... sorry for the ot - Please feel free to contact me off list if it heads further ot.)

_M

At 06:08 PM 11/6/2003, you wrote:
I'm not sure that I totally followed you, however I think I know where you are going with that.  FP reporting is important to your product, and anything that could make the process easier would benefit all of your users, even if some didn't use it.

Speaking for myself and from my perception of what I have seen, I think my approach to management of such things, while not totally out of the ordinary, is unique, and I have the same perception of most here.  While I have Web-mail (KWM), I don't use it except for spam reviewing, and my users hardly use it at all.  Over time I expect to be doing a lot more gateway spam blocking, in which case a setup for managing such domains would need to be quite different since they aren't locally hosted, but locally managed.  The real usefulness might be in single domain installations.

Maybe I'm not following what you are getting at though.  It might be real nice though to come up with a plug-in for reporting spam and false positives in the mail client, or at least the Web-mail client.  If I chose to report spam from a Web mail client for instance, it will munge the HTML stuff and you could lose some important data for processing.  Having the original header information would also be quite useful for a dual match with the body URL for your filtering (this has given me some issues in my trial and forces me to score low in the event of forwarded content from legit users).  Don't get me wrong though, by in large, I'm very impressed with your architecture after three days of trialing your product.

Matt



Pete McNeil wrote:
OT - sort of.
 
We do most of our heavy web work in Java/JSP. We've tossed around the idea of building a Java app that would accept HTTP connections (perhaps on an alternate port) and provide an interface to Declude & other spam management tools for users & admins.
 
Our development schedule is _very_ full, but if there is a significant interest in this I could explore shifting some effort in that direction.
 
As a dedicated Java app it would be cross-platform compatible (in theory), relatively secure, lightweight, and could be configured to run along side any web services that might be present (such as KWM). In an IMail environment we could even present a postini-like interface for users to "release" their held spam - and generate accurate false positive reporting in the process, etc... (these are the ideas we have anyway...)
 
Thoughts?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: Thursday, November 06, 2003 4:46 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] OT: Do you use ColdFusion?

I've got one, but don't really use it.  I much prefer ASP, if just for the integration and stability.

Matt



Jason (by way of R. Scott Perry ) wrote:
I was just wondering how many people here have a ColdFusion server at their disposal.

Jason Wolfe
Lead Developer
Netcomm, Inc.
http://www.netcomm.com
(859) 224-4124

--- [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.

Reply via email to