Sorry about the slow response - this got lost among other things, and I kind of forgot about it for a while :(
This one time, at band camp, Stephen Gran said: > This one time, at band camp, Antonio Fiol said: > > I am using clamd in STREAM mode in every case. > > > > I have found a way of fooling the scanner to give a false > > negative: > > > > If the user sends a BIG file (bigger than the limit) with a virus near > > the end (outside the limit), it will get cut, and the virus will not be > > found. > > > > IMO, the scanner should detect this as an exceptional situation, and > > react by saying: > > stream: ERROR:Size-limit-exceeded FOUND > > > > Or any other informative string. > > Upstream's response is that you should set your MTA limits for message > size to be the same as your settings for stream size, so that you can > just reject over size messages outright. Apparently that means they > don't want to accept your patch :( I think the misunderstanding here is that this is an option to limit the total size of a stream being scanned, so as not to allow a random connection to disk flood you (Streams are usually saved to disk, so this is a useful way of preventing disk full conditions). If you need to ensure that every byte of a file is scanned, use the SCAN or CONTSCAN command instead (perhaps save the stream to file first) or don't limit the stream size being scanned. This is not meant as a cut off for other systems that use clam as a backend. IOW, it is a back door safety trap to avoid over large files, rather than another virus detection option, like the Archive* options. Does that make it more clear? -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
pgpu0CWXVFBo2.pgp
Description: PGP signature
