----- Original Message -----
From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 27, 2003 6:53 PM
Subject: RE: [Declude.JunkMail] Wish list reminder... :-)
>> Scott, with talk recently of optimization and efficiency, and where
>>certain
>> tests should be conducted to save on CPU cycles. I was thinking that one
>> way to gain efficiency would be to NOT run Declude and third-party apps
>> (SpamChk, AlliGate/SpamManager, Sniffer, etc.) on whitelisted e-mails
>>(virus
>> scan only). This would not only greatly reduce CPU requirements, but
also
>> greatly cut down on log file sizes for Declude and third-party apps.
>
>I second the MadScientest on this that some programs use information from
>each message no matter what Declude does with it.
Doesn't make any sense to me. If I know that I have web applications that
send mail to my IMail server, and I want to whitelist the IP addresses of
these systems so that all of the spam checks are not run againt them, who
cares if any other third-party application learns about these e-mail--I sure
don't. If I want to whitelist the IP addresses of my Postfix gateway
servers so that spam tests are not run against bounce and other postmaster
messages, again, who cares if any other third-party apps learn about these
private e-mail messages--I sure don't. If I get system reports and pages
from my differnt network and system monitoring servers, and I don't want or
need to have spam tests run against these messages, who cares if other
third-party apps learn about these messages, again, I sure don't.
I could go on, but I think you get my point. We generate thousands of
confidential messages every day from our web server farm, which generates
lab and eligibility reports for our healhcare customers, and our different
mail servers and monitoring systems. Why would anybody care whether a
third-party app learns about these messages? I, as the purchaser of the
software (which include Declude JM and VP, Sniffer, and
AlliGate/SpamManager) care about performance in this instance, because
third-party apps learning about these messages benefits no one, and hinders
my overall system performance.
>> Secondly, what about spam filtering messages before virus scanning, and
if
>> the message accrues a weight high enough to be deleted, then delete and
do
>> NOT virus scan the message. However, if it meets hold or deliver
weights,
>> then virus scan the message before final handling.
>
>Option is already there, but not recommended.
Wrong, what's already there is an option to run JM before virus scanning,
however, the way it's setup now, if a message is held due to spam rules, it
does get virus scanned before being placed in the hold directory. Re-read
my request above. It says:
"However, if it meets hold or deliver weights, then virus scan the
message before final handling"
The filter before scan feature will virus scan a message that is to be
delivered, however it currently will NOT scan a message that is trigger to
be held by JM. I'm asking for the filter before scan option to be changed
so that even held messages get virus scanned by Declude before being placed
into the hold directory, and no scan processing be done on messages flagged
for deletion by JM. Even better would be for the held messages not to be
virus scanned until they have been reviewed, and messages that are flagged
to be moved back into the queue for delivery, first get moved into a
temporary directory first where Declude can virus scan them and then move
them into the spool directory for delivery by IMail.
I would be happy with ether of these filter before scan option changes, and
I figure it can't hurt to ask--can it...? :-p
Bill
---
[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.
