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