thank you for your feedback, Ned, I've updated my copy of the draft, and
closed all the open issues.
I'd like to bring up a new open issue, though:
6. Implementation Limits
An implementation of this draft MUST support at least 128 distinct
variables. The supported length of variable names MUST be at least
32 characters. Each variable MUST be able to hold at least 4000
characters. Attempts to set the variable to a value larger than what
the implementation supports MUST be treated as an error.
Numeric variables ${1} through ${9} MUST be supported. Referencing
higher indices than is supported is a syntax error which MUST be dis-
covered at compile-time. If the string matching a wildcard or a
regex group operator exceeds the maximum variable size, the implemen-
tation SHOULD truncate it and MUST NOT treat it as an error.
I'm not entirely happy with this since in a minimal implementaion it
makes
if header :matches "Subject" "*" {
set "subject" "I'm gone (was: ${1})";
}
a run-time error whenever Subject is more than 4000 characters long: $1
is truncated, but the expanded string is too long. the result is Sieve
aborting, and the e-mail is implicitly kept. if the desired action is a
redirect, this can be as bad as losing e-mail.
it *is* possible to code defensively:
require ["relational", "variables", "i;ascii-numeric"];
if header :matches "Subject" "*" {
set "orig_subject" "${1}";
set :length "length" "${orig_subject}";
if string :value "ge" :comparator "i;ascii-numeric"
"${length}" "3983" {
set "orig_subject" "[excessively long Subject]";
}
set "subject" "I'm gone (was: ${orig_subject})";
}
but clearly this isn't very practical :-). there is an alternative
method which is more readable:
require ["regex", "variables"];
if header :regex "Subject" "(.{,3983})" {
set "subject" "I'm gone (was: ${1})";
}
but I'm thinking I specified the wrong behaviour when the limit is
exceeded in the first place. it doesn't really solve any problems to
treat it as an error. I think simply truncating silently is better.
users who are worried by this, can code defensively. such long strings
are after all quite uncommon, and will probably mostly occur in the
context of vacation. a truncated vacation message is better than no
message at all, IMO.
--
Kjetil T.