Kjetil Torgrim Homme <kjetilho(_at_)ifi(_dot_)uio(_dot_)no> writes:
[Simon Josefsson]:
* 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.
like
SETDATE :header "Date";
Yes. The string must be allowed to be a variable too, so you can
extract times from Received:, etc.
it seems to me that the only interesting data to be found in Date: is
the local time and time zone of the sender (I feel SETDATE should
normalise the timezone to offset format if it recognises it). the
date itself should be no more than a few minutes earlier than current
time. if it isn't, there is a misconfiguration or an outage going on.
The time in Date: are in general not the same as delivery time.
Differences of several hours and days are typical.
oh! if you run the Sieve script in batch, long after the delivery was
made, the current date is completely useless. SETDATE should be
changed to initialise the variables to the time of delivery, not
current time.
What is the difference between delivery time and current time?
Consider the batch example again, what would SETDATE be initialized to
in this case? The delivery time is in general not available from a
RFC 2822 message, so the implementation would probably simply pick
current time. A delivery agent invoked by the MTA would also pick
current time for this, since current time is delivery time in a
delivery agent. I'm probably just dense, but I don't see a
practically useful distinction between delivery and current time.
* 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:
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.
I'd appreciate it if you could formulate a paragraph for me :-)
Someone who knows english might be able to make the following legible:
Carelessly constructed tests may be both more general than
intended and also less general than intended. This is a generic
problem with Sieve, but may become more important when filtering
decisions are made based on variables initialized from data in
message. The moral of the story is that Sieve tests are not a
replacement for intelligent spam and virus detection mechanisms,
rather a solution that is intended to work most of the time that
can be circumvented by adaptive senders.
For an example of a more general than expected test, consider
looking for "xn--foo-bar" within a To: addr-spec in order to
filter message addressed to a specific internationalized domain
names into a separate folder, and an incoming message having an
addr-spec of someone@(xn--foo-bar)example.org. For an example of
a less general than expected test, consider looking for Subject:
containing "MAKE MONEY FAST" to filter spam into a separate
folder, and an incoming message having a Subject: of
"=?CP-1252?q?MAKE_MONEY_FAST?=.
That reminds me, Sieve should support internationalized domain names
by decoding them when they occur at the appropriate places (dot-atom's
inside domain inside addr-spec, for instance).