Subject: Re: Sieve extensions

From: "Matthew Wall" <[email-masked]>
Date: Sun, 18 Jan 1998 19:19:34 -0500

--On Sun, Jan 18, 1998 18:51 -0500 "Tim Showalter" <[email-masked]>
wrote: 

>  Trying to get a list of all the ways an
> interpreter can fail is futile.

I agree, not that this has prevented people from trying in the past 8-).

However, there is a distinction to be made between specifying a script
language and interpreter behavior.

>  If
> the ACAP server can't validate the script, when does the error get
> returned?  If the ACAP server does validate the script, but then a runtime
> error happens, what happens?

Well, I'd kinda assumed that the ACAP dataset specification would include
accomodation for footprints related to validation, i.e. script generation,
modification, and validation. Either the 'authoring' or 'runtime' agent
would have access to these footprints for relay to the user. For example, an
MTA using mail transport for setting and storing these rules might send back
a mail message, while a SIEVE client using ACAP would do a search on the
footprint attribute immediately following a store. Or something like that. 

This would be neutral as to the validating party; i.e. it wouldn't exclude
something on the ACAP server from doing this validation, but requiring an
ACAP server to do the validation seems like a somewhat baroque requirement.

> 
> I think the transporting agent *should* validate the code, but there's no
> way to enforce that.  The filtering agent has to do validation before
> running the code so that syntax errors can be weeded out -- make sure that
> the filter and the user agree that the script is at least valid before
> trying to run it.

Well, I still disagree. Transport's transport and oughtn't pass judgement on
data -- otherwise, you're essentially suggesting something akin to what
Keith was suggesting earlier, an independent dedicated protocol.

The user (via her/his SIEVE-writing agent) would presumably have agreed to
the syntax prior to submitting it.

> 
> Asking the transport to verify the script is good, but not complete; it's
> the server's responsibility because there's no other way to even suggest
> that the client will get it right.

Yes. But that comes back to the basic point: why require the transport agent
to do anything at all with respect to the validity of the script if it's
ultimately the server's undeniable responsibility to vette prior to
execution? It's redundant, and the transport would merely be acting in an
advisory capacity, anyway. (And wouldn't be able to comment on extension
validity, f'rinstance, the interpreter/server might know about).

I think if you can provide a persuasive argument that there's something
about the proposal that requires a real-time validity response, you may be
arguing for YAP (yuk).

- mw

-----------------------------------------------------------------------
Matthew Wall                       mailto:[email-masked]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: 412 605 0499                Fax: 412 605 0705
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------

---

From: Tomas Fasth <[email-masked]>
Date: Mon, 19 Jan 1998 03:56:34 +0100

I think using ACAP as the middle man between UA and the FA (filter
agent) is not a particularly good solution. It seem like doing things
halfway somehow.

Using ACAP to store UA preferences and configuration, inclusive filter
rules, is one thing. Especially when working truly disconnected and at
different locations. Then it's a great thing.

Using ACAP as a mediator between an UA and remote functionality may
work, unsaid how the security model looks like, but not something we
should put up as a primary recommendation. And even if we do, a user
have to provide the filter agent some form of direction how to dig out
an entry from an ACAP repositary. How exactly is this provided? So,
maybe it's not within the scope to ask such a question. Still, the
question is related to the question about how the FA will be able to
communicate error conditions and status information. If we find an
answer to either of the questions, we might actually have answered both.

Tomas

---

From: Ned Freed <[email-masked]>
Date: Mon, 19 Jan 1998 01:42:03 -0800 (PST)

> agent) is not a particularly good solution. It seem like doing things

I happen to think it would be a great solution. Unfortunately I also happen to
think that people will use all sorts of mechanisms to send these things around
and we need to be prepared to deal with different ones.

We need to focus of documenting what a suitable mechanism is rather than
assuming that some specific mechanism will always be used. We can, if we think
it necessary, define something very specific, but doing so does not obviate
the need to lay down some general requirements.

> an entry from an ACAP repositary. How exactly is this provided?

The ACL facilities in ACAP are more than flexible enough to do this.

> So,

