Hi folks. Rockliffe's Mailsite has the "x_body" extension that keeps
getting mentioned in this thread. Here's how it works:
It matches exactly as Jutta's extension describes. regex is supported,
matches is not. No mime decoding, cte decoding, charset decoding no
nothing. Just plain simple character comparison. If fact, it takes the
utf-8 string from the Sieve script and compares against the body without
even removing the utf-8 encoding. :o/
So the syntax is:
x_body [COMPARATOR] [MATCH-TYPE] <key-list: string-list>
These comparators are supported: ["i;octet" | "i;ascii-casemap"]
These match types are supported: [:contains | :regex]
Mailsite supports Sieve scripts at the server, domain and mailbox level, but
I think that the x_body extension is most commonly used in the server level
scripts rather than at mailbox/domain level.
So yeah in many ways it's grubbier than a grubby thing. But still very
useful and heavily used by our customers. The fact that it is so heavily
used does imply that even at this "basic" level it's worth implementing, and
then leaving the decision of whether or not to take the performance hit up
to the customer.
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)
We called it "x_body" rather than "body" because we knew that eventually
there would be a body extension that we would want to support, and didn't
want to conflict with it. I agree with Tim in that the "body" keyword is
too valuable to polute with anything less than the real McCoy.
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?
Also tests that allow access to the size of an attachment, or the count of
the attachments would be useful too. Perhaps we are looking at a "mime"
test as well as a "body" test?
Here's some scribblings to ponder over...
body: [MIME-BODY-PART] [CONTENT-TRANSFER-DECODING]
[COMPARATOR] [MATCH-TYPE] <key-list: string-list>
CONTENT-TRANSFER-DECODING: ":none" ":all" / ":base64" / "quoted-printable"
MIME-BODY-PART: ":mime-header" [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
Now we could look for addresses in the headers of a body part
Syntax: address [MIME-BODY-PART] [ADDRESS-PART] [COMPARATOR]
[MATCH-TYPE]
<header-list: string-list> <key-list: string-list>
Or if a particular header exists in one of the body parts
Syntax: exists [MIME-BODY-PART] <header-names: string-list>
Or if a header contains a string in one of the body part headers
Syntax: header [MIME-BODY-PART] [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
The size of a body part matching a particular criteria.
Syntax: size [MIME-BODY-PART] <":over" / ":under"> <limit: number>
So if you do a body test with no mime-body-part selector, and a
content-transfer-decoding of :none, then you would end up with the x_body
that we have implemented.
Nigel