ietf-mta-filters
[Top] [All Lists]

Re: "body" extension

2002-06-17 15:55:40

On Mon, 2002-06-17 at 09:16, Nigel Swinson wrote:
The most common usage seems to be as an attachment blocker.  And they have
to implement this by using all sorts of fancy regexes which very quickly
become a fairly sizable performance problem.  Which is what they are
beginning to moan about just now.  There are also folks trying to do some
spam filtering and then as a very early stage virus filter before the new
virus definitions are out.

To reduce the performance burden we were thinking of implementing :matches
for the x_body given that it is all they really need for their attachment
blocker, and then also implementing a mime test that I was hoping we'd all
design together so that we could get a standard for the syntax.  Glad to see
this discussion coming up now :o)

:matches can (and will) get fooled about what does and doesn't match--a
message describing the symptoms, or a email of a Sieve filter that
matches the offending messages, will probably trigger the filter.

Although it's a lot easier to implement O(n) :matches than O(n)
:regex...

I'm definitely in favor of trying to provide MIME filtering capabilities
(i.e., mimepart :filename :matches "*.vbs in particular, but also types,
etc.).  Doing this with x_body can cause problems and false positives. 
There are real horror stories to this.

I really like the idea of having arguments such as :raw or :mime that allow
implementations to "build up" the extension by just supporting :raw then
adding :mime and so forth.  Perhaps we should have arguments that describe
what cte decoding should be done too?

I suspect CTE decoding is all-or-nothing, and it's almost always all. 
Where I can see raw matching being more useful is matching against
headers.

Basically my problem with not decoding CTEs is that if you want to match
against a base64 string, you want the raw form because if the words
aren't quite aligned right, weirdness happens.

We could just document x_body as is.  There's nothing in Sieve that
documents the usual X- convention, but the folks who know what X- means
will get the convenient, unsettling feeling that they're playing with
fire at a gas station.

Tim



<Prev in Thread] Current Thread [Next in Thread>