Subject: extensions and sieve

From: Paulo Sousa <[email-masked]>
Date: Mon, 3 Feb 2003 12:31:51 -0200 (BRST)

Hi

Anyone could help me? I need filter mails by extensions (.exe .vbs ....).
How i can do a rule to this?

Thanks

Paulo Sousa

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 3 Feb 2003 20:57:12 -0000

> How i can do a rule to this?

The Sieve spec doesn't natively support any kind of test on the content of
the message, only the headers, envelope and size of the message.  Sieve is
currently not MIME aware at all.

However some implementation have some kind of X_body test that allows you to
search against the body of the message, but it's all a bit of kludge.  It's
only really worthwhile if it's available in conjunction with the regex
extension, and even then it becomes extremely CPU intensive, and a problem
for the server.

The better solution is to wait for us to knock together some kind of mime
aware syntax that allows us to say "emails that contain attachments of type
X"...

Doing this with MailSite for example, involves following the advice found in
the following KB articles:
http://www.rockliffe.com/support/docs/html/1/00/10039.asp
http://www.rockliffe.com/support/docs/html/1/00/10078.asp

The KB articles describe how to enter the filters into the gui, but if you
click the "advanced" button then you get to see the Sieve it produces in all
it's glory.

BTW, this list is NOT designed to answer this kind of query... it's for
discussion and creation of new Sieve standards/specs.  Advice on this kind
of thing should be solicited from your mail server provider.

Cheers

Nigel

---

From: [email-masked]
Date: Mon, 03 Feb 2003 13:20:31 -0800 (PST)

> aware syntax that allows us to say "emails that contain attachments of type

In the meantime, note that for a message that is in MIME format, you can hope
that perhaps the filename will show up in a MIME header line.  For instance,
filenames are sometimes in a NAME parameter on a Content-type: header line, or
in a FILENAME parameter on the Content-disposition: header line, or
occasionally filenames will even get put on the Content-description: header
line.  So you could try doing something like:

if header :contains
 ["Content-type", "Content-disposition", "Content-description"] ".vbs" { 
 ...some action... }

but of course note that that's only going to apply in cases where incoming
messages are in MIME format, and happen to have the filename explicitly
advertised on one of the listed MIME header lines.  So depending upon what
sorts of incoming messages you're dealing with, this may or may not be useful.

Regards,

Kristin

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 03 Feb 2003 17:08:45 -0500

Hi [email-masked],

--On Monday, February 03, 2003 1:20 PM -0800 [email-masked] wrote:

| In the meantime, note that for a message that is in MIME format, you can
| hope that perhaps the filename will show up in a MIME header line.  For
| instance, filenames are sometimes in a NAME parameter on a Content-type:
| header line, or in a FILENAME parameter on the Content-disposition:
| header line, or occasionally filenames will even get put on the
| Content-description: header line.  So you could try doing something like:
|
| if header :contains
|  ["Content-type", "Content-disposition", "Content-description"] ".vbs" {
|  ...some action... }
|
| but of course note that that's only going to apply in cases where incoming
| messages are in MIME format, and happen to have the filename explicitly
| advertised on one of the listed MIME header lines.  So depending upon what
| sorts of incoming messages you're dealing with, this may or may not be
| useful.

That won't work in general. The 'header' test is done only over the 
top-level rfc2822 headers and not on any MIME headers embedded in the 
message when it is a multipart. Thus any multiparts will not be caught by 
this and I think that will be the majority of cases.

-- 
Cyrus Daboo

---

From: Jutta Degener <[email-masked]>
Date: Mon, 3 Feb 2003 15:13:30 -0800

Seems a lot of people have asked for this.
So, here's a bit of wording to play with.

Two issues I can think of:

- I really don't like applying regexes to something with
  a comment and quote syntax.

  Therefore, I'd like a :param parameter that can be used
  to select a Content-Disposition or Content-Type parameter
  (so you'd check for :param "filename" in the example)
  rather than trying to just match them with :contains
  or worse.  (The grammar describing what :param means
  can probably be done better.)

  But maybe this is overkill.

- RFC 2047 prohibits RFC 2047-encoding of filenames.
  (They're not the right kind of token.)

  In reality, many clients do RFC 2047-encode and -decode names,
  and I think sieve code matching against file names in order
  to prevent use of certain extensions needs to, ironically,
  RFC 2047-decode the wrong tokens in spite of what the RFC itself says.

  I'm not sure about the right wording there.

Here's a hasty first draft:

Test mimeheader

   Syntax: mimeheader [:param <params:string-list>] [COMPARATOR] [MATCH-TYPE]
        	     <header-names: string-list> <key-list: string-list>

   The "mimeheader" test evaluates to true if any of the values of
   the named MIME headers match any of the keys.  The type of match
   is specified by the optional [MATCH-TYPE] argument, which defaults
   to ":is", as specified in section 2.6 of [SIEVE].

   Like the "header" test, this test returns true if any combination of the
   string-list and key-list arguments match.  Also like "header", a
   MIME header listed in the header-names argument contains the
   empty string key if and only if it exists.

   Unlike the "header" test, the headers matching the "mimeheader" test
   can occur either in the outermost RFC2822 header or in any of the 
   contained MIME parts.  (They must occur in the header section of
   a MIME part; the matching algorithm MUST disregard the text contained
   in MIME bodies.)

   If the optional :param keyword is present, all matching headers
   are interpreted as if they had the syntax

   	*(token / <tspecial other than ;>) *(; name=value)

   similar of the Content-Type and Content-Disposition header, and the
   value used for the sake of comparison is that of the parameter whose
   name case-insensitively matches any of the specified names.

Jutta <[email-masked]>

---

From: Marc Mutz <[email-masked]>
Date: Tue, 04 Feb 2003 00:53:51 +0100

On Tuesday 04 February 2003 00:13, Jutta Degener wrote:
<snip :param>

>   RFC 2047-decode the wrong tokens in spite of what the RFC itself
<snip>

They should decode rfc2231, of course, but leave rfc2047 alone in 
parameters. The only client I am aware of that is so broken to produce 
rfc2047 in parameter values is - guess what - Outlook (I think mutt had 
this bug in one or two minor revisions, too, but I don't know, so I 
won't claim it).

As a general note, this mimeheader searching is of course failing for 
encrypted content, so if you try to filter out .vbs (which, I suppose, 
are VisualBasic scripts), you're better off hooking up a custom 
solution (read: ADKs, bah!) into your Sieve engine's spamtest/virustest 
framework.

Marc

-- 
History teaches that grave threats to liberty often come in times of
urgency, when constitutional rights seem too extravagant to endure.
                                  -- Justice Thurgood Marshall, 1989