This begs the question of whether or not complex header transformations are
something we should be doing with sieve. I happen to think the answer to
this
particular question is "no".
I agree.
Copying a subject and perhaps a couple of other
fields into a new message is about as far as I think sieve needs to go.
I agree. So the question is restated as should the set of "other fields" be
predefined and fixed, or generic and able to cope with all current and future
needs? The existing $subject" strategy seems to make a very limited and fixed
set of message attributes available, and I'm concerned that this isn't going
to
meet our future needs and barely meets our current needs.
Oops, I missed the fact that you were talking about the specific (and overly
limited) approach taken in the long-expired notification draft. I have been
assuming that the existing $subject strategy would vanish now that we have
variables. I regard it as much clear to do a
if header :matches "subject" "*" {set "subject" "${0}"}
else {set "subject" ""}
sort of thing than to have a couple of magic variables, or associative arrays
of headers for that matter.
Of course there are all sorts of more complex things people will want to do.
But this is a seriously slippery slope, because lurking not far away are
things like content summaries, keyword extraction, translation services,
content shaping, and so on. This stuff has "research problem" written all
over it, and IMO sieve needs to stay away from this space.
Content summaries sound quite useful :o)
Yes, well, it seemed useful when I first heard a presentation on this general
area by Minski back in 1977. However, at the time I wasn't at all impressed by
the approaches being taken, and here it is, almost 30 years later, and look at
all the progress we've made. Personally, I'm not holding my breath...
I suppose were they to stabalize then I'd like them to be made available
through other Sieve extensions which would make new variables available to the
script author for testing or use in creating new messages.
Again, I'm not holding my breath...
Do you/we favour the $subject$ approach?
I think it is just sufficient to get the jobs appropriate for sieve done.
If we are to keep it then I hope we at least change it to ${subject} or
${headers.subject}
I'd rather get rid of it entirely and use variables instead.
I guess I would accept some implementation complexity
if it means the language is easier to use....
Ease of use is a two-edged sword. One of the things sieve is used for is
as an output format for GUI filter builder utilities. Variables are already
pretty hard to handle in such tools, things like associative arrays
are really over the top.
Actually I think what I'm proposing will make it easier for a gui, not
harder.
Perhaps in this specific case, but in general, no. The problem with the idea
of having "special" variables show up is that it won't be limited to accessing
the header. You yourself used the notion of extending it to spamtest. This
sort of thing requires fairly deep knowledge of each extension in the GUI.
I'd much rather have the binding from various information sources to
variables be explicit. It may not be possible to present this sort of
thing in a very pretty way, but at least it should be possible to accmodate
extensions more easily.
I've had to solve this in the past by having large "magic strings" like this:
if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore"
"${1}";}
addheader "X-Spam-Score" "${spamscore}";
Which I think is fine.
Where the presence or absence of the entire two lines is controlled by a
checkbox. It would have been much easier if I had a ${spamscore.score} or a
${MESSAGE['SpamScore']} available to me.
Yeech. This is exactly the sort of thing I think we need to avoid at all
costs.
Ned