[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sieve draft
Bart Schaefer wrote:
> Why would it be any harder to administer/maintain than a collection of
> individual services? Especially if there is simply a seive script to be
> associated with each such address.
I did express a feeling more than a fact, I admit that.
And I was relying on my own sense of modular design, which is not
guaranteed to suite any other than myself ;-)
Still, while you can provide a mechanism to allow pre-delivery
filtering to be applied on individual addresses, it seem to me that
this is a very different problem domain compared to when providing
means for a user agent to apply filtering rules on the inbox messages.
Especially when you're applying rules as part of SMTP recipient
negotiation, as you described earlier. In such a context, using Sieve
seem to be a big overkill. Or at least, most of the capabilities in
Sieve seem to be non-applicable.
The probability of applying broken rules as part of MTA operation
seem to be much higher in that context, if you persist in using a
language spec identical to the current draft of Sieve. In that case,
yes, I'm pretty sure it will add a burden to the admin task.
Compare this to a post-delivery senario, where the responsibility
for filtering has shifted from the transport domain to the user
domain. The transport is complete, delivery is successful. The
postmaster don't have to bother about MTA malfunction because of
some obscure set of filtering rules injected by a user. Or the
other way around, he don't have to spend time proof-reading every
set of rules the users want him to inject into the MTA operation.
All this have significance, particularly in larger installations.
Tomas Fasth <tomas.fasth@xxxxxxxxxxxx>
tel: +46-13-218-181 cel: +46-708-870-957 fax: +46-708-870-258
TwinSpot is a subsidiary of EuroNetics Operation in Sweden