> > I don't think it is meaningful to add a general function. consider
> > SETDATE, which had an optional parameter for the timezone.
> I agree. The need for extension-specific parameters makes a general
> function infeasible.
<snip>
> I agree here as well. The cost of doing what's necessary to bind a fair
> number of different variables to a set of values is the only thing that
> makes this whole idea somewhat attractive. But the code of binding
> one or two variables, which is what you'd have in the case of spamtest
> or virustest, is so short that I just don't see the need for a separate
> variable binding action.
Great, well as you can guess I'd much rather these variables were just made
available, and we didn't need a setvariables, so where are we now?
My position is that none of this is really needed, but if we have to have it
needs to take the form of a separate extension or set of extensions to define
the needed actions to set the variables. Additionally, the only case I've seen
where I view the marginal utility as being being sufficient to bother is the
that of setheadervariables (or whatever you want to call it).
Are we
saying that spamtest should be revised to specify that it defines certain
variables in a spamtest namespace, and we have a new extension that if
requested makes a list of message attributes available as variables, and we
don't need any special action to ask that they be initialised?
Absolutely not. IMO none of this has any business being added to spamtest.
Let's please remember that spamtest is defined in a standards-track RFC, and
any enhancements to it have to be done as a separate extension. It could
be incorporated into a revised RFC as a separate extension, but again,
I don't think the benefits in the case of spamtest are really there.
Instead
sensible implementations will only evaluate costly variables in a lazy
fashion so as to avoid resource overhead?
So my SMS string has become:
set "Message" "[To: {$header.to} From: ${header.from}] ${header.subject}"
And my "magic string" has become:
addheader "X-Spam-Score" "${spamscore.score}";
I don't see any variable setting actions here, so this is IMO incomplete.
Ned