[Mimedefang] RFC: better virus scanner status reporting?

[David F. Skoll]

On Wed, 13 Aug 2003, James Ralston wrote:

> If you have an idea of how you'd like to see this done, I'd be happy
> to implement it.

Stephane Lentz of Alcatel likes the way amavisd-new integrates
virus-scanners; take a look at
http://lists.roaringpenguin.com/pipermail/mimedefang/2002-November/003579.html

It's a table-driven approach with hooks for running Perl subroutines
for weird cases.

I've resisted changing the way MD integrates virus scanners for
three reasons, not all of them good. :-)

1) It's done the old way in CanIt, and it's a lot harder to break
backware-compatibility with commercial software than with free software.

2) I'm not convinced a table-driven approach is flexible enough.

3) I don't have access to any virus-scanners, so I have no way to test
changes.  I really do not want to break virus-scanning if it works now.

So, I'd like to state my design principles for virus-scanner integration
with MIMEDefang:

0) Whatever you do in your filter code is up to you.  Feel free to violate
any or all of the following principles.

1) We should not depend on scanning output messages for making important
decisions.  It's OK to try to extract a virus name by parsing messages;
it's not OK to make an infected/clean decision on that basis.  This is
because messages might change from version to version, or even depending
on your system's locale settings.

2) If a virus-scanner exit code is ambiguous (eg the Sophos case, where
2 could mean "encrypted" or something else), then we should make a note
of it and leave it up to the filter author to decide.

3) The actions returned by the *_contains_virus_* routines are merely
_suggestions_.  Owners of anti-virus software are encouraged to read
the documentation and make their decisions based on the exit code of
the software.

4) If I don't completely understand a problem, or I feel I can't predict
what will happen in the future, I like to leave it as open as possible,
which means letting filter-writers code their policy in Perl.

I think you see where this is leading. :-)  I would like to leave it
up to filter-writers to code their own policies in Perl.  However, for
unsophisticated users, I suggest we add README's (like README.SOPHOS)
describing the various exit codes and the tradeoffs that must be made.

How's that for passing the buck?

Regards,

David.