* The setdate command is useful, but wouldn't it be even more useful
if there was a command that extracts comparable time/date variables
from Date: headers? To handled obs-zone's timezones. E.g.,
consider if I want to sort messages sent (Date:) between 01 am and
04 am (in the senders timezone) into a folder INBOX.rants.
A date test is also useful, but it is no replacement for the ability
to test the current date. Like it or not, the current date is a value
that may be reflected nowhere in the message, and may be the information
you want to use to decide on an action (e.g., I'm in a meeting and unable
to answer right away).
Additionally, if you are testing date information in the message header,
while it may be useful to test the Date: field, there are actually quite
a few other header fields that can contain date information that is even
more useful to test. For example, tests on Received: fields can be
very useful in determining if a message made it to a given point by
a given time. Tests on the various expiry fields are another example.
All tests on the Date: field tell you is the time the originator's UA or
the originator's submission elected to attach to the message.
The problem with these sorts of tests is that they tend to be somewhat more
dependent on context than we'd like (e.g., can you trust Received: fields or
not) and they introduce a substantial amount of additional complexity. For
exmaple, you really need a way to select a specific occurrance of a field to
make Received: field tests worthwhile. As such, I beleve they should be cast
as a separate operation and extension, not something we try and attach to
this draft.
This would also make it easier for script writers to do more robust
time-based filtering based on Date:, since the server could also
contain functions for handling non-conforming but easily guessable
times, if they want to support that.
Agreed. But this is not the place for it IMO. I'm trying to find the time
to write up a separate date test that accomplishes this.
Looking only at the posts to this list shows people are still using
obs-zone, and if people on this list uses such MUAs, chances are
rather high that many people in the real world also does.
Sure, this is an issue that has to be accomodated in such tests.
* A security consideration is that people should be aware that RFC
2047 encoded-word, IDNA etc potentially encode information that the
script wants to trigger on. This should have been in RFC 3028, but
as variables makes it even more likely that people will try to use
sieve scripts to filter for virus etc it might be useful to mention
it. Compare the sieve-body draft:
And the converse is also true: I may want to test for a specific sort of
encoded word (e.g., anyone sending a message to me with a subject in the gb2312
charset is probably sending spam) and that canont be done reliably at present.
Filters relying on string matches in the raw body of an e-mail
message may be more general than intended. Text matches are no
replacement for a virus or spam filtering system.
Of course they aren't. Have we really reached the point where we
have to belabor obvious points like this in security considerations sections?
* The examples in Section 3.1 and 4.1.1 should be terminated with
semi-colons to be complete Sieve commands.
* I feel variable variable names (e.g., ${foo-${bar}-baz}) would be
useful, but I can't come up with a good example why it is really
required so I'm just mentioning it if someone else can come up with
a illustrative example.
They may be useful but they add substantial complexity to some implementations.
Absent a very compelling use case I don't think this is something we want
to support.
Ned