I think we need to assume that all sorts of paths will exist with varying
capabilities. Mind you, this doesn't mean we cannot standardize a set of errors
for Sieve programs as part of laying out what the minimal capabilities have to
be. However, I think the notion of standardizing a very precise set of errors
and mandating when they are to be produced goes much too far. For one thing,
people are going to use all sorts of different parsers and requiring that
certain errors be detected in certain ways is far too limiting. And for
another, I do not believe that doing stuff like this actually results in a more
useful and user friendly facility. As it happens my initial compiler
experiences were with languages set up with sets of errors along these lines,
and that experience was anything but good.

				Ned

---

From: Tomas Fasth <[email-masked]>
Date: Mon, 19 Jan 1998 18:04:12 +0100

> the need to lay down some general requirements.

That's fine with me. Actually, I would welcome a discussion on general
requirements which is not ACAP tainted. Not that I dislike ACAP in
general, but I have some difficulty to view it as the great savior for
all kinds of inter-agent communication either.

> The ACL facilities in ACAP are more than flexible enough to do this.

Okay, I believe you.

> be.
> However, I think the notion of standardizing a very precise set of errors

Okey, so, a minimum set of error capabilities would at least be
something. We might be lucky, Sieve is a sort of minimalistic language
and as such may limit the amount of possible parsing errors. And I think
a categorized (i.e. not too detailed) status report will suffice.

--Tomas

---

From: Ned Freed <[email-masked]>
Date: Mon, 19 Jan 1998 12:20:26 -0800 (PST)

> all kinds of inter-agent communication either.

Let me take a stab at this and see what I can come up with. I note in passing
that much of this is probably obvious to many if not most participants. This
does not, however, mean we can get away with not writing this stuff down.

First of all, I think its obvious that security is, if not the key issue,
certainly a major issue.

Security breaks down into three things: Authorization, integrity, and
confidentiality 

Authorization is obviously a mandatory requirement. It is imperative that
whatever agent adds a script to the delivery service on behalf of a user check
and make sure the script has appropriate authorization credentials to do so.
Failure to do this leaves the door open (again, obviously) to service denial,
mail interception, and mail bombing attacks.

Integrity checks are a trickier matter, especially since protocols like ACAP
(or LDAP, if you prefer) frequently have authentication checks but not
integrity checks. And without integrity checks a sufficiently determined
attacker can intercept or replace a script. This is intrinsicly harder than the
no-authorization situation, in that such attacks have to wait for someone to
submit a script.

I'm seriously tempted to make integrity a SHOULD or even a MUST sort of thing
here. While it is true that we have many protocols where connection stealing
and similar attacks are possible and we aren't doing much about it, I don't
think we're serving the commmunity by creating more of them.

Finally there's confidentiality. This is also tricky. It is tricky because one
of the things people will do with scripts is put passphrases into them as  part
of building their own simple routing protocols, e.g. if the word "foobar"
appears on the subject like then direct this material to my cellular connection
which costs $$$. One can in fact argue that because of the potential for
scripts to contain passphrases and the IETF's position on password-in-the-clear
all script transfer must employ confidentiality services.

I personally think this goes too far, and that a MAY or, if pressed, a SHOULD,
would be sufficient. Nevertheless we need to explain that privacy is an issue
because the contents of scripts may contain stuff you don't want other people
to see.

Anyway, this is an attempt to start in on the security issues. This isn't the
only transfer requirement of course, but I think it will suffice to get
discussion started.

> a categorized (i.e. not too detailed) status report will suffice.

I agree that this is a possibility. I also think we should recommend that
errors return some amount of context information -- I personally often
find that returning a bit of context is more useful than the error message
itself. (Yes, I know, I sometimes have to deal with really lousy compilers.)

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 19 Jan 1998 12:20:26 -0800 (PST)

Ned

---

From: Chris Newman <[email-masked]>
Date: Mon, 19 Jan 1998 14:36:12 -0800 (PST)

> agent) is not a particularly good solution. It seem like doing things

ACAP permits three architectures:

(1) ACAP and FA are tightly integrated.
(2) FA is an ACAP client.
(3) FA has a tightly integrated ACAP profile and main ACAP server provides
    a referral for sieve dataset class.

Now I'm open to listing requirements for the UA to FA transfer of Sieve
scripts and seeing if something simpler than ACAP is worthwhile.  Here's a
start:

* Ability to get list of FA supported Sieve Extensions
* Read/Write access to script
* Per-user storage of script
* Access control lists (for group addresses)
* Disconnected support (watch for two people editing same script)
* Authentication, integrity protection, privacy (can be provided by SASL
  or TLS)

		- Chris