[pmmail-list] SirCam Virus Filtering Update

[Kris Sorem Sr]

On Sun, 05 Aug 2001 08:20:34 -0500 (CDT), Maynard wrote:

>I probably should have read all the messages, and had my coffee, before
>typing this morning ;-}

I sure know how that is!
>
>Kris just injected to this discussion the possibility of a "mutation".
>I wouldn't bet the farm on any of these little tweaks and differences
>of filter criteria. I suppose that the worm itself may be mutatable, so
>as to next month use different body text, fix it's lowercase header
>line, whatever. Not only that, every mail agent through which the
>message passes is capable of making modifications.

Yes, there are no absolutes.
>
>So each person gets to admit that whatever they're doing to protect
>their clients, it is not permanently perfect, and the question becomes
>whether to capture too much (false positive) or too little (false
>negative), adn whether to manually process the filter results or not.

Permanently perfect means I've worked myself out of a job. :) My
preference is to double check manually. But that can get very time
intensive.
>
>If you'd rather have false positives than to let one slip by, use lots
>of 'or's and few if any 'and's. 
>
>False Positives are easier to work with because you have the message
>which was falsely trapped. There's no telling what will happen to a
>false negative message as it hits the rest of the filter stream. It
>could become lost and leave no indication that there was a false
>negative.

Some things are time critical. It would not be good to hold up
something on a false positive. On the other hand you can't bring
everything to a screeching halt either because you missed a false
negative.
>
>Part of my test of the "date: " string was to place a filter for just
>that condition just ahead of the more comlete SirCam filter definition.
>That way if the first failed to catch it, the second filter should get
>it.
>But that was more in the name of personal science than an attempt to
>filter mail for an entire university.

By preference, I choose to place more strict filters ahead of less
strict filters then order them according to volume for speed.
>
>I expect that most of us deploy filters through a process of testing
>and watching them to see if they're working correctly, so there's
>manual involvement in the early stages anyway, and moving message files
>from the "trap" folder back to the inbox is no real big deal during
>this phase of filter development.

Everything can be improved upon. This takes some trial and error.
Hopefully, not too much though.
>
>SirCam is probably a good one for three stage processing.
>1. ICSL filtering moves it to another Folder.
>2. Operator examines trapped folder for false positives and as a
>regular part of filter maintenance ;-}
>3. Manual Filtering notifies sender or whatever else is desired.

Yes, since there are few absolutes here.
>
>If there's even any suggestion that it will mutate, then filters will
>have to mutate with them, or at least be prepared to.
>And the example here is perfect. By modifying the filter from requiring
>both body lines to be present, to a filter which would accept either
>body line, the probability of false positives rises; the safe thing to
>do.
Well stated. Seems like a good point to end this thread.
--
JMO, 
/s/~Kris
-------------------------------+------------------------------------------



- pmmail-list - The PMMail Dicussion List ---------------------------
To UNSUBSCRIBE, send a message to mdaemon@bmtmicro.com with the first 
line of the message body being...
UNSUBSCRIBE pmmail-list@blueprintsoftwareworks.com