On Tue, Feb 24, 2004 at 09:11:19PM -0600, Matthew Elvey (FM) wrote:
On 2/22/2004 4:23 PM, ned(_dot_)freed(_at_)mrochek(_dot_)com sent forth
electrons to convey:
It's unavoidable for behavior to differ between an MUA and an MTA, if
there is support for a "refuse" action.
This presupposes that refuse is supportable on an MUA.
I didn't (mean to) communicate that. What I meant to communicate:
It's unavoidable for behavior to differ between an MUA and an MTA, if
there is support for a "refuse" action (in Sieve when not on an MUA).
There are at least two different concerns that are being mingled,
I think: one of script operating context, and one of portability
within a given context. A script running in a MUA is in an entirely
different context than a script running on an SMTP server.
Not really. In our use of sieve it is fairly common for users to construct
scripts in their MUA and upload them to a server. And in some cases users may
design a script and both upload it to one server they use that supports such
things and run it locally on their MUA when dealing with another server that
doesn't support sieve filtering.
There can also be server-specific sieve scripts that apply server-wide or to
specific groups of users, but this doesn't mean there's not substantial
overlap. The way I look at it is that server-side sieve support has to cover
all the things client-side scripts do plus some additional stuff.
I believe
most portability issues only apply to scripts within a given context.
Yes, but since the contexts overlap...
Personally I would imagine that an MUA script is written and maintained
differently than one that runs on an SMTP server-- which may or may
not be an MTA script (it could be an MTA script or an LDA script).
So I see no reason to want a particular script to run without edits
if it is put into a different context (MUA vs MTA).
Server-side scripts provided by server admins which apply server-wide or to
groups of users do have this characteristic, if for no other reason than the
fact that most GUI sieve construction tools do a poor job of constructing such
scripts. (Hardly surprising given that this isn't what the interface is
designed to do.) But saying it applies to all scrips that run server-side
is incorrect.
The question is whether an end user can write a server-side script
that will operate whether or not that user knows if the script will
be invoked by the MTA (so that SMTP-time refusal is possible) or
by an LDA after the message has already been accepted at SMTP time.
I believe it's valuable to have this level of portability. Even within
the same mail server (or server farm) the operating mode might change
from time to time. It would be good if the script could accomodate
such a change, and it would be good to minimize the amount of work
necessary to refit a script when moving from one environment to another.
This would benefit both script writers and system administrators.
Yes, which is why I believe keeping the truly universal commands separate
from the server-specific ones is a good idea.
Ned