[Simon Josefsson]:
Kjetil Torgrim Homme <kjetilho(_at_)ifi(_dot_)uio(_dot_)no> writes:
> 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.
you should get a better email provider :-)
huge mailing lists may introduce a delay of half an hour. several
hours is simply not an acceptable delay, and certainly not if it is
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.
the latest Received header is a good bet. the final local delivery
may be held up, but should be very uncommon. in the current mail
system of my University this can happen since the spool disk (my home
directory) is accessed through NFS. these days, delivery to local
storage is becoming the typical mode of operation.
> 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.
all right, I'm not a native speaker, but how about
Sieve filtering should not be relied on as a security measure
against hostile e-mail messages. Sieve is designed to do simple,
mostly static tests, and is not suitable for use as a spam or virus
checker, where the perpetrator has a motivation to vary the format
of the email in order to avoid filtering rules.
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.
if you use :address for matching, this won't be a problem. if you use
:header, there are more likely modes of failure. e.g.,
if :header :matches [ "To", "Cc" ] "root(_at_)*(_dot_)example(_dot_)com"
and a message with "To: root(_at_)uio(_dot_)no, someone(_at_)example(_dot_)com"
although this may be a common pitfall, I'm not sure warnings to "use
the appropriate test" fits in here.
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?=.
I believe that message should be filtered just fine.
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).
I think that is implied, really. it does pose a problem for clients,
they can't know whether the server supports it or not, so they need to
duplicate their tests. hmm, perhaps we do need an extension for it.
--
Kjetil T.