Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 42378 invoked from network); 22 Mar 2004 14:34:16 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 22 Mar 2004 14:34:16 -0000 Received: (qmail 17228 invoked by uid 500); 22 Mar 2004 14:34:08 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 17177 invoked by uid 500); 22 Mar 2004 14:34:07 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 17156 invoked from network); 22 Mar 2004 14:34:07 -0000 Received: from unknown (HELO exchange.sun.com) (192.18.33.10) by daedalus.apache.org with SMTP; 22 Mar 2004 14:34:07 -0000 Received: (qmail 14029 invoked by uid 50); 22 Mar 2004 14:34:42 -0000 Date: 22 Mar 2004 14:34:42 -0000 Message-ID: <20040322143442.14028.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 27193] - Documentation: illustrate how to integrate virus control X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27193 Documentation: illustrate how to integrate virus control ------- Additional Comments From Brian.Ewins@btinternet.com 2004-03-22 14:34 ------- We use the common ability of virus scanners to quarantine infected files immediately after they are written, as a minimal level of integration. Introducing a slight delay in processing the files is enough to ensure that they have been scanned. Our customers have various virus scanners and this has worked for all of them. Of course, this isn't ideal, as if the scanner is off, or slow, the file will still be there next time you look. Using on-demand scanning is slightly better as you'll never get data from the file until after the scanner has kicked in. To test this mechanism, use the eicar test files. http://www.eicar.org/anti_virus_test_file.htm For a more complete solution, AV vendors seem to be aligning around ICAP (http://www.i-cap.org/spec/rfc3507.txt) as a way of plugging in to HTTP servers. ICAP modifies HTTP requests/responses, so you'd have a proxy that used ICAP to talk to an enterprise AV product. Notification appears in headers of the modified request, see: http://www.i-cap.org/spec/draft-stecher-icap-subid-00.txt So you MAY get an 'X-Infection-Found' header if there's a virus; ie what the header /actually/ is may vary from vendor to vendor, but you should see something. Hence, with ICAP available, best practice would be to test for the presence of a configurable infection-flagging header prior to parsing the file upload. Of course you wouldn't have been able to figure that out from the ICAP forum's wonderfully opaque and probably autogenerated 'about' page: http://www.i-cap.org/about/ ... (is this a joke?) --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org