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

From: "Woodhouse, Gregory J." <[email-masked]>
Date: Wed, 14 Jan 1998 20:03:03 -0600

I'm afraid I'm a little confused by what you mean here unless you have 
in mind the practical difficulty involved in having POP3 accounts and 
the like act upon messages in a timely manner. In terms of 
functionality, I can't think of any filtering task I can perform on 
the MS Exchange system I use here that I cannot perform on my Internet 
account. But in all fairness, on my other account I run procmail on 
the UNIX box that is also the POP/IMAP server. I can certainly 
appreciate that most ISPs would be reluctant to allow customers to set 
up their own procmail recipes. In fact, when I do recommend procmail 
to people I usually practically stand on my head to convince them that 
they should have someone who knows what they're doing set it up and 
then test things *carefully*.

Gregory Woodhouse [email-masked]
May the dromedary be with you.

----------
From:  Steve Hole [SMTP:[email-masked]]
Sent:  Wednesday, January 14, 1998 3:47 PM
To:  [email-masked]
Subject:  Re: MTA Filters BOF request, LA IETF; Proposed Charter

Message-ID: <[email-masked]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a6 Build (6)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Tue, 13 Jan 1998 11:57:21 +0100 Tomas Fasth 
<[email-masked]>
wrote:

> Please, hold just there for a moment.
> My opinion is that large ISP anti-spam issues are quite different 
from
> UA-filtering. I think it will improve the discussion a lot if we 
can
> agree on that.

Exactly.   The issues and requirements for dealing with SPAM are far
from well defined.   It may be that Sieve turns out to be a useful 
tool
for dealing with SPAM, maybe not.   That was not the origin of Sieve 
--
it was conceived to do unattended rule based processing on messages.

==> Begin Soapbox

I believe the following to be obvious to everyone.  However, we are
arguing for the start of a new standards track activity so it is
important that everyone have a good understanding on this.

The requirements for "unattended UA actions" (rather than filtering) 
are
reasonably well defined.   There are a number of highly successful
proprietary mail systems that support this type of functionality.
Make no mistake, implementing the same level of functionality in an
Internet client is not an option for any vendor serious about using 
the
Internet mail architecture as a competitor to proprietary systems.

To execute unattended actions you need rules.   Rules bind message
matching criteria together with actions.   If a message matches some
criteria, execute one or more actions.  We have been doing this for 
some
time, and there is good engineering experience as to the advantages 
and
pitfalls.

---

From: Steve Hole <[email-masked]>
Date: Thu, 15 Jan 1998 09:43:49 -0700

> then test things *carefully*.

OK.  There are many examples, including "procmail" and "vacation", of 
systems that do the desired kind of rule based processing of incoming 
messages.   These systems express the desired rule functionality, but
the do not address the issue of *managing* the rule set appropriately
when using distributed (POP or IMAP) clients.   The advantage that 
proprietary systems currently enjoy is the ability to manage rulesets
that are configured in one application and executed in another application.
They are able to do this because they have complete control over the entire
architecture at all times -- the definition of "proprietary" system.

We seek to build a system that standardizes the useful and reasonably well 
known features of "procmail" like rule systems AND make it appropriate for
use in a multivendor, standard architecture.

---  
Steve

---

From: Steve Hole <[email-masked]>
Date: Thu, 15 Jan 1998 10:03:10 -0700

Message-ID: <[email-masked]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a6 Build (6)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

I have now seen the comment "ISP's will not want to allow users to configure 
procmail like services" a few times on this list.    In my experience this 
statement is totally incorrect.   

First of all, there are many different types of ISP.   There is the "classic"
ISP that provides dialup or direct connect accounts for user's to the 
Internet.   It is to this group that the risk comment was directed (I think?).
A much larger group (and the group of interest to most mail vendors) is 
the "organization" service provider that 
provides connections to Internet mail inside of large commercial, educational
and/or government organizations.    It is to this group that the benefits of
what we seek to do really apply.   These are users that *live* in mail as part
of their job.   The functionality offerred by these systems is close to 
mandatory in high mail volume environments.

So ...

1.  The proposed architecture makes it a policy decision by the service
provider whether or not they want to enable rule processing in their sites.
I believe that the vast majority would do so in the presence of a standard, 
well thought out mechanism that is implemented by several different vendors.
Why do I think this way?   Because service providers have said this exact 
thing to me several *hundred* times in the last 3 years.

2.  The key issue is to provide good manageability of the architecture.  If
configurability and security issues are not well thought out, the uptake will
be lower because the risk will be higher.   Nothing magical here -- this is
true for any new service.   We just need to engineer it correctly.

Cheers.

---  
Steve

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 15 Jan 1998 10:11:29 -0700 (MST)

> true for any new service.   We just need to engineer it correctly.

And any competent implementation of a filtering system will give the 
site the ability to disable "active" actions, either globally or on a 
per "user" basis.

--lyndon

---

From: Ned Freed <[email-masked]>
Date: Thu, 15 Jan 1998 12:33:20 -0800 (PST)

> statement is totally incorrect.

My experience is in complete agreement with Steve's in this regard.

> Internet.   It is to this group that the risk comment was directed (I think?).

Well, it is somewhat axiomatic that an ISP that only provides IP connectivity
isn't going to be interested in such a facility. What would they use it for?

> mandatory in high mail volume environments.

You betcha.

> thing to me several *hundred* times in the last 3 years.

They saying this to me as well.

Actually, the reality is that the ones I deal with require this functionality,
and if it doesn't come to them in a standard they will do it in a proprietary
way.

This if anything makes the production of a standard even more important. We
have considerable experience with how this can be done badly, and we also know
that in the absence of a specification saying how to do it properly people will
do it badly. In other words, the argument, "Having a standard may lead to abuse
whereas not having one will prevent people from building and abusing this sort
of service" just doesn't wash. We don't have the option of preventing this from
happening; the most we can hope for it is to make it happen properly in some
cases.

> true for any new service.   We just need to engineer it correctly.

I actually doubt that we have much if any control over the rate of installation
of such services, and even if we do now it isn't going to last long. I do think
we may have considerable influence over what services people build, however.

				Ned

---

From: Tomas Fasth <[email-masked]>
Date: Thu, 15 Jan 1998 22:41:17 +0100

Steve, I think we all are appreciating your analysis and regard it as
being quite accurate. Your earlier posted soapbox not the least. You
have a strong point regarding manageability. I hope this sprouting
working group will be allowed to at least make some (strong?)
recommendations in this matter, preferably in the form of an
informational RFC. It does need to be addressed somehow. It seem
appropriate to keep filtering related subjects together. So, why not
this "soon-to-be" working group (slightly broadening it's scope from
plain language standardization)?

Tomas
--
Tomas Fasth                     mailto:[email-masked]
EuroNetics Operation            http://euronetics.com
Mjärdevi Science Park           Office tel: +46 13 218 181
Teknikringen 1 E                Office fax: +46 13 218 182
58330 Linköping                 Mobile tel: +46 708 870 957
Sweden                          Mobile fax: +46 708 870 258