SIEVE Email Filtering: Spamtest and VirusTest Extensions
RFC 3685

Some concerns were raised by the IESG as to extensibility
tradeoffs this provides -- is the specific set of
virustest too specific and/or is the ability to test
arbitary strings added by different applications to
general. Only time will tell -- if this turns out to
be busted a recycle at proposed may be in order.

[Ballot comment]
I consider shipping this stuff at Proposed now to be a Good Thing.
Recycling if we get it slightly wrong (or need to split the spamstuff from the virusstuff) is not severely hampered by publishing at Proposed now.

[Ballot discuss]
I'm wondering if this might not be an extension we suggest spend some time as
an Experimental, with a date for return as Proposed or for further revision.  I'm
concerned that we are doing a couple of different things here:  including spamtest
and virustest in one document (useful, but makes it difficult to adjust later if
we got one wrong).  This is driven not so much by concerns like "why is one 5 and one
10", but by the associations of specific values with specific actions.  The Virustest
actions are:


0          message was not tested for viruses
1          message was tested and contains no known viruses
2          message was tested and contained a known virus which
            was replaced with harmless content
3          message was tested and contained a known virus which
            was "cured" such that it is now harmless
4          message was tested and possibly contains a known virus
5          message was tested and definately contains a known virus

I can easily think of other actions, some of which might be considered side
effects and some of which are primary (e.g. and the individual/postmaster of the site
from which the mail arrived has been warned; using this as a trigger to check
for updated virus definitions, etc.).  By limiting the output to these 6 and
without including a further extension mechanism, we may be
overly limiting this.

Did the mailing list consider other formats, etc?  Was there a lot of discussion on this?

[Ballot discuss]
I'm wondering if this might not be an extension we suggest spend some time as
an Experimental, with a date for return as Proposed or for further revision.  I'm
concerned that we are doing a couple of different things here:  including spamtest
and virustest in one document (useful, but makes it difficult to adjust later if
we got one wrong).  This is driven not so much by concerns like "why is one 5 and one
10", but by the associations of specific values with specific actions.  The Virustest
actions are:


0          message was not tested for viruses
1          message was tested and contains no known viruses
2          message was tested and contained a known virus which
            was replaced with harmless content
3          message was tested and contained a known virus which
            was "cured" such that it is now harmless
4          message was tested and possibly contains a known virus
5          message was tested and definately contains a known virus

I can easily think of other actions, some of which might be considered side
effects and some of which are primary (e.g. and the individual/postmaster of the site
from which the mail arrived has been warned; using this as a trigger to check
for updated virus definitions, etc.).  By limiting the output to these 5 and
without including a further extension mechanism, we may be
overly limiting this.

Did the mailing list consider other formats, etc?  Was there a lot of discussion on this?

New version addresses all major open issues; document
is now ready for IETF last call. Some small items still
need to be fixed:

Title needs to be changed to "SIEVE Email Filtering: Spamtest and VirusTest Extensions"

There's a bracket out of alignment in the example in section 3.3

Section 3.3 again: "definately" -> "definitely"

There are a few draft nits that will need to be addressed with a revised
version:

(1) The document lacks the required IPR boilerplate. The IESG has recently
    started pushing back on this.

(2) The change history section needs to be marked "to be removed prior
    to publication as an RFC".

(3) The abstract should refer to the "sieve mail filtering language" rather
    than just "sieve", in order to better put the document in context.

(4) The conventions section should be moved so it appears after the
    introduction and overview.

(5) The abstract should not be numbered.

Sieve meeting 19-Mar-2002: Decided to change draft
so spamtest/virustest information has rating number at
the start but may have additional text following. This
can be used to provide things like the list of rules that
fired, the virus that was found, etc. Once this is added
the document should be ready for last call