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.
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) 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.
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 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.
I'm imagining a gui with checkboxes along these lines:
Send an SMS to your phone including the following attributes:
- Sender
- Subject
- Message Body
- Spam Score
- Priority
Then depending on which checkboxes were ticked would change what message string
we authored, where the checkbox would either add or remove a
$HEADERS['Subject'] from the message string. Without this kind of mechanism,
we have to not only add the string to the message, but also use a header test
before hand to make sure we have that variable available to us to use in this
message.
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}";
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.
I would doubt that any gui builder out there can handle every corner case of
every part of Sieve, but rather makes the most useful subset available to the
user and surrenders to a text editor if the nesting/syntax goes beyond the
scope of what can be easily communicated through form controls.
Nigel