On Thu, Jan 15, 2004 at 04:50:14PM -0800, Jutta Degener wrote:
But in the (more common) case where
the filter is operating on behalf of the recipient, I would want to be
able to do the changes I want done. (kind of a tautology there.)
I don't think we have enough data to judge which use of
this proposed extension is common.
I was referring to common use of sieve, per its stated design as a
final delivery agent. However, I did allude to the possibility that a
sieve filter *could* be used in a pass-through mode, since you were
the one who was talking about MTA-like properties providing precedent
for header placement, and I was making some conjectures about where
that perspective was coming from. My contention is that in a local
delivery mode, one ought to be able to do to the mail what one wants
to do to it. As I said, I could see where there could be more
constraints on a filter that was operating in other than local
delivery mode. However I think it would be a shame to cripple a local
delivery agent for that reason: it would be better to define an
operational mode that had more constraints if one wanted.
And.. what about replaceheader?
As mentioned in section 9.1, replaceheader is no longer in the draft.
My implementation still has it, but it's a vendor-specific extension
after encountering determined opposition from some members of the
work group. If you implement it, the rules with respect to duplication
would be the same as for add- and deleteheader.
Hmm- certainly seems like replaceheader is a convenient shortcut
for "deleteheader" and "replaceheader" -- except that you lose
position, which I consider a loss (for reasons given above).
You lose count, too; if multiple headers of the same sort are present,
you can't generally rename them (e.g., Cc to Resent-Cc) because you
can't loop in sieve.
While that is true (no loops), I'm not sure it's a real answer. There
are ways to address that concern, a couple of which you illustrated in
a previous draft (nicely showing its usefulness). Rename them all,
rename the nth one, rename the ones matching a pattern, per prior
draft. There certainly could be situations where replaceheader can't
do what you want: but that's no reason to remove it.
How does a vendor-specific extension get specified vis-a-vis "require" ?
RFC 3028, section 6.1. Their name starts with "vnd."
That's not really what I was getting at. I'd want to see
"replaceheader" retained in the draft, even if it's as a "MAY" with a
separate capability name (a la the "envelope" precedent) rather than
punted like that with no chance for uniform implementation of optional
facilities. Certainly anything can be incorporated in a private
implementation, but that's not this discussion.
And in that light, could not the rules for duplication also become
In general, I don't think that's a good way of dealing with conflicting
opinions about details of an implementation.
My point too :-)