headers
Richard Lyons | 1 Mar 2005 01:27
Picon

Re: Re: Partial MIME support

On Fri, 2005-02-25 at 17:18 -0500, John Peacock wrote:

> The whole point is to avoid rewriting the file (for performance 
> reasons).  To recap, I am trying to integrate clamd into an MTA 
> (qpsmtpd) and I already have a file which contains only the body of the 
> message, so if I can scan that without rewriting, it means the SMTP 
> transaction takes less time.

I went through a similar optimisation process with our qmail install
a little while ago.  We use qmail-qfilter, which stores the entire
message on disk before calling the list of filters with the file
descriptor of the message.  I patched clamd (subsequently accepted
into the codebase) to accept a file descriptor for scanning.  We run
other filters over the message, so the cost of having qmail-qfilter 
writing the file to disk is amortised over the filters.  I know this
is not helpful to your plan to integrate into qpsmtpd, but if you
use qmail-qfilter for other reasons you might consider moving your
virus scanning down the chain.

Rick.

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 1 comment |
headers
Richard Lyons | 1 Mar 2005 01:41
Picon

Re: MIME header processing glitch

On Fri, 2005-02-25 at 15:20 +0000, Nigel Horne wrote:

> > The sample you sent had no virus in it so I can't substatiate this claim.
> > Since I have no virus to test against I am unwary about making 

I haven't actually received a virus with sort of boundary, I was just
running clamav over some messages and noticed that it was emitting
the following:

LibClamAV Warning: Ignoring empty field in " boundary="
LibClamAV Warning: Multipart MIME message contains no boundaries

My concern was that clamav would pass messages with what it thought
was malformed MIME headers to clients that would treat them as valid,
thereby providing a method for VXers to circumvent clamav checking.
As it turns out, I was incorrect.

> I notice that the boundaries don't have quotes around the bracketed bit.

The boundaries don't, the boundary definition does:

...
Content-Transfer-Encoding: 7bit
Content-Type: multipart/mixed; boundary="(AlternativeBoundary)"
...
--(AlternativeBoundary)
Content-Type: multipart/alternative; boundary="(AlternativeBoundary2)"

I you didn't receive the text as formatted above, perhaps an
intermediate MSA/MTA/MUA has reformatted the message.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tomasz Kojm | 1 Mar 2005 01:48
Favicon

Re: suggestion: adding ClamAV version info to SCAN SUMMARY

On Mon, 28 Feb 2005 08:15:18 +0100
Robert Allerstorfer <roal <at> anet.at> wrote:

> Hi,
> 
> I would find it comfortable to not only have the number of Known
> viruses in the SCAN SUMMARY, but also some ClamAV version info.
> Currently, the output looks like this:
> 
> $ clamscan /home/roal/clam/clam_BZip2.zip
> /home/roal/clam/clam_BZip2.zip: Zip module failure
> /home/roal/clam/clam_BZip2.zip: OK
> 
> ----------- SCAN SUMMARY -----------
> Known viruses: 31277
> Scanned directories: 0
> Scanned files: 1
> Infected files: 0
> Data scanned: 0.00 MB
> I/O buffer size: 131072 bytes
> Time: 0.508 sec (0 m 0 s)
> 
> $ clamscan -V
> ClamAV 0.83/732/Sun Feb 27 10:51:18 2005
> 
> 
> Why not expanding the first line of the SCAN SUMMARY to somrthing like
> this:
> 
> Known viruses: 31277 (ClamAV 0.83/732)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jin Tao | 1 Mar 2005 07:24
Picon

something seemingly wrong in libClamAV\line.c

Hi all, 

Line 60 in libClamAV\Line.c  is  
"  line_t *ret = (line_t *)li_malloc(sizeof(struct line));  ",    which I
think should be " line_t *ret = (line_t *)cli_malloc(sizeof(struct line));  

Is that right?   I don't know what "li_malloc" means.

Thanks 

jintao
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 1 comment |
headers
Per Jessen | 1 Mar 2005 08:58
Picon
Favicon

Re: proposed patch - fork() instead of system() for OnError/UpdateExecute

Per Jessen wrote:

