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.
My experience is in complete agreement with Steve's in this regard.
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?).
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?
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.
You betcha.
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.
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.
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.
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