Subject: RE: Service provider acceptance of user configured rules

From: "Woodhouse, Gregory J." <[email-masked]>
Date: Thu, 15 Jan 1998 14:40:23 -0600

Actually, I think you are right. For what it's worth, I do run 
procmail through an ISP (i.e., on their system, not on my own), but I 
consider that to be the exception rather than the rule. On a certain 
level, I see procmail (or other filtering agents) and CGI as being 
very similar. In each case, a program is executed on a server in 
response to a message (SMTP for procmail and HTTP for CGI). Now, as it 
happens most "classic" ISPs will either disallow CGI altogether or 
provide a limited set of "canned" programs (counters, form processors, 
etc.) but relatively few will allow users to write their own CGI 
programs. Now, my ISP does allow users to wrte their own CGI but 
places a quota on CPU resources. I can imagine a similar strategy for 
MFAs (message filtering agents) such as procmail, but I'm not 
necessarily recommending or not recommending it. Anyway, perhaps 
provider policy per se is off topic here (but provider acceptance may 
well be an appropriate topic, especially in the exploratory phase).

Anyway, before I get too tangled up in my own ramblings, perhaps I 
should step back and say that my only intention was to say that I 
recognize that there are very real and significant issues with having 
MTAs  (or MDAs) invoke user supplied code. That being said, I am not 
so sure I would go so far as to say an MTA (or MDA) should never do 
so. What I *do* think is that it is important to identify the issues 
involved and think through the issues. But again, I recognize that 
these are really implementation issues. I do not see the HTTP working 
group spending a lot of time worrying about the dangers of poorly 
written CGI (or NSAPI or ISAPI) programs. Now, maybe the situations 
aren't really analogous. One of my biggest interests right now when it 
comes to messaging (HTTP or SMTP) is gateways, and we all know the 
adage about hammers and nails...

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

----------
From:  Steve Hole [SMTP:[email-masked]]
Sent:  Thursday, January 15, 1998 9:03 AM
To:  IETF MTA Filters
Subject:  Service provider acceptance of user configured rules

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