ietf-mta-filters
[Top] [All Lists]

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

1998-01-12 16:21:02
--On Mon, Jan 12, 1998 17:59 -0500 "Keith Moore" 
<moore(_at_)cs(_dot_)utk(_dot_)edu> 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 "me(_at_)Myworkaccount(_dot_)com". 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:wall(_at_)cyrusoft(_dot_)com
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: 412 605 0499                Fax: 412 605 0705
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------




<Prev in Thread] Current Thread [Next in Thread>