Re: [sniffer]Re[2]: [sniffer]FP suggestions

[Matt]

Pete, An X-Header would be very, very nice to have.  I understand the issues related to waiting to see if something comes through, and because of that, I would maybe suggest moving on your own. Sniffer doesn't need to be run on every single message in a Declude system.  Through weight based skipping, many administrators (especially the ones that could make the most use of this) could skip processing Sniffer once a certain weight is reached, and in turn that would save enough load that it should easily make up for needing to re-write the message to the disk with the modified headers.  On external tests that allow for weight skipping on my system, I was skipping around 50% of messages before lightening the load with pre-scanning. Sniffer could do weight skipping with Declude by accepting the %WEIGHT% variable in the command line. SNIFFER-IP        external    063    "C:\IMail\Declude\Sniffer\customer-code.exe license-code WH=26 WL=-5 CW=%WEIGHT%"    5    0 ...etc. The WH setting says don't run if equal to or greater than, the WL says don't run if equal to or less than, and the CW passes in the weight from Declude at the time of calling Sniffer.  It still launches Sniffer, but it could be stopped immediately before any heavy lifting is done. The best solution of course would be for Declude to allow for weight-based skipping in the config without calling the executable, but I started asking about that back in the Scott days and I am not holding out hope for that happening soon considering.  The most realistic option would seem to then have Sniffer do the heavy lifting of rewriting itself, and save some CPU and disk I/O by improving efficiencies with something as simple as weight-based skipping.  I'm pretty sure the net result would be less CPU and disk I/O overall if both were done. Another alternative may be to create a separate executable (with weight-based skipping) that would only deal with adding headers from the text file that Sniffer drops in the directory.  There would be less benefit overall to keeping this all in one app, but it would target the primary need.  This could easily be written by one of us in _vbscript_ as a proof of concept.  I have considered doing this before, but it isn't at the top of my priorities. BTW, you could maybe even encode links in the headers for FP reporting through a Web interface, completely removing the forwarding mechanism from the mix, though you wouldn't have the opportunity to see the messages which may not be good as a whole. Matt Pete McNeil wrote: Hello Scott, Wednesday, June 7, 2006, 10:08:58 AM, you wrote: For me the pain of false positives submissions is the research that happens when I get a "no rule found" return.   I then need to find the queue-id of the original message and then find the appropriate Sniffer log and pull out the log lines from there and then submit it. Almost always in these cases, a rule is removed.   If this process could be improved that would really be a time saver. This depends on the email system you are using. On some systems (MDaemon, and postfix, for example) X- headers from SNF can be emitted into the message. When we see these we can identify the rules directly without asking for the extra research. It would be nice if Declude would offer a mechanism to pick up the optional .xhdr file SNF can generate and include it in the X headers that it already adds to the message. I know this begs the question, why not have SNF add the headers for SmarterMail and IMail platforms, and the reason is that it would require writing an additional copy of the message to disk. Since these systems tend to be io bound already (Declude/IMail anyhow) the performance penalty would be prohibitive. If Declude picks up .xhdr from SNF directly then it can be included in the ONE rewrite Declude makes anyway. I've asked them about this and other improved integration opportunities for a while now (many months), and I get favorable responses, but no action so far. I guess we will see :-) _M