RE: [Declude.Virus] EXITSCANONVIRUS
ANYWAYS, what would be the comment from Declude on this issue? John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox Sent: Sunday, May 29, 2005 4:43 PM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS Sounds good to me. I tend to think of both virus and spam detection in the same breath, since I think they're stronger together than separate... but you certainly have a valid point about moving code to Junkmail...and it would seem more useful there as well. I haven't seen the false positives you've seen with the Outlook Boundary Space Gap vulnerability, but it may be due to a variation in customer base. I'll check the logs and let you know what we've seen over a similar timeframe. Happy Memorial Day weekend! Don't forget to spend some time with the fam. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 5:35 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin, My list was really only in respect to my feelings on Declude Virus and not JunkMail. In this perspective of both however, maybe a modification where #2 includes the potential of adding it as a test to JunkMail if it would be beneficial, and a clarification on #3 like so: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients. 2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). Add code to Declude JunkMail if useful for blocking spam. I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients. 3) Removal - Remove the code from the Declude Virus part of the executable. Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years. Note that some of these vulnerabilities have never been actively exploited by viruses. Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach. I think this reflects what you have said, and in essence this is what I was indicating in the paragraph that followed. I would definitely like to see the Outlook CR Vulnerability added to Declude JunkMail as a scoreable test since it does hit on a good deal of spam, but I won't use it in Declude Virus since I can only chose to block or pass and it has daily issues with false positives for my customer base. Other present vulnerabilities might not justify keeping the code however. The Outlook Boundary Space Gap vulnerability trapped a total of 8 messages that weren't otherwise detected as viruses on my system in a two week period of time, covering over 1 million scanned messages. Of these 8 messages, all 8 were legitimate personal E-mails generated by Microsoft's own E-mail clients. I think we could agree that if this is the long-term trend, this code would be best removed or fixed instead of being added to JunkMail. Alternatively, if this is still a threat with this one vulnerability (I don't know), then the detection should be fixed. The false positives were all the result of an error in Declude where the following header was properly 'folded', but Declude seemingly experienced an error in de-folding the headers which led it to believe that there were spaces within the boundary. The 4 spaces at the beginning of the second line in this case is part of proper header folding Content-Type: multipart/alternative; boundary= "_=_NextPart_001_01C55D5F.F2B051DD" This vulnerability is designed to detect spaces or tabs within message boundaries, and apparently could be exploited to package attachments which Outlook clients would read. The above example is not an example of exploitable code. RFC 2912 - http://www.faqs.org/rfcs/rfc2912.html 3.1 Whitespace and folding long headers In some circumstances, media feature expressions can be very long. According to "A Syntax for Describing Media Feature Sets" [1], whitespace is allowed between lexical elements of a media feature _expression_. Further, RFC822/MIME [4,5] allows folding of long headers at points where whitespace appears to avoid line length restrictions. Therefore, it is recommended that whitespace is included as permitted, especially in long me
Re: [Declude.Virus] EXITSCANONVIRUS
I personally would not go with 2 different brands of drives since the 2 different brands would be slightly different in design and could vary in performance and in my opinion could cause issues with array stability. On the other hand I have had drives in Raid1 Fail, but I have never had the whole array fail, 1 drive just goes down and I replace it. Perhaps for the best performance and to avoid a bad lot you would be better off buying 2 drives of the same model and brand but buy them from 2 different vendors so you get 2 different lots. Jim Matuska Jr.Computer Tech2, CCNANez Perce TribeInformation Systems[EMAIL PROTECTED] - Original Message - From: Marc Catuogno To: Declude.Virus@declude.com Sent: Monday, May 30, 2005 8:40 AM Subject: RE: [Declude.Virus] EXITSCANONVIRUS John, Sorry to hear about that it sucks. There was something I heard once about having identical drives mirrored. That if they were from the same vendor and the same model and lot number they can fail at the same time. The IBM Deskstar was apparently notorious for this. If Im building a server I try to use two different HDs on the mirror one IBM and one Maxtor or something. It is tough to get my host to do this for me. Good luck man~ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists)Sent: Monday, May 30, 2005 3:31 AMTo: Declude.Virus@declude.comSubject: RE: [Declude.Virus] EXITSCANONVIRUS Off the topic, but it interrupted my work on my mail server. Any one ever loose both mirrored OS drives at the same time? FUN FUN FUN NOT! At least Ghost is able to read the master. John T eServices For You
RE: [Declude.Virus] EXITSCANONVIRUS
John, it wouldn't help you this time but we have running most of our servers with Raid-Mirroring and each server has a third disk in standby. This disk is not only here to be replaced if one of the other two disk fails but it is also replaced periodicaly (usualy once per month) with one of the mirror drives. So if there is a problem on the RAID who has caused a "disaster" we have at all time a running system that will boot within minutes and begin to restore the daily backup files. Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists)Sent: Monday, May 30, 2005 6:07 PMTo: Declude.Virus@declude.comSubject: RE: [Declude.Virus] EXITSCANONVIRUS Windows. Power went out, for some reason the UPS went into shutdown mode, it appears some thing on the server hung preventing it from shutting down before the UPS shutdown timer expired, the rest is history. Turns out the Ghost image is inconsistent, so I am rebuilding the OS from the ground, will try to do a restore from a backup I made of the extracted OS partition in Ghost, not sure how that is going to go, but if not then will have to recreate in IIS 47 web sites. Data for the sites is fine, as that was on a pair of separate SCSI drives. So much for getting caught up on other work. John T eServices For You -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin CoxSent: Monday, May 30, 2005 6:43 AMTo: Declude.Virus@declude.comSubject: Re: [Declude.Virus] EXITSCANONVIRUS Oh man...I feel your pain! Happened to us mid-April. Fortunately it was just after midnight on a Friday, so we had everything back up before morning and no one noticed the interruption in service. Was it Windows mirroring or hardware level? Darin. - Original Message - From: John Tolmachoff (Lists) To: Declude.Virus@declude.com Sent: Monday, May 30, 2005 3:30 AM Subject: RE: [Declude.Virus] EXITSCANONVIRUS Off the topic, but it interrupted my work on my mail server. Any one ever loose both mirrored OS drives at the same time? FUN FUN FUN NOT! At least Ghost is able to read the master. John T eServices For You ==
RE: [Declude.Virus] EXITSCANONVIRUS
Title: Message Oh, don’t get me started on the ProLiant 350 with the all-in-one SCSIController/NIC/VGA card. Why would any one even ever think to sell a server with a monstrosity like that is beyond me. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Monday, May 30, 2005 9:46 AM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS Yep, that same happened with their hardware raid-1 on an ML 530 (a pretty up-scale server). Had one bad drive (apparently) and the controller managed to wipe out the complete string. The other controller channel was unaffected. I'm pretty certain, I've see this happen twice (the second time I got lucky.) Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Monday, May 30, 2005 12:39 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS Ouch. We've periodically had problems with Compaq (now HP) Proliant servers that have been mostly about the pre-failure being too sensitive; it's now part of our best practice to keep up with driver and ROM updates. This used to be difficult, but now HP has a ROM update bootable ISO image we download, it detects and updates the ROMs on the motherboard, the array cards, and the microcode on the hard drives. It's called the Firmware Maintenance CD. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Monday, May 30, 2005 9:07 AM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS Windows. Power went out, for some reason the UPS went into shutdown mode, it appears some thing on the server hung preventing it from shutting down before the UPS shutdown timer expired, the rest is history. Turns out the Ghost image is inconsistent, so I am rebuilding the OS from the ground, will try to do a restore from a backup I made of the extracted OS partition in Ghost, not sure how that is going to go, but if not then will have to recreate in IIS 47 web sites. Data for the sites is fine, as that was on a pair of separate SCSI drives. So much for getting caught up on other work. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox Sent: Monday, May 30, 2005 6:43 AM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS Oh man...I feel your pain! Happened to us mid-April. Fortunately it was just after midnight on a Friday, so we had everything back up before morning and no one noticed the interruption in service. Was it Windows mirroring or hardware level? Darin. - Original Message - From: John Tolmachoff (Lists) To: Declude.Virus@declude.com Sent: Monday, May 30, 2005 3:30 AM Subject: RE: [Declude.Virus] EXITSCANONVIRUS Off the topic, but it interrupted my work on my mail server. Any one ever loose both mirrored OS drives at the same time? FUN FUN FUN NOT! At least Ghost is able to read the master. John T eServices For You ==
RE: [Declude.Virus] EXITSCANONVIRUS
Title: Message Yep, that same happened with their hardware raid-1 on an ML 530 (a pretty up-scale server). Had one bad drive (apparently) and the controller managed to wipe out the complete string. The other controller channel was unaffected. I'm pretty certain, I've see this happen twice (the second time I got lucky.) Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, AndrewSent: Monday, May 30, 2005 12:39 PMTo: Declude.Virus@declude.comSubject: RE: [Declude.Virus] EXITSCANONVIRUS Ouch. We've periodically had problems with Compaq (now HP) Proliant servers that have been mostly about the pre-failure being too sensitive; it's now part of our best practice to keep up with driver and ROM updates. This used to be difficult, but now HP has a ROM update bootable ISO image we download, it detects and updates the ROMs on the motherboard, the array cards, and the microcode on the hard drives. It's called the Firmware Maintenance CD. Andrew 8) -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists)Sent: Monday, May 30, 2005 9:07 AMTo: Declude.Virus@declude.comSubject: RE: [Declude.Virus] EXITSCANONVIRUS Windows. Power went out, for some reason the UPS went into shutdown mode, it appears some thing on the server hung preventing it from shutting down before the UPS shutdown timer expired, the rest is history. Turns out the Ghost image is inconsistent, so I am rebuilding the OS from the ground, will try to do a restore from a backup I made of the extracted OS partition in Ghost, not sure how that is going to go, but if not then will have to recreate in IIS 47 web sites. Data for the sites is fine, as that was on a pair of separate SCSI drives. So much for getting caught up on other work. John T eServices For You -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin CoxSent: Monday, May 30, 2005 6:43 AMTo: Declude.Virus@declude.comSubject: Re: [Declude.Virus] EXITSCANONVIRUS Oh man...I feel your pain! Happened to us mid-April. Fortunately it was just after midnight on a Friday, so we had everything back up before morning and no one noticed the interruption in service. Was it Windows mirroring or hardware level? Darin. - Original Message - From: John Tolmachoff (Lists) To: Declude.Virus@declude.com Sent: Monday, May 30, 2005 3:30 AM Subject: RE: [Declude.Virus] EXITSCANONVIRUS Off the topic, but it interrupted my work on my mail server. Any one ever loose both mirrored OS drives at the same time? FUN FUN FUN NOT! At least Ghost is able to read the master. John T eServices For You ==
RE: [Declude.Virus] EXITSCANONVIRUS
Title: Message Ouch. We've periodically had problems with Compaq (now HP) Proliant servers that have been mostly about the pre-failure being too sensitive; it's now part of our best practice to keep up with driver and ROM updates. This used to be difficult, but now HP has a ROM update bootable ISO image we download, it detects and updates the ROMs on the motherboard, the array cards, and the microcode on the hard drives. It's called the Firmware Maintenance CD. Andrew 8) -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists)Sent: Monday, May 30, 2005 9:07 AMTo: Declude.Virus@declude.comSubject: RE: [Declude.Virus] EXITSCANONVIRUS Windows. Power went out, for some reason the UPS went into shutdown mode, it appears some thing on the server hung preventing it from shutting down before the UPS shutdown timer expired, the rest is history. Turns out the Ghost image is inconsistent, so I am rebuilding the OS from the ground, will try to do a restore from a backup I made of the extracted OS partition in Ghost, not sure how that is going to go, but if not then will have to recreate in IIS 47 web sites. Data for the sites is fine, as that was on a pair of separate SCSI drives. So much for getting caught up on other work. John T eServices For You -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin CoxSent: Monday, May 30, 2005 6:43 AMTo: Declude.Virus@declude.comSubject: Re: [Declude.Virus] EXITSCANONVIRUS Oh man...I feel your pain! Happened to us mid-April. Fortunately it was just after midnight on a Friday, so we had everything back up before morning and no one noticed the interruption in service. Was it Windows mirroring or hardware level? Darin. - Original Message - From: John Tolmachoff (Lists) To: Declude.Virus@declude.com Sent: Monday, May 30, 2005 3:30 AM Subject: RE: [Declude.Virus] EXITSCANONVIRUS Off the topic, but it interrupted my work on my mail server. Any one ever loose both mirrored OS drives at the same time? FUN FUN FUN NOT! At least Ghost is able to read the master. John T eServices For You ==
RE: [Declude.Virus] EXITSCANONVIRUS
Windows. Power went out, for some reason the UPS went into shutdown mode, it appears some thing on the server hung preventing it from shutting down before the UPS shutdown timer expired, the rest is history. Turns out the Ghost image is inconsistent, so I am rebuilding the OS from the ground, will try to do a restore from a backup I made of the extracted OS partition in Ghost, not sure how that is going to go, but if not then will have to recreate in IIS 47 web sites. Data for the sites is fine, as that was on a pair of separate SCSI drives. So much for getting caught up on other work. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox Sent: Monday, May 30, 2005 6:43 AM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS Oh man...I feel your pain! Happened to us mid-April. Fortunately it was just after midnight on a Friday, so we had everything back up before morning and no one noticed the interruption in service. Was it Windows mirroring or hardware level? Darin. - Original Message - From: John Tolmachoff (Lists) To: Declude.Virus@declude.com Sent: Monday, May 30, 2005 3:30 AM Subject: RE: [Declude.Virus] EXITSCANONVIRUS Off the topic, but it interrupted my work on my mail server. Any one ever loose both mirrored OS drives at the same time? FUN FUN FUN NOT! At least Ghost is able to read the master. John T eServices For You ==
RE: [Declude.Virus] EXITSCANONVIRUS
John, Sorry to hear about that – it sucks. There was something I heard once about having identical drives mirrored. That if they were from the same vendor and the same model and lot number they can fail at the same time. The IBM Deskstar was apparently notorious for this. If I’m building a server I try to use two different HDs on the mirror – one IBM and one Maxtor or something. It is tough to get my host to do this for me. Good luck man~ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Monday, May 30, 2005 3:31 AM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS Off the topic, but it interrupted my work on my mail server. Any one ever loose both mirrored OS drives at the same time? FUN FUN FUN NOT! At least Ghost is able to read the master. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Sunday, May 29, 2005 4:59 PM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS Thanks! The grass is cut and the friends are already on the way over with beer and stuff to burn :) Matt Darin Cox wrote: Sounds good to me. I tend to think of both virus and spam detection in the same breath, since I think they're stronger together than separate... but you certainly have a valid point about moving code to Junkmail...and it would seem more useful there as well. I haven't seen the false positives you've seen with the Outlook Boundary Space Gap vulnerability, but it may be due to a variation in customer base. I'll check the logs and let you know what we've seen over a similar timeframe. Happy Memorial Day weekend! Don't forget to spend some time with the fam. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 5:35 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin, My list was really only in respect to my feelings on Declude Virus and not JunkMail. In this perspective of both however, maybe a modification where #2 includes the potential of adding it as a test to JunkMail if it would be beneficial, and a clarification on #3 like so: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients. 2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). Add code to Declude JunkMail if useful for blocking spam. I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients. 3) Removal - Remove the code from the Declude Virus part of the executable. Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years. Note that some of these vulnerabilities have never been actively exploited by viruses. Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach. I think this reflects what you have said, and in essence this is what I was indicating in the paragraph that followed. I would definitely like to see the Outlook CR Vulnerability added to Declude JunkMail as a scoreable test since it does hit on a good deal of spam, but I won't use it in Declude Virus since I can only chose to block or pass and it has daily issues with false positives for my customer base. Other present vulnerabilities might not justify keeping the code however. The Outlook Boundary Space Gap vulnerability trapped a total of 8 messages that weren't otherwise detected as viruses on my system in a two week period of time, covering over 1 million scanned messages. Of these 8 messages, all 8 were legitimate personal E-mails generated by Microsoft's own E-mail clients. I think we could agree that if this is the long-term trend, this code would be best removed or fixed instead of being added to JunkMail. Alternatively, if this is still a threat with this one vulnerability (I don't know), then the detection should be fixed. The false positives were all the result of an error in Declude where the following header was properly 'folded', but Declude seemingly experienced an error in de-folding the headers which led it to believe that there were spaces within the boundary. The 4 spaces at the beginning of the second
Re: [Declude.Virus] EXITSCANONVIRUS
Oh man...I feel your pain! Happened to us mid-April. Fortunately it was just after midnight on a Friday, so we had everything back up before morning and no one noticed the interruption in service. Was it Windows mirroring or hardware level? Darin. - Original Message - From: John Tolmachoff (Lists) To: Declude.Virus@declude.com Sent: Monday, May 30, 2005 3:30 AM Subject: RE: [Declude.Virus] EXITSCANONVIRUS Off the topic, but it interrupted my work on my mail server. Any one ever loose both mirrored OS drives at the same time? FUN FUN FUN NOT! At least Ghost is able to read the master. John T eServices For You -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Sunday, May 29, 2005 4:59 PMTo: Declude.Virus@declude.comSubject: Re: [Declude.Virus] EXITSCANONVIRUS Thanks! The grass is cut and the friends are already on the way over with beer and stuff to burn :)MattDarin Cox wrote: Sounds good to me. I tend to think of both virus and spam detection in the same breath, since I think they're stronger together than separate... but you certainly have a valid point about moving code to Junkmail...and it would seem more useful there as well. I haven't seen the false positives you've seen with the Outlook Boundary Space Gap vulnerability, but it may be due to a variation in customer base. I'll check the logs and let you know what we've seen over a similar timeframe. Happy Memorial Day weekend! Don't forget to spend some time with the fam. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 5:35 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin,My list was really only in respect to my feelings on Declude Virus and not JunkMail. In this perspective of both however, maybe a modification where #2 includes the potential of adding it as a test to JunkMail if it would be beneficial, and a clarification on #3 like so: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients.2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). Add code to Declude JunkMail if useful for blocking spam. I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients.3) Removal - Remove the code from the Declude Virus part of the executable. Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years. Note that some of these vulnerabilities have never been actively exploited by viruses. Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach. I think this reflects what you have said, and in essence this is what I was indicating in the paragraph that followed.I would definitely like to see the Outlook CR Vulnerability added to Declude JunkMail as a scoreable test since it does hit on a good deal of spam, but I won't use it in Declude Virus since I can only chose to block or pass and it has daily issues with false positives for my customer base.Other present vulnerabilities might not justify keeping the code however. The Outlook Boundary Space Gap vulnerability trapped a total of 8 messages that weren't otherwise detected as viruses on my system in a two week period of time, covering over 1 million scanned messages. Of these 8 messages, all 8 were legitimate personal E-mails generated by Microsoft's own E-mail clients. I think we could agree that if this is the long-term trend, this code would be best removed or fixed instead of being added to JunkMail.Alternatively, if this is still a threat with this one vulnerability (I don't know), then the detection should be fixed. The false positives were all the result of an error in Declude where the following header was properly 'folded', but Declude seemingly experienced an error in de-folding the headers which led it to believe that there were spaces within the boundary. The 4 spaces at the beginning of the second line in this case is part of proper header folding Content-Type: multipart/alternative; boundary= "_=_NextPart_001_01C55D5F.F2B051DD" This vulnerability is designed to detect spaces or tabs within message boundaries, and apparently could be exploited to package attachme
RE: [Declude.Virus] EXITSCANONVIRUS
Off the topic, but it interrupted my work on my mail server. Any one ever loose both mirrored OS drives at the same time? FUN FUN FUN NOT! At least Ghost is able to read the master. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Sunday, May 29, 2005 4:59 PM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS Thanks! The grass is cut and the friends are already on the way over with beer and stuff to burn :) Matt Darin Cox wrote: Sounds good to me. I tend to think of both virus and spam detection in the same breath, since I think they're stronger together than separate... but you certainly have a valid point about moving code to Junkmail...and it would seem more useful there as well. I haven't seen the false positives you've seen with the Outlook Boundary Space Gap vulnerability, but it may be due to a variation in customer base. I'll check the logs and let you know what we've seen over a similar timeframe. Happy Memorial Day weekend! Don't forget to spend some time with the fam. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 5:35 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin, My list was really only in respect to my feelings on Declude Virus and not JunkMail. In this perspective of both however, maybe a modification where #2 includes the potential of adding it as a test to JunkMail if it would be beneficial, and a clarification on #3 like so: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients. 2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). Add code to Declude JunkMail if useful for blocking spam. I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients. 3) Removal - Remove the code from the Declude Virus part of the executable. Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years. Note that some of these vulnerabilities have never been actively exploited by viruses. Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach. I think this reflects what you have said, and in essence this is what I was indicating in the paragraph that followed. I would definitely like to see the Outlook CR Vulnerability added to Declude JunkMail as a scoreable test since it does hit on a good deal of spam, but I won't use it in Declude Virus since I can only chose to block or pass and it has daily issues with false positives for my customer base. Other present vulnerabilities might not justify keeping the code however. The Outlook Boundary Space Gap vulnerability trapped a total of 8 messages that weren't otherwise detected as viruses on my system in a two week period of time, covering over 1 million scanned messages. Of these 8 messages, all 8 were legitimate personal E-mails generated by Microsoft's own E-mail clients. I think we could agree that if this is the long-term trend, this code would be best removed or fixed instead of being added to JunkMail. Alternatively, if this is still a threat with this one vulnerability (I don't know), then the detection should be fixed. The false positives were all the result of an error in Declude where the following header was properly 'folded', but Declude seemingly experienced an error in de-folding the headers which led it to believe that there were spaces within the boundary. The 4 spaces at the beginning of the second line in this case is part of proper header folding Content-Type: multipart/alternative; boundary= "_=_NextPart_001_01C55D5F.F2B051DD" This vulnerability is designed to detect spaces or tabs within message boundaries, and apparently could be exploited to package attachments which Outlook clients would read. The above example is not an example of exploitable code. RFC 2912 - http://www.faqs.org/rfcs/rfc2912.html 3.1 Whitespace and folding long headers In some circumstances, media feature expressions can be very long. According to "A Syntax for Describing Media Feature Sets" [1], whitespace is allowed between lexical elements of a media fe
Re: [Declude.Virus] EXITSCANONVIRUS
Sounds good to me. I tend to think of both virus and spam detection in the same breath, since I think they're stronger together than separate... but you certainly have a valid point about moving code to Junkmail...and it would seem more useful there as well. I haven't seen the false positives you've seen with the Outlook Boundary Space Gap vulnerability, but it may be due to a variation in customer base. I'll check the logs and let you know what we've seen over a similar timeframe. Happy Memorial Day weekend! Don't forget to spend some time with the fam. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 5:35 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin,My list was really only in respect to my feelings on Declude Virus and not JunkMail. In this perspective of both however, maybe a modification where #2 includes the potential of adding it as a test to JunkMail if it would be beneficial, and a clarification on #3 like so: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients.2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). Add code to Declude JunkMail if useful for blocking spam. I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients.3) Removal - Remove the code from the Declude Virus part of the executable. Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years. Note that some of these vulnerabilities have never been actively exploited by viruses. Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach.I think this reflects what you have said, and in essence this is what I was indicating in the paragraph that followed.I would definitely like to see the Outlook CR Vulnerability added to Declude JunkMail as a scoreable test since it does hit on a good deal of spam, but I won't use it in Declude Virus since I can only chose to block or pass and it has daily issues with false positives for my customer base.Other present vulnerabilities might not justify keeping the code however. The Outlook Boundary Space Gap vulnerability trapped a total of 8 messages that weren't otherwise detected as viruses on my system in a two week period of time, covering over 1 million scanned messages. Of these 8 messages, all 8 were legitimate personal E-mails generated by Microsoft's own E-mail clients. I think we could agree that if this is the long-term trend, this code would be best removed or fixed instead of being added to JunkMail.Alternatively, if this is still a threat with this one vulnerability (I don't know), then the detection should be fixed. The false positives were all the result of an error in Declude where the following header was properly 'folded', but Declude seemingly experienced an error in de-folding the headers which led it to believe that there were spaces within the boundary. The 4 spaces at the beginning of the second line in this case is part of proper header folding Content-Type: multipart/alternative; boundary= "_=_NextPart_001_01C55D5F.F2B051DD"This vulnerability is designed to detect spaces or tabs within message boundaries, and apparently could be exploited to package attachments which Outlook clients would read. The above example is not an example of exploitable code. RFC 2912 - http://www.faqs.org/rfcs/rfc2912.html3.1 Whitespace and folding long headers In some circumstances, media feature expressions can be very long. According to "A Syntax for Describing Media Feature Sets" [1], whitespace is allowed between lexical elements of a media feature _expression_. Further, RFC822/MIME [4,5] allows folding of long headers at points where whitespace appears to avoid line length restrictions. Therefore, it is recommended that whitespace is included as permitted, especially in long media feature expressions, to facilitate the folding of headers by agents that do not otherwise understand the syntax of this field.For this to have been the vulnerability, the whitespace would have needed to have been within the quotes that defined the boundary and not before it.MattDarin Cox wrote:
Re: [Declude.Virus] EXITSCANONVIRUS
Thanks! The grass is cut and the friends are already on the way over with beer and stuff to burn :) Matt Darin Cox wrote: Sounds good to me. I tend to think of both virus and spam detection in the same breath, since I think they're stronger together than separate... but you certainly have a valid point about moving code to Junkmail...and it would seem more useful there as well. I haven't seen the false positives you've seen with the Outlook Boundary Space Gap vulnerability, but it may be due to a variation in customer base. I'll check the logs and let you know what we've seen over a similar timeframe. Happy Memorial Day weekend! Don't forget to spend some time with the fam. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 5:35 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin, My list was really only in respect to my feelings on Declude Virus and not JunkMail. In this perspective of both however, maybe a modification where #2 includes the potential of adding it as a test to JunkMail if it would be beneficial, and a clarification on #3 like so: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients. 2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). Add code to Declude JunkMail if useful for blocking spam. I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients. 3) Removal - Remove the code from the Declude Virus part of the executable. Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years. Note that some of these vulnerabilities have never been actively exploited by viruses. Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach. I think this reflects what you have said, and in essence this is what I was indicating in the paragraph that followed. I would definitely like to see the Outlook CR Vulnerability added to Declude JunkMail as a scoreable test since it does hit on a good deal of spam, but I won't use it in Declude Virus since I can only chose to block or pass and it has daily issues with false positives for my customer base. Other present vulnerabilities might not justify keeping the code however. The Outlook Boundary Space Gap vulnerability trapped a total of 8 messages that weren't otherwise detected as viruses on my system in a two week period of time, covering over 1 million scanned messages. Of these 8 messages, all 8 were legitimate personal E-mails generated by Microsoft's own E-mail clients. I think we could agree that if this is the long-term trend, this code would be best removed or fixed instead of being added to JunkMail. Alternatively, if this is still a threat with this one vulnerability (I don't know), then the detection should be fixed. The false positives were all the result of an error in Declude where the following header was properly 'folded', but Declude seemingly experienced an error in de-folding the headers which led it to believe that there were spaces within the boundary. The 4 spaces at the beginning of the second line in this case is part of proper header folding Content-Type: multipart/alternative; boundary= "_=_NextPart_001_01C55D5F.F2B051DD" This vulnerability is designed to detect spaces or tabs within message boundaries, and apparently could be exploited to package attachments which Outlook clients would read. The above example is not an example of exploitable code. RFC 2912 - http://www.faqs.org/rfcs/rfc2912.html 3.1 Whitespace and folding long headers In some circumstances, media feature expressions can be very long. According to "A Syntax for Describing Media Feature Sets" [1], whitespace is allowed between lexical elements of a media feature _expression_. Further, RFC822/MIME [4,5] allows folding of long headers at points where whitespace appears to avoid line length restrictions. Therefore, it is recommended that whitespace is included as permitted, especially in long media feature expressions, to facilitate the folding of headers by agents that do not otherwise understand the syntax of this field. For this to have been the vulnerability, the
Re: [Declude.Virus] EXITSCANONVIRUS
, and apparently could be exploited to package attachments which Outlook clients would read. The above example is not an example of exploitable code. RFC 2912 - http://www.faqs.org/rfcs/rfc2912.html 3.1 Whitespace and folding long headers In some circumstances, media feature expressions can be very long. According to "A Syntax for Describing Media Feature Sets" [1], whitespace is allowed between lexical elements of a media feature _expression_. Further, RFC822/MIME [4,5] allows folding of long headers at points where whitespace appears to avoid line length restrictions. Therefore, it is recommended that whitespace is included as permitted, especially in long media feature expressions, to facilitate the folding of headers by agents that do not otherwise understand the syntax of this field. For this to have been the vulnerability, the whitespace would have needed to have been within the quotes that defined the boundary and not before it. Matt Darin Cox wrote: Hi Matt, I think most of us always consider the "greater good" before making requests... and by their nature, most requests from one person have benefit to many others. I think the recommendation you outlined below is fairly good...but again, I would not like to see potentially valuable tests removed. Defaulting to off is good, but removing doesn't make sense when there's value in the test. Other than an occasional Partial vulnerability, I see no false positives with vulnerabilities from our user base. I do think your point about moving the code from Virus over to Junkmail is a good one when it is no longer an active vulnerability. I would just hate to see a valuable test removed, and again, we see a decent amount of spam caught by Virus that doesn't get caught by our Junkmail config. Code can easily be broken in moving from one place to another (Virus to Junkmail), so this may be a maintenance problem that it is desirable to avoid. However, deprecated vulnerabilities could potentially be more valuable there for use in weighting or combo tests to identify particular spammers and assist with detecting their payloads. I think this all falls under the "The more info we have about a message, the better we can classify it" category. Indeed, one of the main reasons we haven't migrated to SmarterMail is the unavailability of the CMDSPACE test. We find much of the strength in Declude is due to the variety of special tests Scott was able to come up with. So, with the caveat of not performing Item 3 in your list (Removal), it sounds very good to me. It's nowhere near #1 on my list either...just didn't want anything useful to disappear. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 4:22 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin, I think there are many different ways to define "retire" in this context. Personally, I have already 'retired' the functionality on my system where I feel that it appropriate, but when I share my opinions and recommendations, I am often thinking of the greater good. I tend to not ask for things from Declude that would not also be of benefit to a good number of it's users. While having the switch alone might be good enough for the majority of us on these lists, the majority of Declude's customers don't pay attention to the lists, release notes, or many other things...they tend to run default configurations with very little in the way of tweaks. These people are most in need of a solution, though they probably mostly don't recognize the issue, and likewise wouldn't recognize the solution. By Declude providing this functionality and not working it into the overall approach for the best standard config and practices, it really only serves the few of us that are paying very close attention. So in this perspective, the best global approach in my opinion would be to establish a system for depricating such functionality. I would suggest the following: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients. 2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients. 3) Removal - Remove the code from the executable. Depending on the conditions related to the vulnerability; i.e. commonality in e
Re: [Declude.Virus] EXITSCANONVIRUS
our Junkmail config. Code can easily be broken in moving from one place to another (Virus to Junkmail), so this may be a maintenance problem that it is desirable to avoid. However, deprecated vulnerabilities could potentially be more valuable there for use in weighting or combo tests to identify particular spammers and assist with detecting their payloads. I think this all falls under the "The more info we have about a message, the better we can classify it" category. Indeed, one of the main reasons we haven't migrated to SmarterMail is the unavailability of the CMDSPACE test. We find much of the strength in Declude is due to the variety of special tests Scott was able to come up with. So, with the caveat of not performing Item 3 in your list (Removal), it sounds very good to me. It's nowhere near #1 on my list either...just didn't want anything useful to disappear. Darin. - Original Message ----- From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 4:22 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin, I think there are many different ways to define "retire" in this context. Personally, I have already 'retired' the functionality on my system where I feel that it appropriate, but when I share my opinions and recommendations, I am often thinking of the greater good. I tend to not ask for things from Declude that would not also be of benefit to a good number of it's users. While having the switch alone might be good enough for the majority of us on these lists, the majority of Declude's customers don't pay attention to the lists, release notes, or many other things...they tend to run default configurations with very little in the way of tweaks. These people are most in need of a solution, though they probably mostly don't recognize the issue, and likewise wouldn't recognize the solution. By Declude providing this functionality and not working it into the overall approach for the best standard config and practices, it really only serves the few of us that are paying very close attention. So in this perspective, the best global approach in my opinion would be to establish a system for depricating such functionality. I would suggest the following: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients. 2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients. 3) Removal - Remove the code from the executable. Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years. Note that some of these vulnerabilities have never been actively exploited by viruses. Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach. Regarding their use in blocking some spam, I personally would rather Declude JunkMail tag such things, that way we could handle this as spam, as well as the potential false positives, within the systems that we have built to handle spam instead of the one built to handle viruses. Active Vulnerabilities are a different story, but I wouldn't object to seeing code added to BADHEADERS/SPAMHEADERS or another built-in test to show that something failed a depricated check within the context of Declude JunkMail. Some of these vulnerabilities are presently less than 90% accurate on my system in judging between spam and ham, though the viruses associated with them might well be deleted if they do exist and were detected by one of my scanners (I've based this on a review of the spam folder and I delete viruses on my system). The Outlook CR Vulnerability blocks the most spam, but it also has the highest number of false positives by far. Web mail generated messages from Comcast, Excite, 126.com/263.com (Chinese equivalent of Hotmail) will all fail Outlook CR in Declude. Does that sound reasonable? Would it provide for all of what you desire in this respect? I do get that the folks at Declude do read this stuff and they seem to be embracing our logic and popular opinion on the lists lately, so I would guess that what you think does count for something. Personally this isn't by far my #1 issue since I have already solv
Re: [Declude.Virus] EXITSCANONVIRUS
Hi Matt, I think most of us always consider the "greater good" before making requests... and by their nature, most requests from one person have benefit to many others. I think the recommendation you outlined below is fairly good...but again, I would not like to see potentially valuable tests removed. Defaulting to off is good, but removing doesn't make sense when there's value in the test. Other than an occasional Partial vulnerability, I see no false positives with vulnerabilities from our user base. I do think your point about moving the code from Virus over to Junkmail is a good one when it is no longer an active vulnerability. I would just hate to see a valuable test removed, and again, we see a decent amount of spam caught by Virus that doesn't get caught by our Junkmail config. Code can easily be broken in moving from one place to another (Virus to Junkmail), so this may be a maintenance problem that it is desirable to avoid. However, deprecated vulnerabilities could potentially be more valuable there for use in weighting or combo tests to identify particular spammers and assist with detecting their payloads. I think this all falls under the "The more info we have about a message, the better we can classify it" category. Indeed, one of the main reasons we haven't migrated to SmarterMail is the unavailability of the CMDSPACE test. We find much of the strength in Declude is due to the variety of special tests Scott was able to come up with. So, with the caveat of not performing Item 3 in your list (Removal), it sounds very good to me. It's nowhere near #1 on my list either...just didn't want anything useful to disappear. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 4:22 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin,I think there are many different ways to define "retire" in this context.Personally, I have already 'retired' the functionality on my system where I feel that it appropriate, but when I share my opinions and recommendations, I am often thinking of the greater good. I tend to not ask for things from Declude that would not also be of benefit to a good number of it's users. While having the switch alone might be good enough for the majority of us on these lists, the majority of Declude's customers don't pay attention to the lists, release notes, or many other things...they tend to run default configurations with very little in the way of tweaks. These people are most in need of a solution, though they probably mostly don't recognize the issue, and likewise wouldn't recognize the solution. By Declude providing this functionality and not working it into the overall approach for the best standard config and practices, it really only serves the few of us that are paying very close attention.So in this perspective, the best global approach in my opinion would be to establish a system for depricating such functionality. I would suggest the following: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients.2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients.3) Removal - Remove the code from the executable. Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years. Note that some of these vulnerabilities have never been actively exploited by viruses. Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach.Regarding their use in blocking some spam, I personally would rather Declude JunkMail tag such things, that way we could handle this as spam, as well as the potential false positives, within the systems that we have built to handle spam instead of the one built to handle viruses. Active Vulnerabilities are a different story, but I wouldn't object to seeing code added to BADHEADERS/SPAMHEADERS or another built-in test to show that something failed a depricated check within the context of Declude JunkMail. Some of these vulnerabilities are presently less than 90% accurate on my system in judging between spam and ham, though the viruses associated wi
Re: [Declude.Virus] EXITSCANONVIRUS
Darin, I think there are many different ways to define "retire" in this context. Personally, I have already 'retired' the functionality on my system where I feel that it appropriate, but when I share my opinions and recommendations, I am often thinking of the greater good. I tend to not ask for things from Declude that would not also be of benefit to a good number of it's users. While having the switch alone might be good enough for the majority of us on these lists, the majority of Declude's customers don't pay attention to the lists, release notes, or many other things...they tend to run default configurations with very little in the way of tweaks. These people are most in need of a solution, though they probably mostly don't recognize the issue, and likewise wouldn't recognize the solution. By Declude providing this functionality and not working it into the overall approach for the best standard config and practices, it really only serves the few of us that are paying very close attention. So in this perspective, the best global approach in my opinion would be to establish a system for depricating such functionality. I would suggest the following: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients. I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients. 2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call). I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients. 3) Removal - Remove the code from the executable. Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years. Note that some of these vulnerabilities have never been actively exploited by viruses. Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach. Regarding their use in blocking some spam, I personally would rather Declude JunkMail tag such things, that way we could handle this as spam, as well as the potential false positives, within the systems that we have built to handle spam instead of the one built to handle viruses. Active Vulnerabilities are a different story, but I wouldn't object to seeing code added to BADHEADERS/SPAMHEADERS or another built-in test to show that something failed a depricated check within the context of Declude JunkMail. Some of these vulnerabilities are presently less than 90% accurate on my system in judging between spam and ham, though the viruses associated with them might well be deleted if they do exist and were detected by one of my scanners (I've based this on a review of the spam folder and I delete viruses on my system). The Outlook CR Vulnerability blocks the most spam, but it also has the highest number of false positives by far. Web mail generated messages from Comcast, Excite, 126.com/263.com (Chinese equivalent of Hotmail) will all fail Outlook CR in Declude. Does that sound reasonable? Would it provide for all of what you desire in this respect? I do get that the folks at Declude do read this stuff and they seem to be embracing our logic and popular opinion on the lists lately, so I would guess that what you think does count for something. Personally this isn't by far my #1 issue since I have already solved it with other new functionality, but I think the process is just as if not more important as the functionality to the product and the customer base as a whole. Matt Darin Cox wrote: Matt, Point taken that it may no longer be a vulnerability. So, call it something different, maybe just another type of spam test, but don't take it away. They still have value as tests. As I stated earlier, we see spam held by the vulnerability tests that were not detected by spam tests. If the vulnerability/test can be disabled so it doesn't add any processing time to your config, why argue that it should be taken away from someone else who still has a use for it? Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 2:06 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin, A vulnerability is only a vulnerability if there is an application vulnerable to it. Viruses also won't ever achieve 'critical mass' and therefore won't succeed in the wild if they rely on exploiting a vulnerability that no longer exists. Given that
Re: [Declude.Virus] EXITSCANONVIRUS
Matt, Point taken that it may no longer be a vulnerability. So, call it something different, maybe just another type of spam test, but don't take it away. They still have value as tests. As I stated earlier, we see spam held by the vulnerability tests that were not detected by spam tests. If the vulnerability/test can be disabled so it doesn't add any processing time to your config, why argue that it should be taken away from someone else who still has a use for it? Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 2:06 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin,A vulnerability is only a vulnerability if there is an application vulnerable to it. Viruses also won't ever achieve 'critical mass' and therefore won't succeed in the wild if they rely on exploiting a vulnerability that no longer exists. Given that some of these vulnerabilities have been patched for more than two years, it is unlikely that a mass-mailing virus would attempt to exploit one of them, and if they relied on one of these methods that was long since patched, they could end up hurting their chances of success since their attachments wouldn't be seen by the E-mail clients receiving them (it would be better just to attach it normally and would make no sense to try to exploit the old vulnerability).Many of the vulnerability checks in Declude were the result of flaws in Outlook and Outlook Express. There were mostly ways to package in attachments in E-mails so that error correction in the clients would display or even execute the attachments, but the deMIMEing engines associated with E-mail virus scanners might not recognize them as attachments and therefore might not even attempt to scan the attachments. The shortcoming to many of Declude's vulnerability checks is that they might only check for the presence of the precursor or non-standard (but sometimes compliant) construction, and not the presence of the exploit (such as an attachment buried in the headers). So in essence all this is tagging is construction, and there are flaws in many of the current detection methods that can tag legitimate E-mail.This didn't become much of an issue for me until the number of addresses and domains expanded to the point where most flaws in the detection, or otherwise error prone mailers of legitimate E-mail were tripping these things in measurable numbers every single day. For servers with single domains or fewer addresses, this is probably much less of an issue, but the false positives would be more likely to go undetected.My opinion is that every vulnerability has a lifespan, and eventually should be retired if there is any chance of it causing a false positive, or even regardless. One example would be the "Object Data Vulnerability". This was discovered by eEye in the April of 2003 and patched by Microsoft on October 3, 2003. Two fairly unsuccessful Bagle variants exploited this vulnerability in April of 2004 and Declude added this to their list of vulnerabilities in response. While other viruses might have attempted to exploit this vulnerability, it would not be successful given the year and a half since the patch...it wouldn't be successful enough to achieve critical mass. On the flip side of this, I have found that Outlook can trip this vulnerability in Declude under certain circumstances, though I'm not sure what exactly they are, and the only solutions would be to fix the detection, turn it off, or retire it. I have almost zero concern about this causing me any issues by not detecting it at this point. http://www.eeye.com/html/Research/Advisories/AD20030820.html http://www.microsoft.com/technet/security/bulletin/MS03-040.mspx There are similar conditions for other vulnerabilities as well. It was good to have them at the time, but now they are more trouble that their worth in my opinion.MattDarin Cox wrote: I would hope existing vulnerability checks would not be retired, since there are already flags to decide whether or not to check for particular ones. We catch a bit of spam in the virus queue with these checks that is not otherwise caught, especially some that someone else (Andrew?) mentioned getting rid of. Unless there is 100% probability that no one will use the functionality any longer, please add flags to turn it off instead of removing it completely. That way those that still prefer it can still use it. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 1:23 AM Subject: Re: [Declude.Virus] EXITSCANONVIRUS John,I don't think that the behavior displayed in your logs was entirely purposeful. Declude tagged it with a vulnerability and then it ran your first virus scanner and found no virus, an
Re: [Declude.Virus] EXITSCANONVIRUS
Darin, A vulnerability is only a vulnerability if there is an application vulnerable to it. Viruses also won't ever achieve 'critical mass' and therefore won't succeed in the wild if they rely on exploiting a vulnerability that no longer exists. Given that some of these vulnerabilities have been patched for more than two years, it is unlikely that a mass-mailing virus would attempt to exploit one of them, and if they relied on one of these methods that was long since patched, they could end up hurting their chances of success since their attachments wouldn't be seen by the E-mail clients receiving them (it would be better just to attach it normally and would make no sense to try to exploit the old vulnerability). Many of the vulnerability checks in Declude were the result of flaws in Outlook and Outlook Express. There were mostly ways to package in attachments in E-mails so that error correction in the clients would display or even execute the attachments, but the deMIMEing engines associated with E-mail virus scanners might not recognize them as attachments and therefore might not even attempt to scan the attachments. The shortcoming to many of Declude's vulnerability checks is that they might only check for the presence of the precursor or non-standard (but sometimes compliant) construction, and not the presence of the exploit (such as an attachment buried in the headers). So in essence all this is tagging is construction, and there are flaws in many of the current detection methods that can tag legitimate E-mail. This didn't become much of an issue for me until the number of addresses and domains expanded to the point where most flaws in the detection, or otherwise error prone mailers of legitimate E-mail were tripping these things in measurable numbers every single day. For servers with single domains or fewer addresses, this is probably much less of an issue, but the false positives would be more likely to go undetected. My opinion is that every vulnerability has a lifespan, and eventually should be retired if there is any chance of it causing a false positive, or even regardless. One example would be the "Object Data Vulnerability". This was discovered by eEye in the April of 2003 and patched by Microsoft on October 3, 2003. Two fairly unsuccessful Bagle variants exploited this vulnerability in April of 2004 and Declude added this to their list of vulnerabilities in response. While other viruses might have attempted to exploit this vulnerability, it would not be successful given the year and a half since the patch...it wouldn't be successful enough to achieve critical mass. On the flip side of this, I have found that Outlook can trip this vulnerability in Declude under certain circumstances, though I'm not sure what exactly they are, and the only solutions would be to fix the detection, turn it off, or retire it. I have almost zero concern about this causing me any issues by not detecting it at this point. http://www.eeye.com/html/Research/Advisories/AD20030820.html http://www.microsoft.com/technet/security/bulletin/MS03-040.mspx There are similar conditions for other vulnerabilities as well. It was good to have them at the time, but now they are more trouble that their worth in my opinion. Matt Darin Cox wrote: I would hope existing vulnerability checks would not be retired, since there are already flags to decide whether or not to check for particular ones. We catch a bit of spam in the virus queue with these checks that is not otherwise caught, especially some that someone else (Andrew?) mentioned getting rid of. Unless there is 100% probability that no one will use the functionality any longer, please add flags to turn it off instead of removing it completely. That way those that still prefer it can still use it. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 1:23 AM Subject: Re: [Declude.Virus] EXITSCANONVIRUS John, I don't think that the behavior displayed in your logs was entirely purposeful. Declude tagged it with a vulnerability and then it ran your first virus scanner and found no virus, and then apparently it decided not to run the last two virus scanners. This of course is only interim functionality and I would imagine that they would be open to reports of unexpected behavior as well as tweaks for more optimal behavior. I believe that the intended functionality for EXITSCANONVIRUS ON would be to ignore the vulnerabilities and only skip further virus scanning when a prior virus scanner reports an exit code that you have configured to mark it as a virus. This seems consistent with what you are saying it should be. In an older thread regarding some bugs with F-Prot and other related things, Andrew also suggested separate functionality that would skip virus scanning when a vu
Re: [Declude.Virus] EXITSCANONVIRUS
I'll second the EXITSCANONVULNERABILITY option. There is an occasional need to requeue a message that false positived on a vulnerability, so I would myself prefer that all those messages would be checked for viruses. I'd run: EXITSCANONVIRUS ON EXITSCANONVULNERABILITY OFF I think it would also be interesting if the virus-laden emails and vulnerabilites-laden emails got put into different folders. I don't know if this is an Imail or a Declude function. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 12:23 AM Subject: Re: [Declude.Virus] EXITSCANONVIRUS John,I don't think that the behavior displayed in your logs was entirely purposeful. Declude tagged it with a vulnerability and then it ran your first virus scanner and found no virus, and then apparently it decided not to run the last two virus scanners. This of course is only interim functionality and I would imagine that they would be open to reports of unexpected behavior as well as tweaks for more optimal behavior.I believe that the intended functionality for EXITSCANONVIRUS ON would be to ignore the vulnerabilities and only skip further virus scanning when a prior virus scanner reports an exit code that you have configured to mark it as a virus. This seems consistent with what you are saying it should be.In an older thread regarding some bugs with F-Prot and other related things, Andrew also suggested separate functionality that would skip virus scanning when a vulnerability was found since that would be enough to block it on most systems. At that time I suggested that this was not necessarily a good idea, but I made a mistake. For my system, and many others running BANCRVIRUSES ON, it might be an even bigger CPU savings to skip all virus scanners when a vulnerability is detected. The only downside to this is that you will fill up your virus directory when using such a switch unless you are using another new directive, DELETEVULNERABILITIES ON. Naturally skipping virus scanning for vulnerabilities would be optional and not the default setting, and so would be deleting vulnerabilities. I would be in favor of seeing something like EXITSCANONVULNERABILITY added to Declude.Note that there are many issues with the current set of vulnerability checks that Declude does, and it would help to address these at the same time. We do have a switch to turn most of this off, but I get the impression that they are aware of the issues and are considering or may have decided to approach vulnerabilities differently, or possibly retiring some where appropriate. Deleting messages that fail vulnerability checks but aren't tagged as viruses should only really be done if you can rely on the vulnerability checks to be accurate.MattJohn Tolmachoff (Lists) wrote: It appears to be stopping when it finds a vulnerability and does not get scanned for virus. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Colbeck, Andrew Sent: Saturday, May 28, 2005 5:58 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS ... that's reasonable, John. How does it work up to now? If a vulnerability and a virus are detected, which gets reported? Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, May 28, 2005 5:17 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS I agree with Darrell. If it contains a virus, I want it to be marked as a virus. If it does not contain a virus, then if it contains a vulnerability or banned extension then mark as such. An example is that some Sober viruses also contain vulnerability. Well, I want it labeled as a virus not vulnerability. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Darrell ([EMAIL PROTECTED]) Sent: Saturday, May 28, 2005 10:10 AM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS My thoughts are this - a virus is a virus and a vulnerability is a vulnerability. My expectation is that if a virus is detected than the other scanners will not be called. However, if a vulnerability is detected the scanners will execute until such time a "virus" is found. Maybe two switches - EXITSCANONVULNERABILITY... However, on the grander scale of things if nothing changed on this I would still use EXITSCANONVIRUS as long as it observes the various delivery options on vulnerabilities. Darrell --- invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the default configuration. Download a copy today - http://www.invariantsystems
Re: [Declude.Virus] EXITSCANONVIRUS
I would hope existing vulnerability checks would not be retired, since there are already flags to decide whether or not to check for particular ones. We catch a bit of spam in the virus queue with these checks that is not otherwise caught, especially some that someone else (Andrew?) mentioned getting rid of. Unless there is 100% probability that no one will use the functionality any longer, please add flags to turn it off instead of removing it completely. That way those that still prefer it can still use it. Darin. - Original Message - From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 1:23 AM Subject: Re: [Declude.Virus] EXITSCANONVIRUS John,I don't think that the behavior displayed in your logs was entirely purposeful. Declude tagged it with a vulnerability and then it ran your first virus scanner and found no virus, and then apparently it decided not to run the last two virus scanners. This of course is only interim functionality and I would imagine that they would be open to reports of unexpected behavior as well as tweaks for more optimal behavior.I believe that the intended functionality for EXITSCANONVIRUS ON would be to ignore the vulnerabilities and only skip further virus scanning when a prior virus scanner reports an exit code that you have configured to mark it as a virus. This seems consistent with what you are saying it should be.In an older thread regarding some bugs with F-Prot and other related things, Andrew also suggested separate functionality that would skip virus scanning when a vulnerability was found since that would be enough to block it on most systems. At that time I suggested that this was not necessarily a good idea, but I made a mistake. For my system, and many others running BANCRVIRUSES ON, it might be an even bigger CPU savings to skip all virus scanners when a vulnerability is detected. The only downside to this is that you will fill up your virus directory when using such a switch unless you are using another new directive, DELETEVULNERABILITIES ON. Naturally skipping virus scanning for vulnerabilities would be optional and not the default setting, and so would be deleting vulnerabilities. I would be in favor of seeing something like EXITSCANONVULNERABILITY added to Declude.Note that there are many issues with the current set of vulnerability checks that Declude does, and it would help to address these at the same time. We do have a switch to turn most of this off, but I get the impression that they are aware of the issues and are considering or may have decided to approach vulnerabilities differently, or possibly retiring some where appropriate. Deleting messages that fail vulnerability checks but aren't tagged as viruses should only really be done if you can rely on the vulnerability checks to be accurate.MattJohn Tolmachoff (Lists) wrote: It appears to be stopping when it finds a vulnerability and does not get scanned for virus. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Colbeck, Andrew Sent: Saturday, May 28, 2005 5:58 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS ... that's reasonable, John. How does it work up to now? If a vulnerability and a virus are detected, which gets reported? Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, May 28, 2005 5:17 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS I agree with Darrell. If it contains a virus, I want it to be marked as a virus. If it does not contain a virus, then if it contains a vulnerability or banned extension then mark as such. An example is that some Sober viruses also contain vulnerability. Well, I want it labeled as a virus not vulnerability. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Darrell ([EMAIL PROTECTED]) Sent: Saturday, May 28, 2005 10:10 AM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS My thoughts are this - a virus is a virus and a vulnerability is a vulnerability. My expectation is that if a virus is detected than the other scanners will not be called. However, if a vulnerability is detected the scanners will execute until such time a "virus" is found. Maybe two switches - EXITSCANONVULNERABILITY... However, on the grander scale of things if nothing changed on this I would still use EXITSCANONVIRUS as long as it observes the various delivery options on vulnerabilities. Darrell --- invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the default configuration. Download a copy today - http://www.invariantsystems.com - Original Message ---
Re: [Declude.Virus] EXITSCANONVIRUS
John, I don't think that the behavior displayed in your logs was entirely purposeful. Declude tagged it with a vulnerability and then it ran your first virus scanner and found no virus, and then apparently it decided not to run the last two virus scanners. This of course is only interim functionality and I would imagine that they would be open to reports of unexpected behavior as well as tweaks for more optimal behavior. I believe that the intended functionality for EXITSCANONVIRUS ON would be to ignore the vulnerabilities and only skip further virus scanning when a prior virus scanner reports an exit code that you have configured to mark it as a virus. This seems consistent with what you are saying it should be. In an older thread regarding some bugs with F-Prot and other related things, Andrew also suggested separate functionality that would skip virus scanning when a vulnerability was found since that would be enough to block it on most systems. At that time I suggested that this was not necessarily a good idea, but I made a mistake. For my system, and many others running BANCRVIRUSES ON, it might be an even bigger CPU savings to skip all virus scanners when a vulnerability is detected. The only downside to this is that you will fill up your virus directory when using such a switch unless you are using another new directive, DELETEVULNERABILITIES ON. Naturally skipping virus scanning for vulnerabilities would be optional and not the default setting, and so would be deleting vulnerabilities. I would be in favor of seeing something like EXITSCANONVULNERABILITY added to Declude. Note that there are many issues with the current set of vulnerability checks that Declude does, and it would help to address these at the same time. We do have a switch to turn most of this off, but I get the impression that they are aware of the issues and are considering or may have decided to approach vulnerabilities differently, or possibly retiring some where appropriate. Deleting messages that fail vulnerability checks but aren't tagged as viruses should only really be done if you can rely on the vulnerability checks to be accurate. Matt John Tolmachoff (Lists) wrote: It appears to be stopping when it finds a vulnerability and does not get scanned for virus. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Colbeck, Andrew Sent: Saturday, May 28, 2005 5:58 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS ... that's reasonable, John. How does it work up to now? If a vulnerability and a virus are detected, which gets reported? Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, May 28, 2005 5:17 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS I agree with Darrell. If it contains a virus, I want it to be marked as a virus. If it does not contain a virus, then if it contains a vulnerability or banned extension then mark as such. An example is that some Sober viruses also contain vulnerability. Well, I want it labeled as a virus not vulnerability. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Darrell ([EMAIL PROTECTED]) Sent: Saturday, May 28, 2005 10:10 AM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS My thoughts are this - a virus is a virus and a vulnerability is a vulnerability. My expectation is that if a virus is detected than the other scanners will not be called. However, if a vulnerability is detected the scanners will execute until such time a "virus" is found. Maybe two switches - EXITSCANONVULNERABILITY... However, on the grander scale of things if nothing changed on this I would still use EXITSCANONVIRUS as long as it observes the various delivery options on vulnerabilities. Darrell --- invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the default configuration. Download a copy today - http://www.invariantsystems.com - Original Message - From: "Colbeck, Andrew" <[EMAIL PROTECTED]> To: Sent: Saturday, May 28, 2005 12:49 PM Subject: RE: [Declude.Virus] EXITSCANONVIRUS John, can you expand on that? In my implementation, there is no difference in message treatment if a vulnerability or virus is detected. Therefore, I am happy to stop the virus scanning if a vulnerability is detected. That is, as long as ALLOWVULNERABILITIESFROM is still respected. Of course, I've already found that these two had too many false positives for the safety they afford, so I've turned them off: BANPARTIAL OFF BANCRVIRUSE
RE: [Declude.Virus] EXITSCANONVIRUS
... right, but what's the behaviour without the new: EXITSCANONVIRUS ON option when a vulnerability and virus are in a single message? Which gets reported? Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, May 28, 2005 7:23 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS It appears to be stopping when it finds a vulnerability and does not get scanned for virus. John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Colbeck, Andrew > Sent: Saturday, May 28, 2005 5:58 PM > To: Declude.Virus@declude.com > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > ... that's reasonable, John. > > How does it work up to now? If a vulnerability and a virus are > detected, which gets reported? > > Andrew 8) > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff > (Lists) > Sent: Saturday, May 28, 2005 5:17 PM > To: Declude.Virus@declude.com > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > I agree with Darrell. If it contains a virus, I want it to be marked > as a virus. If it does not contain a virus, then if it contains a > vulnerability or banned extension then mark as such. > > An example is that some Sober viruses also contain vulnerability. > Well, I want it labeled as a virus not vulnerability. > > John T > eServices For You > > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > On Behalf Of Darrell ([EMAIL PROTECTED]) > > Sent: Saturday, May 28, 2005 10:10 AM > > To: Declude.Virus@declude.com > > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > > > My thoughts are this - a virus is a virus and a vulnerability is a > > vulnerability. My expectation is that if a virus is detected than > > the > other > > scanners will not be called. However, if a vulnerability is > > detected the scanners will execute until such time a "virus" is > > found. > > > > Maybe two switches - EXITSCANONVULNERABILITY... > > > > However, on the grander scale of things if nothing changed on this I > > would still use EXITSCANONVIRUS as long as it observes the various > > delivery options on vulnerabilities. > > > > Darrell > > > > --- > > invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the > > default configuration. Download a copy today - > > http://www.invariantsystems.com > > > > > > - Original Message - > > From: "Colbeck, Andrew" <[EMAIL PROTECTED]> > > To: > > Sent: Saturday, May 28, 2005 12:49 PM > > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > > > > John, can you expand on that? > > > > In my implementation, there is no difference in message treatment if > > a > > > vulnerability or virus is detected. Therefore, I am happy to stop > > the > > > virus scanning if a vulnerability is detected. That is, as long as > > ALLOWVULNERABILITIESFROM is still respected. > > > > Of course, I've already found that these two had too many false > > positives for the safety they afford, so I've turned them off: > > > > BANPARTIAL OFF > > BANCRVIRUSES OFF > > > > which leaves me with > > > > BANCLSID ON > > > > which has never been triggered. > > > > Andrew 8) > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of John > > Tolmachoff > > (Lists) > > Sent: Saturday, May 28, 2005 12:34 AM > > To: Declude.Virus@declude.com > > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > > > > Well, here is an example of what I was hoping not to see. > > > > 05/27/2005 23:35:14 Q112105DF2AB2 Vulnerability flags = 0 > > 05/27/2005 23:35:14 Q112105DF2AB2 Outlook 'CR' vulnerability > > [Subject: H] in line 15 05/27/2005 23:35:15 Q112105DF2AB2 Virus > > scanner 1 reports exit code of 0 05/27/2005 23:35:15 > > Q112105DF2AB2 > > > File(s) are INFECTED [[Outlook 'CR' > > Vulnerability]: 0] > > 05/27/2005 23:35:36 Q112105DF2AB2 Scanned: CONTAINS A VIRUS > > 05/27/2005 23:35:36 Q112105DF2AB2 From: > > [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] [incoming from x.x.x.x] 05/27/2005 > > 23:35:36 Q112105DF2AB2 Subject: How is Rebecca do
RE: [Declude.Virus] EXITSCANONVIRUS
It appears to be stopping when it finds a vulnerability and does not get scanned for virus. John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Colbeck, Andrew > Sent: Saturday, May 28, 2005 5:58 PM > To: Declude.Virus@declude.com > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > ... that's reasonable, John. > > How does it work up to now? If a vulnerability and a virus are > detected, which gets reported? > > Andrew 8) > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff > (Lists) > Sent: Saturday, May 28, 2005 5:17 PM > To: Declude.Virus@declude.com > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > I agree with Darrell. If it contains a virus, I want it to be marked as > a virus. If it does not contain a virus, then if it contains a > vulnerability or banned extension then mark as such. > > An example is that some Sober viruses also contain vulnerability. Well, > I want it labeled as a virus not vulnerability. > > John T > eServices For You > > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > On Behalf Of Darrell ([EMAIL PROTECTED]) > > Sent: Saturday, May 28, 2005 10:10 AM > > To: Declude.Virus@declude.com > > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > > > My thoughts are this - a virus is a virus and a vulnerability is a > > vulnerability. My expectation is that if a virus is detected than the > other > > scanners will not be called. However, if a vulnerability is detected > > the scanners will execute until such time a "virus" is found. > > > > Maybe two switches - EXITSCANONVULNERABILITY... > > > > However, on the grander scale of things if nothing changed on this I > > would still use EXITSCANONVIRUS as long as it observes the various > > delivery options on vulnerabilities. > > > > Darrell > > > > --- > > invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the > > default configuration. Download a copy today - > > http://www.invariantsystems.com > > > > > > - Original Message - > > From: "Colbeck, Andrew" <[EMAIL PROTECTED]> > > To: > > Sent: Saturday, May 28, 2005 12:49 PM > > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > > > > John, can you expand on that? > > > > In my implementation, there is no difference in message treatment if a > > > vulnerability or virus is detected. Therefore, I am happy to stop the > > > virus scanning if a vulnerability is detected. That is, as long as > > ALLOWVULNERABILITIESFROM is still respected. > > > > Of course, I've already found that these two had too many false > > positives for the safety they afford, so I've turned them off: > > > > BANPARTIAL OFF > > BANCRVIRUSES OFF > > > > which leaves me with > > > > BANCLSID ON > > > > which has never been triggered. > > > > Andrew 8) > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff > > (Lists) > > Sent: Saturday, May 28, 2005 12:34 AM > > To: Declude.Virus@declude.com > > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > > > > Well, here is an example of what I was hoping not to see. > > > > 05/27/2005 23:35:14 Q112105DF2AB2 Vulnerability flags = 0 > > 05/27/2005 23:35:14 Q112105DF2AB2 Outlook 'CR' vulnerability > > [Subject: H] in line 15 05/27/2005 23:35:15 Q112105DF2AB2 Virus > > scanner 1 reports exit code of 0 05/27/2005 23:35:15 Q112105DF2AB2 > > > File(s) are INFECTED [[Outlook 'CR' > > Vulnerability]: 0] > > 05/27/2005 23:35:36 Q112105DF2AB2 Scanned: CONTAINS A VIRUS > > 05/27/2005 23:35:36 Q112105DF2AB2 From: > > [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] [incoming from x.x.x.x] 05/27/2005 > > 23:35:36 Q112105DF2AB2 Subject: How is Rebecca doing? > > > > In this case, the subject line is the last line for the message in the > > > Declude Virus log in HIGH and it apparently shows that scanners 2 & 3 > > were not called. If it finds a vulnerability, it still should fire the > > > scanners to see if one of them finds an actual virus. > > > > John T > > eServices For You > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED]
RE: [Declude.Virus] EXITSCANONVIRUS
... that's reasonable, John. How does it work up to now? If a vulnerability and a virus are detected, which gets reported? Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, May 28, 2005 5:17 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS I agree with Darrell. If it contains a virus, I want it to be marked as a virus. If it does not contain a virus, then if it contains a vulnerability or banned extension then mark as such. An example is that some Sober viruses also contain vulnerability. Well, I want it labeled as a virus not vulnerability. John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Darrell ([EMAIL PROTECTED]) > Sent: Saturday, May 28, 2005 10:10 AM > To: Declude.Virus@declude.com > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > My thoughts are this - a virus is a virus and a vulnerability is a > vulnerability. My expectation is that if a virus is detected than the other > scanners will not be called. However, if a vulnerability is detected > the scanners will execute until such time a "virus" is found. > > Maybe two switches - EXITSCANONVULNERABILITY... > > However, on the grander scale of things if nothing changed on this I > would still use EXITSCANONVIRUS as long as it observes the various > delivery options on vulnerabilities. > > Darrell > > --- > invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the > default configuration. Download a copy today - > http://www.invariantsystems.com > > > - Original Message - > From: "Colbeck, Andrew" <[EMAIL PROTECTED]> > To: > Sent: Saturday, May 28, 2005 12:49 PM > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > John, can you expand on that? > > In my implementation, there is no difference in message treatment if a > vulnerability or virus is detected. Therefore, I am happy to stop the > virus scanning if a vulnerability is detected. That is, as long as > ALLOWVULNERABILITIESFROM is still respected. > > Of course, I've already found that these two had too many false > positives for the safety they afford, so I've turned them off: > > BANPARTIAL OFF > BANCRVIRUSES OFF > > which leaves me with > > BANCLSID ON > > which has never been triggered. > > Andrew 8) > > -----Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff > (Lists) > Sent: Saturday, May 28, 2005 12:34 AM > To: Declude.Virus@declude.com > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > Well, here is an example of what I was hoping not to see. > > 05/27/2005 23:35:14 Q112105DF2AB2 Vulnerability flags = 0 > 05/27/2005 23:35:14 Q112105DF2AB2 Outlook 'CR' vulnerability > [Subject: H] in line 15 05/27/2005 23:35:15 Q112105DF2AB2 Virus > scanner 1 reports exit code of 0 05/27/2005 23:35:15 Q112105DF2AB2 > File(s) are INFECTED [[Outlook 'CR' > Vulnerability]: 0] > 05/27/2005 23:35:36 Q112105DF2AB2 Scanned: CONTAINS A VIRUS > 05/27/2005 23:35:36 Q112105DF2AB2 From: > [EMAIL PROTECTED] > To: [EMAIL PROTECTED] [incoming from x.x.x.x] 05/27/2005 > 23:35:36 Q112105DF2AB2 Subject: How is Rebecca doing? > > In this case, the subject line is the last line for the message in the > Declude Virus log in HIGH and it apparently shows that scanners 2 & 3 > were not called. If it finds a vulnerability, it still should fire the > scanners to see if one of them finds an actual virus. > > John T > eServices For You > > > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > On Behalf Of David Franco-Rocha [ Declude ] > > Sent: Friday, May 27, 2005 7:21 AM > > To: Declude.Virus@declude.com > > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > > > John, > > > > There is a processing loop wherein all the scanners are called in > > succession. It is independent of vulnerability checking. This > > directive merely tells Declude to break out of the external virus > > scanner execution loop. If you use this directive to exit the > > scanning > > > loop on virus > detection > > and (1) you have 5 scanners listed in your cfg file and (2) a virus > > is > > > detected by the first scanner listed, then the effect is exactly the > > same > in > > processing as if you had a single scanner listed and a virus were > > detected by that single scanner
RE: [Declude.Virus] EXITSCANONVIRUS
I agree with Darrell. If it contains a virus, I want it to be marked as a virus. If it does not contain a virus, then if it contains a vulnerability or banned extension then mark as such. An example is that some Sober viruses also contain vulnerability. Well, I want it labeled as a virus not vulnerability. John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Darrell ([EMAIL PROTECTED]) > Sent: Saturday, May 28, 2005 10:10 AM > To: Declude.Virus@declude.com > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > My thoughts are this - a virus is a virus and a vulnerability is a > vulnerability. My expectation is that if a virus is detected than the other > scanners will not be called. However, if a vulnerability is detected the > scanners will execute until such time a "virus" is found. > > Maybe two switches - EXITSCANONVULNERABILITY... > > However, on the grander scale of things if nothing changed on this I would > still use EXITSCANONVIRUS as long as it observes the various delivery > options on vulnerabilities. > > Darrell > > --- > invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the default > configuration. Download a copy today - http://www.invariantsystems.com > > > - Original Message - > From: "Colbeck, Andrew" <[EMAIL PROTECTED]> > To: > Sent: Saturday, May 28, 2005 12:49 PM > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > John, can you expand on that? > > In my implementation, there is no difference in message treatment if a > vulnerability or virus is detected. Therefore, I am happy to stop the > virus scanning if a vulnerability is detected. That is, as long as > ALLOWVULNERABILITIESFROM is still respected. > > Of course, I've already found that these two had too many false > positives for the safety they afford, so I've turned them off: > > BANPARTIAL OFF > BANCRVIRUSES OFF > > which leaves me with > > BANCLSID ON > > which has never been triggered. > > Andrew 8) > > -Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff > (Lists) > Sent: Saturday, May 28, 2005 12:34 AM > To: Declude.Virus@declude.com > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > Well, here is an example of what I was hoping not to see. > > 05/27/2005 23:35:14 Q112105DF2AB2 Vulnerability flags = 0 05/27/2005 > 23:35:14 Q112105DF2AB2 Outlook 'CR' vulnerability [Subject: H] in > line 15 05/27/2005 23:35:15 Q112105DF2AB2 Virus scanner 1 reports > exit code of 0 05/27/2005 23:35:15 Q112105DF2AB2 File(s) are > INFECTED [[Outlook 'CR' > Vulnerability]: 0] > 05/27/2005 23:35:36 Q112105DF2AB2 Scanned: CONTAINS A VIRUS > 05/27/2005 23:35:36 Q112105DF2AB2 From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] [incoming from x.x.x.x] 05/27/2005 > 23:35:36 Q112105DF2AB2 Subject: How is Rebecca doing? > > In this case, the subject line is the last line for the message in the > Declude Virus log in HIGH and it apparently shows that scanners 2 & 3 > were not called. If it finds a vulnerability, it still should fire the > scanners to see if one of them finds an actual virus. > > John T > eServices For You > > > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > On Behalf Of David Franco-Rocha [ Declude ] > > Sent: Friday, May 27, 2005 7:21 AM > > To: Declude.Virus@declude.com > > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > > > John, > > > > There is a processing loop wherein all the scanners are called in > > succession. It is independent of vulnerability checking. This > > directive merely tells Declude to break out of the external virus > > scanner execution loop. If you use this directive to exit the scanning > > > loop on virus > detection > > and (1) you have 5 scanners listed in your cfg file and (2) a virus is > > > detected by the first scanner listed, then the effect is exactly the > > same > in > > processing as if you had a single scanner listed and a virus were > > detected by that single scanner. > > > > David Franco-Rocha > > Declude Technical Support > > > > - Original Message - > > From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> > > To: > > Sent: Friday, May 27, 2005 2:50 AM > > Subject: [Declude.Virus] EXITSCANONVIRUS > > > > > > A question about this new feature. > > > > Am I correct in thinkin
Re: [Declude.Virus] EXITSCANONVIRUS
My thoughts are this - a virus is a virus and a vulnerability is a vulnerability. My expectation is that if a virus is detected than the other scanners will not be called. However, if a vulnerability is detected the scanners will execute until such time a "virus" is found. Maybe two switches - EXITSCANONVULNERABILITY... However, on the grander scale of things if nothing changed on this I would still use EXITSCANONVIRUS as long as it observes the various delivery options on vulnerabilities. Darrell --- invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the default configuration. Download a copy today - http://www.invariantsystems.com - Original Message - From: "Colbeck, Andrew" <[EMAIL PROTECTED]> To: Sent: Saturday, May 28, 2005 12:49 PM Subject: RE: [Declude.Virus] EXITSCANONVIRUS John, can you expand on that? In my implementation, there is no difference in message treatment if a vulnerability or virus is detected. Therefore, I am happy to stop the virus scanning if a vulnerability is detected. That is, as long as ALLOWVULNERABILITIESFROM is still respected. Of course, I've already found that these two had too many false positives for the safety they afford, so I've turned them off: BANPARTIAL OFF BANCRVIRUSES OFF which leaves me with BANCLSID ON which has never been triggered. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, May 28, 2005 12:34 AM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS Well, here is an example of what I was hoping not to see. 05/27/2005 23:35:14 Q112105DF2AB2 Vulnerability flags = 0 05/27/2005 23:35:14 Q112105DF2AB2 Outlook 'CR' vulnerability [Subject: H] in line 15 05/27/2005 23:35:15 Q112105DF2AB2 Virus scanner 1 reports exit code of 0 05/27/2005 23:35:15 Q112105DF2AB2 File(s) are INFECTED [[Outlook 'CR' Vulnerability]: 0] 05/27/2005 23:35:36 Q112105DF2AB2 Scanned: CONTAINS A VIRUS 05/27/2005 23:35:36 Q112105DF2AB2 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] [incoming from x.x.x.x] 05/27/2005 23:35:36 Q112105DF2AB2 Subject: How is Rebecca doing? In this case, the subject line is the last line for the message in the Declude Virus log in HIGH and it apparently shows that scanners 2 & 3 were not called. If it finds a vulnerability, it still should fire the scanners to see if one of them finds an actual virus. John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of David Franco-Rocha [ Declude ] > Sent: Friday, May 27, 2005 7:21 AM > To: Declude.Virus@declude.com > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > John, > > There is a processing loop wherein all the scanners are called in > succession. It is independent of vulnerability checking. This > directive merely tells Declude to break out of the external virus > scanner execution loop. If you use this directive to exit the scanning > loop on virus detection > and (1) you have 5 scanners listed in your cfg file and (2) a virus is > detected by the first scanner listed, then the effect is exactly the > same in > processing as if you had a single scanner listed and a virus were > detected by that single scanner. > > David Franco-Rocha > Declude Technical Support > > - Original Message - > From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> > To: > Sent: Friday, May 27, 2005 2:50 AM > Subject: [Declude.Virus] EXITSCANONVIRUS > > > A question about this new feature. > > Am I correct in thinking that as soon as a scanner reports a virus, > the next > scanner(s) in line will not be called and the message will be > processed accordingly, and that it will not be affected by Declude > first finding a banned attachment before having it scanned by a > scanner? > > John T > eServices For You > > > > --- > This E-mail came from the Declude.Virus mailing list. To unsubscribe, > just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. > > --- > This E-mail came from the Declude.Virus mailing list. To unsubscribe, > just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PR
RE: [Declude.Virus] EXITSCANONVIRUS
John, can you expand on that? In my implementation, there is no difference in message treatment if a vulnerability or virus is detected. Therefore, I am happy to stop the virus scanning if a vulnerability is detected. That is, as long as ALLOWVULNERABILITIESFROM is still respected. Of course, I've already found that these two had too many false positives for the safety they afford, so I've turned them off: BANPARTIAL OFF BANCRVIRUSES OFF which leaves me with BANCLSID ON which has never been triggered. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, May 28, 2005 12:34 AM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS Well, here is an example of what I was hoping not to see. 05/27/2005 23:35:14 Q112105DF2AB2 Vulnerability flags = 0 05/27/2005 23:35:14 Q112105DF2AB2 Outlook 'CR' vulnerability [Subject: H] in line 15 05/27/2005 23:35:15 Q112105DF2AB2 Virus scanner 1 reports exit code of 0 05/27/2005 23:35:15 Q112105DF2AB2 File(s) are INFECTED [[Outlook 'CR' Vulnerability]: 0] 05/27/2005 23:35:36 Q112105DF2AB2 Scanned: CONTAINS A VIRUS 05/27/2005 23:35:36 Q112105DF2AB2 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] [incoming from x.x.x.x] 05/27/2005 23:35:36 Q112105DF2AB2 Subject: How is Rebecca doing? In this case, the subject line is the last line for the message in the Declude Virus log in HIGH and it apparently shows that scanners 2 & 3 were not called. If it finds a vulnerability, it still should fire the scanners to see if one of them finds an actual virus. John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of David Franco-Rocha [ Declude ] > Sent: Friday, May 27, 2005 7:21 AM > To: Declude.Virus@declude.com > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > John, > > There is a processing loop wherein all the scanners are called in > succession. It is independent of vulnerability checking. This > directive merely tells Declude to break out of the external virus > scanner execution loop. If you use this directive to exit the scanning > loop on virus detection > and (1) you have 5 scanners listed in your cfg file and (2) a virus is > detected by the first scanner listed, then the effect is exactly the > same in > processing as if you had a single scanner listed and a virus were > detected by that single scanner. > > David Franco-Rocha > Declude Technical Support > > - Original Message - > From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> > To: > Sent: Friday, May 27, 2005 2:50 AM > Subject: [Declude.Virus] EXITSCANONVIRUS > > > A question about this new feature. > > Am I correct in thinking that as soon as a scanner reports a virus, > the next > scanner(s) in line will not be called and the message will be > processed accordingly, and that it will not be affected by Declude > first finding a banned attachment before having it scanned by a > scanner? > > John T > eServices For You > > > > --- > This E-mail came from the Declude.Virus mailing list. To unsubscribe, > just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. > > --- > This E-mail came from the Declude.Virus mailing list. To unsubscribe, > just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com.
RE: [Declude.Virus] EXITSCANONVIRUS
Well, here is an example of what I was hoping not to see. 05/27/2005 23:35:14 Q112105DF2AB2 Vulnerability flags = 0 05/27/2005 23:35:14 Q112105DF2AB2 Outlook 'CR' vulnerability [Subject: H] in line 15 05/27/2005 23:35:15 Q112105DF2AB2 Virus scanner 1 reports exit code of 0 05/27/2005 23:35:15 Q112105DF2AB2 File(s) are INFECTED [[Outlook 'CR' Vulnerability]: 0] 05/27/2005 23:35:36 Q112105DF2AB2 Scanned: CONTAINS A VIRUS 05/27/2005 23:35:36 Q112105DF2AB2 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] [incoming from x.x.x.x] 05/27/2005 23:35:36 Q112105DF2AB2 Subject: How is Rebecca doing? In this case, the subject line is the last line for the message in the Declude Virus log in HIGH and it apparently shows that scanners 2 & 3 were not called. If it finds a vulnerability, it still should fire the scanners to see if one of them finds an actual virus. John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of David Franco-Rocha [ Declude ] > Sent: Friday, May 27, 2005 7:21 AM > To: Declude.Virus@declude.com > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > John, > > There is a processing loop wherein all the scanners are called in > succession. It is independent of vulnerability checking. This directive > merely tells Declude to break out of the external virus scanner execution > loop. If you use this directive to exit the scanning loop on virus detection > and (1) you have 5 scanners listed in your cfg file and (2) a virus is > detected by the first scanner listed, then the effect is exactly the same in > processing as if you had a single scanner listed and a virus were detected > by that single scanner. > > David Franco-Rocha > Declude Technical Support > > - Original Message - > From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> > To: > Sent: Friday, May 27, 2005 2:50 AM > Subject: [Declude.Virus] EXITSCANONVIRUS > > > A question about this new feature. > > Am I correct in thinking that as soon as a scanner reports a virus, the next > scanner(s) in line will not be called and the message will be processed > accordingly, and that it will not be affected by Declude first finding a > banned attachment before having it scanned by a scanner? > > John T > eServices For You > > > > --- > This E-mail came from the Declude.Virus mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. > > --- > This E-mail came from the Declude.Virus mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com.
RE: [Declude.Virus] EXITSCANONVIRUS
Thanks. John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of David Franco-Rocha [ Declude ] > Sent: Friday, May 27, 2005 8:33 AM > To: Declude.Virus@declude.com > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > John, > > This setting defaults to OFF, which is the way it has been historically. The > only setting it actually looks for is ON. If you omit the directive > completely from your virus.cfg file, it will be OFF. > > Please note that the actual directive is EXITSCANONVIRUSDETECT ON > > David Franco-Rocha > Declude Technical Support > > - Original Message - > From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> > To: > Sent: Friday, May 27, 2005 11:17 AM > Subject: RE: [Declude.Virus] EXITSCANONVIRUS > > > Thanks. Is this a configurable meaning we have to have either ON or OFF? > > John T > eServices For You > > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > On Behalf Of David Franco-Rocha [ Declude ] > > Sent: Friday, May 27, 2005 7:21 AM > > To: Declude.Virus@declude.com > > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > > > John, > > > > There is a processing loop wherein all the scanners are called in > > succession. It is independent of vulnerability checking. This directive > > merely tells Declude to break out of the external virus scanner execution > > loop. If you use this directive to exit the scanning loop on virus > detection > > and (1) you have 5 scanners listed in your cfg file and (2) a virus is > > detected by the first scanner listed, then the effect is exactly the same > in > > processing as if you had a single scanner listed and a virus were detected > > by that single scanner. > > > > David Franco-Rocha > > Declude Technical Support > > > > - Original Message - > > From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> > > To: > > Sent: Friday, May 27, 2005 2:50 AM > > Subject: [Declude.Virus] EXITSCANONVIRUS > > > > > > A question about this new feature. > > > > Am I correct in thinking that as soon as a scanner reports a virus, the > next > > scanner(s) in line will not be called and the message will be processed > > accordingly, and that it will not be affected by Declude first finding a > > banned attachment before having it scanned by a scanner? > > > > John T > > eServices For You > > > > > > > > --- > > This E-mail came from the Declude.Virus mailing list. To > > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > > type "unsubscribe Declude.Virus".The archives can be found > > at http://www.mail-archive.com. > > > > --- > > This E-mail came from the Declude.Virus mailing list. To > > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > > type "unsubscribe Declude.Virus".The archives can be found > > at http://www.mail-archive.com. > > --- > This E-mail came from the Declude.Virus mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. > > --- > This E-mail came from the Declude.Virus mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com.
Re: [Declude.Virus] EXITSCANONVIRUS
John, This setting defaults to OFF, which is the way it has been historically. The only setting it actually looks for is ON. If you omit the directive completely from your virus.cfg file, it will be OFF. Please note that the actual directive is EXITSCANONVIRUSDETECT ON David Franco-Rocha Declude Technical Support - Original Message - From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> To: Sent: Friday, May 27, 2005 11:17 AM Subject: RE: [Declude.Virus] EXITSCANONVIRUS Thanks. Is this a configurable meaning we have to have either ON or OFF? John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Franco-Rocha [ Declude ] Sent: Friday, May 27, 2005 7:21 AM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS John, There is a processing loop wherein all the scanners are called in succession. It is independent of vulnerability checking. This directive merely tells Declude to break out of the external virus scanner execution loop. If you use this directive to exit the scanning loop on virus detection and (1) you have 5 scanners listed in your cfg file and (2) a virus is detected by the first scanner listed, then the effect is exactly the same in processing as if you had a single scanner listed and a virus were detected by that single scanner. David Franco-Rocha Declude Technical Support - Original Message - From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> To: Sent: Friday, May 27, 2005 2:50 AM Subject: [Declude.Virus] EXITSCANONVIRUS A question about this new feature. Am I correct in thinking that as soon as a scanner reports a virus, the next scanner(s) in line will not be called and the message will be processed accordingly, and that it will not be affected by Declude first finding a banned attachment before having it scanned by a scanner? John T eServices For You --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com.
RE: [Declude.Virus] EXITSCANONVIRUS
Release notes indicate default is off. To use it, use: EXITSCANONVIRUSDETECT ON John C -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, May 27, 2005 10:18 AM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS Thanks. Is this a configurable meaning we have to have either ON or OFF? John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of David Franco-Rocha [ Declude ] > Sent: Friday, May 27, 2005 7:21 AM > To: Declude.Virus@declude.com > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > John, > > There is a processing loop wherein all the scanners are called in > succession. It is independent of vulnerability checking. This > directive merely tells Declude to break out of the external virus > scanner execution loop. If you use this directive to exit the scanning > loop on virus detection > and (1) you have 5 scanners listed in your cfg file and (2) a virus is > detected by the first scanner listed, then the effect is exactly the > same in > processing as if you had a single scanner listed and a virus were > detected by that single scanner. > > David Franco-Rocha > Declude Technical Support > > - Original Message - > From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> > To: > Sent: Friday, May 27, 2005 2:50 AM > Subject: [Declude.Virus] EXITSCANONVIRUS > > > A question about this new feature. > > Am I correct in thinking that as soon as a scanner reports a virus, > the next > scanner(s) in line will not be called and the message will be > processed accordingly, and that it will not be affected by Declude > first finding a banned attachment before having it scanned by a scanner? > > John T > eServices For You > > > > --- > This E-mail came from the Declude.Virus mailing list. To unsubscribe, > just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. > > --- > This E-mail came from the Declude.Virus mailing list. To unsubscribe, > just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com.
RE: [Declude.Virus] EXITSCANONVIRUS
Thanks. Is this a configurable meaning we have to have either ON or OFF? John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of David Franco-Rocha [ Declude ] > Sent: Friday, May 27, 2005 7:21 AM > To: Declude.Virus@declude.com > Subject: Re: [Declude.Virus] EXITSCANONVIRUS > > John, > > There is a processing loop wherein all the scanners are called in > succession. It is independent of vulnerability checking. This directive > merely tells Declude to break out of the external virus scanner execution > loop. If you use this directive to exit the scanning loop on virus detection > and (1) you have 5 scanners listed in your cfg file and (2) a virus is > detected by the first scanner listed, then the effect is exactly the same in > processing as if you had a single scanner listed and a virus were detected > by that single scanner. > > David Franco-Rocha > Declude Technical Support > > - Original Message - > From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> > To: > Sent: Friday, May 27, 2005 2:50 AM > Subject: [Declude.Virus] EXITSCANONVIRUS > > > A question about this new feature. > > Am I correct in thinking that as soon as a scanner reports a virus, the next > scanner(s) in line will not be called and the message will be processed > accordingly, and that it will not be affected by Declude first finding a > banned attachment before having it scanned by a scanner? > > John T > eServices For You > > > > --- > This E-mail came from the Declude.Virus mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. > > --- > This E-mail came from the Declude.Virus mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.Virus".The archives can be found > at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com.
Re: [Declude.Virus] EXITSCANONVIRUS
John, There is a processing loop wherein all the scanners are called in succession. It is independent of vulnerability checking. This directive merely tells Declude to break out of the external virus scanner execution loop. If you use this directive to exit the scanning loop on virus detection and (1) you have 5 scanners listed in your cfg file and (2) a virus is detected by the first scanner listed, then the effect is exactly the same in processing as if you had a single scanner listed and a virus were detected by that single scanner. David Franco-Rocha Declude Technical Support - Original Message - From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> To: Sent: Friday, May 27, 2005 2:50 AM Subject: [Declude.Virus] EXITSCANONVIRUS A question about this new feature. Am I correct in thinking that as soon as a scanner reports a virus, the next scanner(s) in line will not be called and the message will be processed accordingly, and that it will not be affected by Declude first finding a banned attachment before having it scanned by a scanner? John T eServices For You --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus".The archives can be found at http://www.mail-archive.com.
