Hi,
--On Tim Showalter <tjs(_at_)mirapoint(_dot_)com> wrote:
| I'm not convinced Sieve is the right place to do virus scanning
I agree - most of the examples given for body filtering are down to the
need to do virus and spam filtering. I don't think the need for virus and
spam filtering alone should justify the presence of body.
What I would like to see are generic 'spamtest' and 'virustest' extensions
in sieve that would allow sieve implementations to take better advantage of
third-party tools in a transparent manner. For example, some spam tools
insert specific headers with the header content indicating the level of
spam. Right now you have to code a sieve script to recognise these headers
for each type of spam tool that you might use. A better approach, IMHO, is
to have a generic 'spamtest' command that returns a number in the range,
say, 0 to 10, that can be used to trigger an appropriate action.
The sieve implementation would determine exactly what spamtest does. In the
case of sieve sitting behind one of those spam tools, the spamtest command
would implicitly look for the relevant headers and have some form of
normalising those results into its 0..10 range. If a sieve implementation
had a spam detection system builtin, it could utilise that directly.
The benefit of this is that you don't have to keep rewriting scripts for
different kinds of spam or virus tools that may be in use - each sieve
implementation would deal with the specifics of the spam/virus tool itself,
hiding complexity from the end user. If a user really wanted a lower level
of control, they would be free to not use spamtest, and instead do the
header/body tests directly.
--
Cyrus Daboo