headers
JT Traub | 6 Sep 2000 00:18

(re)Opening a can of worms

I work for a small software company (Seattle Lab, Inc) which provides an
email server for Windows NT as one of our products.  One of the features we
are looking at adding to SLMail is SIEVE support.   This seems rather
straightforward, and I understand the reasons for not having the SIEVE draft
specify how scripts are accepted by the server from the clients.   However,
that is one thing we will have to address.   In looking over the mailing
list archives, it seems as if at least one other server is approaching this
by implementing a minimal ACAP service.   Since we haven't yet begun the
implementation of this feature, I wanted to see what methods were currently
in use by the clients and servers which plan on supporting SIEVE.   Pointers
to the documentation on those implementations (if they aren't
self-explanatory) would be useful as well so that we can make an informed
choice on how to proceed in a reasonable fashion.

Thanks,
--JT

--
===========================================
JT Traub                  Software Engineer
Phone: 425-825-7060       Fax: 425-825-7061
Email: jtraub <at> seattlelab.com

Seattle Lab Inc.
11730 118th Ave. NE #400
Kirkland, WA  98034
http://www.seattlelab.com
===========================================
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nigel Swinson | 7 Sep 2000 18:48

Possible RegEx security problem.

Hi folks,

In draft-murchison-sieve-regex-02.txt it says

    Security considerations are discussed in [SIEVE].  It is believed
    that this extension doesn't introduce any additional security
    concerns.

What if I write a regular expresssion that may be utterly meaningless, but
processor hungry.  Could we not potentially crash the server as it tries to
match this against part (or all) of the message?

I bring this up as I have just been working with a WIN32 RegEx
implementation that freezes up if you type in the regular expression

  (.*)*

I'd rather not have a user type in this as a regular expression and freeze
up my mail server!

Is this a potential security problem, or have I just had a bad experience
with a bad RegEx implementation?

Nigel
Permalink | Reply | 2 comments |
headers
Tony Hansen | 8 Sep 2000 02:33
Picon
Favicon

Re: Possible RegEx security problem.

I'd call it a bad regex implementation. 

All implementations of anything have the potential of having bugs that
can be exploited for nefarious means. This extension definitely doesn't
introduce any additional concerns along those lines.

	Tony Hansen
	tony <at> att.com

Nigel Swinson wrote:
> 
> Hi folks,
> 
> In draft-murchison-sieve-regex-02.txt it says
> 
>     Security considerations are discussed in [SIEVE].  It is believed
>     that this extension doesn't introduce any additional security
>     concerns.
> 
> What if I write a regular expresssion that may be utterly meaningless, but
> processor hungry.  Could we not potentially crash the server as it tries to
> match this against part (or all) of the message?
> 
> I bring this up as I have just been working with a WIN32 RegEx
> implementation that freezes up if you type in the regular expression
> 
>   (.*)*
> 
> I'd rather not have a user type in this as a regular expression and freeze
> up my mail server!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phil Pennock | 8 Sep 2000 09:43

Re: Possible RegEx security problem.

On 2000-09-07 at 20:33 -0400, Tony Hansen wrote:
> All implementations of anything have the potential of having bugs that
> can be exploited for nefarious means. This extension definitely doesn't
> introduce any additional concerns along those lines.

Aren't regexes inherently more _likely_ to cause optimisation problems
in an implementation, because of the greater expressive power?

But then, it's an extension, so sites which worry about their users
doing this are free to not provide it.  :^)

But should the draft be amended to note that any implementation is
likely to carry a higher processing overhead than the globbing used by
:matches and sites should take this into consideration when deciding
whether or not to provide it?

> > I bring this up as I have just been working with a WIN32 RegEx
> > implementation that freezes up if you type in the regular expression
> > 
> >   (.*)*
> > 
> > I'd rather not have a user type in this as a regular expression and freeze
> > up my mail server!
> > 
> > Is this a potential security problem, or have I just had a bad experience
> > with a bad RegEx implementation?

That level of effect is a bad implementation.  But generally speaking,
regular expression matching is more resource intensive [1] than globbing
or straight string comparison.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Gellens | 12 Sep 2000 01:46

