3 Feb 2003 15:31
3 Feb 2003 21:57
Re: extensions and sieve
Nigel Swinson <Nigel <at> Swinson.com>
2003-02-03 20:57:12 GMT
2003-02-03 20:57:12 GMT
> 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)
3 Feb 2003 22:20
Re: extensions and sieve
<Kristin.Hubner <at> sun.com>
2003-02-03 21:20:31 GMT
2003-02-03 21:20:31 GMT
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)
3 Feb 2003 23:08
Re: extensions and sieve
Cyrus Daboo <daboo <at> cyrusoft.com>
2003-02-03 22:08:45 GMT
2003-02-03 22:08:45 GMT
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)
4 Feb 2003 00:13
Re: extensions and sieve
Jutta Degener <jutta <at> sendmail.com>
2003-02-03 23:13:30 GMT
2003-02-03 23:13:30 GMT
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)
4 Feb 2003 00:53
Re: extensions and sieve
Marc Mutz <mutz <at> kde.org>
2003-02-03 23:53:51 GMT
2003-02-03 23:53:51 GMT
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)
4 Feb 2003 15:10
[managesieve] setactive "" semantics questions
Marc Mutz <mutz <at> kde.org>
2003-02-04 14:10:26 GMT
2003-02-04 14:10:26 GMT
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)
4 Feb 2003 22:16
Re: [managesieve] setactive "" semantics questions
Lawrence Greenfield <leg+ <at> andrew.cmu.edu>
2003-02-04 21:16:09 GMT
2003-02-04 21:16:09 GMT
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)
24 Feb 2003 07:55
Working with the CMU Sieve code base
Aaron Stone <aaron <at> engr.Paly.NET>
2003-02-24 06:55:13 GMT
2003-02-24 06:55:13 GMT
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
24 Feb 2003 15:13
Re: Working with the CMU Sieve code base
Rob Siemborski <rjs3 <at> andrew.cmu.edu>
2003-02-24 14:13:26 GMT
2003-02-24 14:13:26 GMT
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)
RSS Feed