> 
> http://jessen.ch/files/patch-clamav-0.83-freshclam-with-fork2
> 

Any other comments - Tomasz maybe? 

/Per Jessen, Zürich

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 0 comments |
headers
Robert Allerstorfer | 1 Mar 2005 12:06
Picon
Favicon

Re: suggestion: adding ClamAV version info to SCAN SUMMARY

On Tue, 1 Mar 2005, 01:48 GMT+01 Tomasz Kojm wrote:

> I've added "Engine version" in CVS:

> ----------- SCAN SUMMARY -----------
> Known viruses: 31313
> Engine version: devel-20050301
> Scanned directories: 1
> Scanned files: 26
> Infected files: 0
> Data scanned: 0.40 MB
> Time: 1.861 sec (0 m 1 s)

> We can't/shouldn't add the database information because clamscan can be
> run with external databases of random formats (-d).

Thanks!

rob.

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 0 comments |
headers
Nigel Horne | 1 Mar 2005 12:31
Picon
Gravatar

Re: something seemingly wrong in libClamAV\line.c

On Tuesday 01 Mar 2005 06:24, Jin Tao wrote:

> Line 60 in libClamAV\Line.c  is  
> "  line_t *ret = (line_t *)li_malloc(sizeof(struct line));  ",    which I
> think should be " line_t *ret = (line_t *)cli_malloc(sizeof(struct line));  
> 
> Is that right?   I don't know what "li_malloc" means.

It means "this is a typo". Must be something called li_malloc somewhere.
Thanks for the keen eye, I'll fix it.

> jintao

--

-- 
Nigel Horne. Arranger, Composer, Typesetter.
NJH Music, Barnsley, UK.  ICQ#20252325
njh <at> despammed.com http://www.bandsman.co.uk
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 0 comments |
headers
John Peacock | 1 Mar 2005 13:01
Favicon

Re: Partial MIME support

Richard Lyons wrote:
> I went through a similar optimisation process with our qmail install
> a little while ago.  We use qmail-qfilter, which stores the entire
> message on disk before calling the list of filters with the file
> descriptor of the message.  I patched clamd (subsequently accepted
> into the codebase) to accept a file descriptor for scanning.

Thanks for the suggestion.  As it turns out, after discussion with the other 
qpsmtpd developers, I patched the core to write the entire in-coming message 
(headers and body) into a spool file, then noted the offset where the body 
itself started.  From that point, it is trivial to scan with clamd, and we can 
create a fresh header (with additional Received: line and any other X-headers) 
without rewriting the disk file when queuing the message for delivery.

I still think that it is suboptimal that the only public interface to libclamav 
requires you to go through the heuristics.  No matter how good those heuristics 
are (and I have no doubt they are *very* good), there is no reason to spend the 
time to execute them, _if the external system already knows what type of file is 
to be scanned_.  Sure, it's an edge case, but ignoring external information 
means more work has to be done than is strictly necessary.

John

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 0 comments |
headers
Laurent Wacrenier | 1 Mar 2005 13:43
Picon

Re: Re: proposed patch - fork() instead of system() for OnError/UpdateExecute

Le Ven 25 fév 15:03:51 2005, Per Jessen écrit:
> > - The system shell may not be /bin/sh everywhere.
> 
> system() uses /bin/sh -c on Linux - I wanted to keep the existing behaviour of system().

/bin/sh is a reasonable default, but you can't assert the system shell
is here. It may live in a lot of places like /bin/posix/sh, /usr/bin/sh
/usr/xpg4/bin/sh...
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 16 comments |
headers
Per Jessen | 1 Mar 2005 19:17
Picon
Favicon

Re: Re: proposed patch - fork() instead of system() for OnError/UpdateExecute

Laurent Wacrenier wrote:

> /bin/sh is a reasonable default, but you can't assert the system shell
> is here. It may live in a lot of places like /bin/posix/sh, /usr/bin/sh
> /usr/xpg4/bin/sh...

Fair enough.  
I'll use _PATH_BSHELL from <paths.h> instead - 

http://jessen.ch/files/patch-clamav-0.83-freshclam-with-fork3

/Per Jessen, Zürich

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Permalink | Reply | 15 comments |

Gmane