hi,
while running some tests with clamassassin i noticed inconsistencies between
mailscanning with clamscan and clamdscan.
test subject is a Worm.Klez.H infected mail extracted from a
well-known-and-hated mua (and then modified by different scripts, formail,
procmail etc. for internal testcases). i'll paste the output of three of
those variants, which only differ in the first two lines of the mail:
# head -n 2 case1.eml
Return-Path: <[EMAIL PROTECTED]>
Received: from somedomain.de (someotherdomain.de [IP])
# head -n 2 case2.eml
X-POP3-Rcpt: [EMAIL PROTECTED]
Return-Path: <[EMAIL PROTECTED]>
# head -n 2 case3.eml
>From [EMAIL PROTECTED] Sun Aug 1 17:21:32 2004
X-POP3-Rcpt: [EMAIL PROTECTED]
clamscan behaves "correct" on all three files:
# clamscan --disable-summary --mbox - <case1.eml
/tmp/clamav-a3e524d40c4f2dba/textportionDcDSTi: OK
/tmp/clamav-a3e524d40c4f2dba/src.scrQUgYQD: Worm.Klez.H FOUND
/tmp/clamav-a3e524d40c4f2dba/i-3_T[3].jpgCkt7NY: OK
# (same for case2.eml and case3.eml, with other tmpdir of course)
while clamdscan (ScanMail in clamav.conf is set) produces the following:
# clamdscan --disable-summary - <case1.eml
stream: Worm.Klez.H FOUND
# clamdscan --disable-summary - <case2.eml
stream: OK
# clamdscan --disable-summary - <case3.eml
stream: Worm.Klez.H FOUND
Note that in case2 (the first line of stdin is X-POP3-Rcpt:, and it does the
same with any custom mail header line) the infection is not detected, and
there is no sign indicating that scanning of stdin was not successfull or
there was malformatted input. Its also not an issue of "streaming":
# clamdscan --disable-summary case2.eml
/root/devel/test/case2.eml: OK
# clamdscan --disable-summary case3.eml
/root/devel/test/case3.eml: Worm.Klez.H FOUND
This leaves some bad feelings, although this slighty "malformatted" mails
are unlikely to appear in the productive enviromnet (but i do not want to
take that for granted)
I am aware that for example just piping the mail through formail before
passing it to clamdscan is a workaround for the above scenario, but I
plan to use clamdscan in different environments, some of them not allowing
me to do such "preparations". Another usecase is quick
command-line-verification where in-depth validation of a mail-like input
file is surely not what i want to do after every OK clamdscan gives me.
So my questions are:
1) what is the difference in mail/mbox-handling in clamscan and clamdscan?
2) which algorithm is used to "identify" a mail in clamdscan? and does this
depend on third party software, e.g. some libs on the host system?
3) is there a way to force clamd/clamdscan to expect mailfiles and report a
failure if the input stream was not identified and parsed as mail?
4) are there simple tweaks to assure clam(d)scan handles the input as a
single mail rather than just "anything" from no-mail-at-all to mbox
containing multiple mails?
5) or is that, after all, kinda bug? ;)
sincerly,
martin koniczek
(test system: ClamAV version 0.75.1 on crux 1.3, 2.4.24 SMP on i686)
(mailfiles: http://clamssh.yawsp.de/void/20040801cases.tar.gz)
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Clamav-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/clamav-users
