Paulo Sousa | 3 Feb 2003 15:31
Picon

extensions and sieve


Hi

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

Thanks

Paulo Sousa

Nigel Swinson | 3 Feb 2003 21:57

Re: extensions and sieve


> Anyone could help me? I need filter mails by extensions (.exe .vbs ....).
> 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.
(Continue reading)

Kristin.Hubner | 3 Feb 2003 22:20
Picon

Re: extensions and sieve


In addition to what Nigel Swinson <Nigel <at> Swinson.com> wrote:

> > Anyone could help me? I need filter mails by extensions (.exe .vbs ....).
> > 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"...

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... }
(Continue reading)

Cyrus Daboo | 3 Feb 2003 23:08

Re: extensions and sieve


Hi Kristin.Hubner <at> sun.com,

--On Monday, February 03, 2003 1:20 PM -0800 Kristin.Hubner <at> sun.com 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

(Continue reading)

Jutta Degener | 4 Feb 2003 00:13
Favicon

Re: extensions and sieve


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:

(Continue reading)

Marc Mutz | 4 Feb 2003 00:53
Picon
Favicon

Re: extensions and sieve

On Tuesday 04 February 2003 00:13, Jutta Degener wrote:
<snip :param>
>   But maybe this is overkill.

It isn't, but this is:

> - 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.
<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

(Continue reading)

Marc Mutz | 4 Feb 2003 15:10
Picon
Favicon

[managesieve] setactive "" semantics questions

Hi!

from draft-martin-managesieve-04:
2.8.  SETACTIVE Command
    This command sets a script active. If the script name is the empty
    string (i.e. "") then any active script is disabled. If the script
    does not exist on the server then the server MUST reply with a NO
    response.
<snip>

What does that mean for
  setactive ""
when no script is active? Should it fail or succeed? (The latter would 
be a PITA for client implementors, since I need to LISTSCRIPTS before 
any SETACTIVE "").

And:
Do I need to issue
 setactive ""
between
  setactive "foo"
  setactive "bar"
or will the second command implicitely set "foo" to inactive?

Marc

--

-- 
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.      -- Benjamin Franklin
(Continue reading)

Lawrence Greenfield | 4 Feb 2003 22:16
Picon

Re: [managesieve] setactive "" semantics questions


   Date: Tue, 04 Feb 2003 15:10:26 +0100
   From: Marc Mutz <mutz <at> kde.org>

   from draft-martin-managesieve-04:
   2.8.  SETACTIVE Command
       This command sets a script active. If the script name is the empty
       string (i.e. "") then any active script is disabled. If the script
       does not exist on the server then the server MUST reply with a NO
       response.
   <snip>

   What does that mean for
     setactive ""
   when no script is active? Should it fail or succeed? (The latter would 
   be a PITA for client implementors, since I need to LISTSCRIPTS before 
   any SETACTIVE "").

Our server repsonds with a "No" when there is no active script. I
don't think a server that responds with an "Ok" would be that far out
of line.

   And:
   Do I need to issue
    setactive ""
   between
     setactive "foo"
     setactive "bar"
   or will the second command implicitely set "foo" to inactive?

(Continue reading)

Aaron Stone | 24 Feb 2003 07:55

Working with the CMU Sieve code base


Hi,

I've been wrestling with the CMU Sieve code base for the past few weeks
and months, cleaning it up and making it useable as a generic Sieve
library without external dependencies.

Many of the folks on this list are also in the source as principal authors
of that code base... so this may be off-topic for the list, but is there
interest in discussing the finer points of wrestling with the code here?

Specifically: sieve_script_parse() takes a FILE argument. Many modern
MDA's use databases, LDAP, and other such storage mechanisms for their
user information, such that it would be much easier to present a buffer.

Thanks,
Aaron

Rob Siemborski | 24 Feb 2003 15:13
Picon

Re: Working with the CMU Sieve code base


I'd suggest the Cyrus Development list (cyrus-devel <at> lists.andrew.cmu.edu)
for this thread.

-Rob

On Sun, 23 Feb 2003, Aaron Stone wrote:

>
> Hi,
>
> I've been wrestling with the CMU Sieve code base for the past few weeks
> and months, cleaning it up and making it useable as a generic Sieve
> library without external dependencies.
>
> Many of the folks on this list are also in the source as principal authors
> of that code base... so this may be off-topic for the list, but is there
> interest in discussing the finer points of wrestling with the code here?
>
> Specifically: sieve_script_parse() takes a FILE argument. Many modern
> MDA's use databases, LDAP, and other such storage mechanisms for their
> user information, such that it would be much easier to present a buffer.
>
> Thanks,
> Aaron
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
(Continue reading)


Gmane