Re: (re)Opening a can of worms

<http://www.ietf.org/internet-drafts/draft-gellens-acap-sieve-00.txt> 
describes one simple approach, which is very easy to implement in both 
clients and servers.  We have prototype code running for both.

(I need to publish an updated version of the document.)
Permalink | Reply | 0 comments |
headers
Randall Gellens | 12 Sep 2000 02:12

draft-melnikov-sieve-imapflags-03


>    All actions described in this specification (setflag, addflag, removeflag,
>    mark, unmark) operate on an internal variable that contains the set of 
> [IMAP] flags
>    associated with the message being delivered. When the interpreter 
> starts executing
>    a script this variable contains an empty set. The 'addflag' action 
> adds flags
>    to the existing set. The 'removeflag' action removes flags from the 
> existing set.
>    The 'setflag' action replaces the existing set of flags with a new set.
>    Whenever the interpreter encounters a 'fileinto' or 'keep' action it files
>    the message with the current set of flags.

I'm not comfortable with the specification of an internal variable.

I'd prefer that the draft stick to the semantics of the operations.  As I 
see it, the actions added by this extension modify IMAP flags on the 
message being processed.  If the message is eventually kept or filed, the 
flags go with it.  If the message is deleted, the flags are meaningless.

'setflags' undoes any previous flag actions and causes the specified flags 
to be set.

'addflag' sets the specified flags.

'removeflag' cancels the specified flags from being set.

Also, I think the descriptions of 'mark' and 'unmark' are unclear.  They 
should specify exactly what is to happen, and not have so many MAY do this
(Continue reading)

Permalink | Reply | 4 comments |
headers
Randall Gellens | 12 Sep 2000 02:34

draft-murchison-sieve-subaddress-01

I think the draft should say why it is needed, that is, why not just use

     if address :contains :localpart ["to", "cc", "bcc"] "+foo"

Also, should the draft deal with the fact that not all systems use "+" as 
the character which introduces subaddresses?
Permalink | Reply | 6 comments |
headers
Ken Murchison | 12 Sep 2000 21:43

Re: draft-murchison-sieve-subaddress-01


Randall Gellens wrote:
> 
> I think the draft should say why it is needed, that is, why not just use
> 
>      if address :contains :localpart ["to", "cc", "bcc"] "+foo"

The problem is that this will match both 'user+foo' and 'user+foobar'
which we may not want.

The :user and :detail options provide the same functionality as the
:localpart and :domain options -- they all allow for exact matches on
the various pieces of the address.

Without having variables, the :detail option doesn't have much, if any
use IMHO.  But the :user option is valuable when people use detailed
'from' addresses.  For example, if I want to do something with all
messages from you, I'd use:

if allof (address :user "from" "randy", address :domain "qualcomm.com")

This will catch mail from you whether you use "randy", "randy+sieve",
"randy+imap", etc.  This being said, the best way to do this (and any
other complex address match) is via the regex extension, eg:

if address :regex "from" "randy(\\+.*)? <at> qualcomm.com"

> Also, should the draft deal with the fact that not all systems use "+" as
> the character which introduces subaddresses?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Randall Gellens | 12 Sep 2000 23:55

Re: draft-murchison-sieve-subaddress-01

I think it's useful.  You also bring up a good point, which is that 
if a Sieve implementation supports userdetail, the ":user" portion 
of an address does *not* include the detail.
Permalink | Reply | 4 comments |
headers
Ken Murchison | 13 Sep 2000 03:34

Re: draft-murchison-sieve-subaddress-01


Randall Gellens wrote:
> 
> I think it's useful.  You also bring up a good point, which is that
> if a Sieve implementation supports userdetail, the ":user" portion
> of an address does *not* include the detail.

So, you think that I should continue work on the draft?

Are you suggesting that the capability should be userdetail instead of
subaddress?  I really don't like subaddress and have been searching for
something better.

Do you have any problems with :user and :detail as the optional
arguments?  Suggestions for something better?

Any suggested text for discussing different user/detail separators?

Thanks,
Ken
--

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
Permalink | Reply | 3 comments |

Gmane