Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter

From: "Matthew Wall" <[email-masked]>
Date: Mon, 12 Jan 1998 18:29:10 -0500

--On Mon, Jan 12, 1998 17:59 -0500 "Keith Moore" <[email-masked]> wrote: 

> vacation and procmail *are* UAs, as are any programs to which mail is
> forwarded for the purpose of filtering mail.
> 
> I can understand why a ubiquitous filtering language would be useful.
> I can also understand how it could cause a great deal of harm, by making
> the behavior of the mail transport system less predictable.  

If delivery isn't part of the transport system, i.e. mail delivered to
procmail and vacation are out of scope, then it's not making the transport
system any less predictable. And conversely, if you do consider vacation and
procmail part of the transport system, they're full of unpredictability now.
Tell me you've never lost mail because a filter didn't do what you thought
it was supposed to 8-).

Again, the question is not whether there are lots of schemes afoot to do
this kind of activity -- causing inherent unpredictability -- because there
are and they're growing by leaps and bounds -- it's whether the IETF is
going to deal with them or punt on the issue and let the current chaos
profuse.

> 
> Defining only the language also ignores the security issues.   How
> are users going to specify such filtering without some means of 
> authenticating themselves to the filter?

On the contrary, it's probably better to not be explicit about security,
since security with a restricted-logic language is mostly a wire issue. As
with any *current* filtering or rules-processing scheme, it's only as safe
as what your delivery agent is willing to believe and the method in which
the user may authenticate and write out said rules. 

This is kind of like asking to deal with the security of writing .forward
files. You have access to it or you don't. Your delivery agent believes it
or it doesn't.

And to flip this around another way, if I am using a popular client right
now that does extensive filtering on a shared (let's say University lab)
machine, and those filters live on that machine with that client, and I step
away from the machine and Joe sits down at it, he's as subject to security
problems via my filters as anything. I.e. I have a filter that says "If from
BOSS", forward to "[email-masked]". Joe inherits the filter without
ownership or any concept about the filter, and mail from BOSS gets forwarded
to my account with Joe ever knowing it. Now *that's* a security problem.

The proposed solution doesn't speak to requirements for on-the-wire security
because it doesn't have to, although I'd be perfectly comfortable with
adding language that strongly recommends a secure channel. 

Not that SIEVE will solve this problem per se, it's just nothing new is
being introduced here. And potentially the right architecture will solve
this. While SIEVE isn't limited to use in this context, here's how I see the
ideal solution:
                                                     
                                          +----------+
                                          v          | 
      MTA -------------------> ACAP SIEVE rules ---+ |
        |                                          | |
  +--SIEVE interpreter<----------------------------+ |
  |                                                  v
  +------------------->mailstore<------------------>MUA
                                                     |
                                                     v
                                     MUA filters/SIEVE interpreter

Using the ACAP model, the MTA can trust (or not) sets of SIEVE rules
applicable to sites, groups, individuals, or other shades of ownership. The
MUA can also read -- and write, if permissions are appropriate -- similar
rules, either for interpretation by the MTA or for "private" use by the MUA,
which presumably would have a superset of MTA-side delivery functionality as
to disposition.

This way you get location-independent filtering rules, multiple clients can
build on primitives, and specific filter actions can be shared or passed
from MTA to MUA, from admin to user, and back again.

This is "security neutral" because it's the channel for how the rules get
written and read that's the basic security issue, and the working proposal
is intentionally mute on this issue.

Note the potential fundamental security issue of misuse of SIEVE -- use of
the rules to do something evil by exploiting the interpreter --  is also
addressed by the language specifically *not* being Turing-complete. Sites
that want to extend the logic have the extensibility mechanism, though, if
site security policy and confidence in the implementation allow.

-----------------------------------------------------------------------
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: "Matthew Wall" <[email-masked]>
Date: Mon, 12 Jan 1998 18:58:47 -0500

--On Mon, Jan 12, 1998 18:45 -0500 "Keith Moore" <[email-masked]> wrote: 

> 
> the filtering language might be thought of as a separate piece, but it's 
> going to need some sort of transfer protocol with authentication to be 
> useful in this scenario.
>

I think Lyndon mentioned that this has been one of the envisioned uses of
ACAP, although ACAP's obviously not a necessary prerequisite. A secure
telnet connection would do the same job, of course. Don't get me started on
SSL 8-), but http is used to slice cheese and treat cancer, and is probably
the most popular transport mechanism for moving around proprietary forms of
these rules these days (check out one of those free email with a web browser
services, or one of the Yahoo-style 'personal' content filters), so I guess
I should (shudder) mention it as another candidate.

In any event, I don't see the requirement for a separate transfer protocol.