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

From: "Matthew Wall" <[email-masked]>
Date: Tue, 13 Jan 1998 17:25:06 -0500

--On Tue, Jan 13, 1998 22:49 +0100 "Tomas Fasth" <[email-masked]>
wrote: 

> Would it be possible to draw a charter for this "delivery filtering"
> working group which include goals addressing the issues I brought up?
> It seem to me like a good idea to keep such issues together in the same
> working group and try to provide an overall interoperable delivery
> filtering standard.

OK, so I don't get to punt 8-).

I have a strong intuition that broadening the scope in this way would lead
to a firey death when we ask Harald and Keith to approve the charter.

I totally agree that these need addressing, I'm just not as sure it's an
achievable goal, and neither am I convinced that starting with a very basic
set of filter language primitives isn't the correct first step even if we'd
like to get to these things eventually.

Specifics:

> How should a MUA be able to transfer filtering rules to the MTA (or more
> precisely; to the delivery agent) so that arbitrary brands of MUA and
> MTA can interoperate?

Two answers here:

(1) it doesn't matter, if you use an intermediary, like ACAP. In a separate
thread with the ACAP group, I'm proposing an experimental SIEVE rules
dataset so we can get a reality check on implementation of filters via an
intermediary.

This is not science fiction, btw; the IMSP experiment included option names
for common mail server/MUA attributes that could be used at delivery time
for a few operations.

(Anybody who's been following cal/sched, insert your experiences here with
the new protocol issue...)

(2) since the filtering rules are just data, this can be deferred (if my
first answer isn't satisfactory) until after the filtering language itself
is completed. There's nothing inherent in construction of the language that
would preclude a particular approach to transport later.

> And, how can this be done in a way preventing evil attacks to succeed?

We perhaps need to add some more language to the current draft for security
considerations that addresses the basic issue, but I honestly don't see this
as particularly different from the simple case of having access to the
.forward file or a server-based vacation program. I can only attack where I
can convince some agent in the process to believe rules I have permission to
write.

(Case in point, by the way, I got into a little mini flame-like exchange
with somebody I "sent mail" to yesterday, and continued to "send mail" to.
It turns out a colleague incorrectly set his .forward notice to point at
this guy's account, and I was the first unfortunate SOB who sent him mail
from outside the company in question, a point this person didn't get since
he had absolutely nothing to do with setting the .forward file. Let's say
you've been fired. Before you leave, you set your .forward to go to
[email-masked]. You go home, get a hotmail account, and
immediately start cranking out mail to your old address. Substantially the
same as just attacking the Boss' mailbox directly.)

> How can the MTA be able to communicate filtering status and reports to a
> MUA in an interoperable way between arbitrary brands?

Definitely way out of scope. Desirable to talk about, but there's early and
somewhat unsatisfactory work on the instrumentation front (APPLMIB, yes?)
that will either be applicable or it won't. Transfer and handling of log
information isn't unique to this problem domain, ergo we should ignore the
issue. (My 2 c, of course, only.)

And actually, this really seems like either just an implementation issue or
something for the generalized application instrumentation/logging standards
work elsewhere.

> And, what can we do to eliminate unpredictable results from running the
> filter rules?

There are two general answers to this:

1) make the rules themselves as safe as possible. By restricting looping and
similar constructs, sieve is 'safe', although discussion of the
extensibility mechanism is probably well-advised to get into this in more
detail.

2) you can't prevent people from writing incorrect rules. This happens *all*
the time with filters. It's a problem with FLAMES, it's a problem with
Procmail, it's a problem with Eudora. And one of the problems with doing
validation for any rules-based filter in any sphere is it's quite difficult
to comprehensively test outliers -- i.e. you can do all the syntax checking
you want, but there's no algorithm on the planet to check if the rule
semantically matches the intended effect.

>  we have to
> address the interoperability issue as percieved from site deployment
> point of view. Or do you suggest that we are going to say, "Hey, it's up
> to you to find the pieces that fit together"? Seem not to adhere to the
> general spirit of IETF, IMHO.

Not really. Lyndon's analogy about RFC822 messages was a good one. You
specify structure and format for one part of the architecture, independent
of transport. Look at MIME. Same deal. You can address a building block
piece without necessarily providing a holistic answer to all problems in the
sphere.

> I suggest we either discuss
> the possibility to define a simple TCP based protocol to be used to
> exchange information related to MTA filtering. 

Yuck. I really don't see the need for it. There are a ton of ways of getting
this sort of thing over the wire, and I'd have to hear a pretty convincing
argument that a separate protocol is required for exchanging this kind of
information. ACAP is ideal, http will likely be used regardless, the mail
transport pipe itself can be used (much like it is for virtually all
listserv-style processing, for instance.)

> Or, discuss the
> possibility to define one or more MIME based formats suitable to
> exchange information related to MTA filtering using the mail transport
> itself as communication media between the MTA and the MUA.

A MIME definition is probably a good idea as part of the base spec on
general principle.

= 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: Chris Newman <[email-masked]>
Date: Wed, 14 Jan 1998 12:33:01 -0800 (PST)

Looks like this will be a tricky charter to get agreement on.  I happen to
think this is a very important effort.  I suggest the following structure
to "do it the IETF way" and to try to get concensus:

Focus on writing a simple, extensible language for final delivery time
filtering (MTA -> mailstore interface).  While other uses for this could
be nice, this is the one which needs client/server interoperability in the
IMAP context.

Have three deliverables:
* A model document which describes how final delivery filtering fits in
the Internet mail architecture, and includes requirements for
transferring the script from the client to the final delivery agent.

* A MIME type for the Sieve language

* At least one proposed transport mechanism to pass the MIME type securely
from the client to the final delivery agent.

---

I don't see how an IETF WG could get away with designing a payload (e.g.,
the Sieve language) without also identifying at least one way to carry
that payload.

		- Chris

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Jan 1998 15:59:11 -0500

> be nice, this is the one which needs client/server interoperability in the

It's the POP and IMAP cases that most need a standard upload mechanism,
but I don't want this to be specific to POP and IMAP.

seems like we've got multiple delivery scenarios in use:   

delivery to passive mailboxes (which might be accessible by POP or IMAP),
delivery to filter programs,
delivery to gateways,
LMDP

the language should work with multiple delivery scenarios

the user also needs to know where to send the filter specification.
the WG would need to specify how he does this.

(an elegant way might be to send the digitally signed filter to
an email address that is easily derived from the user's email address
e.g. [email-masked] => [email-masked] 

that way, existing mail protocols and mail routing automagically get
the message to the 'right place'.  but I haven't thought this through)

seems like the user also needs a way to retrieve his current filter,
and to determine how well it is working (how many messages processed,
how many bounced/refused, which messages were bounced, etc.)
else, how does the user know when he's shooting himself in the foot? 

in general, how does the user debug/test his filters?

> transferring the script from the client to the final delivery agent.

something like that.  at least, there is a need to list design goals.
but we don't have it yet, and the WG's charter should follow from this list.

> * A MIME type for the Sieve language

I assume this includes the description of the language itself? :)

> from the client to the final delivery agent.

Keith