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 gregory(_dot_)woodhouse(_at_)med(_dot_)va(_dot_)gov
May the dromedary be with you.
----------
From: Steve Hole [SMTP:steve(_at_)esys(_dot_)ca]
Sent: Thursday, January 15, 1998 9:03 AM
To: IETF MTA Filters
Subject: Service provider acceptance of user configured rules
Message-ID:
<SIMEON(_dot_)980115100310(_dot_)A(_at_)gallileo(_dot_)esys(_dot_)ca>
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