ietf-mta-filters
[Top] [All Lists]

Re: Comments on draft-homme-sieve-variables-01.txt

2003-04-19 04:53:14


[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.

Cute. I hadn't thought of using this to get a likely time zone for the
originator.

like
  SETDATE :header "Date";
vs. just
  SETDATE;
to access the current time.

Ned, you had some ideas for more date related tests, what do you
think?

I really don't want to try and force this into the setdate framework.
I'll see what I can do to write up the approach I have in mind for this.

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.

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.

Um, no, it may well be that it is the value in the Date: field that is
completely useless. It is all a question of what you're trying to achieve. If I
want a likely time zone for the originator I use Date:. If I want to guess at
when the message was actually sent use the oldest Received: field. If I want a
good estimate of when the message reached me use the newest Received: field.
(Actually, it may be necessary to  skip down a few to get the real scoop. This
is one of the reasons why this sort of test tends to be a bit context
sensitive.) If I want to know if the message has expired according to the
originator use one of the various expired fields. And if I want to alter
processing based on my current situation, use the current date.

There's a reason why there isn't a single grand unified time stamp on all
messages, and why we eventually want the ability to perform flexible
tests in this area.

  * 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.

it could be used as a poor man's associative arrays.  there'd be no
function to list all keys in the "array", though.  if we do this, we
need a way of escaping the dollar character other than the ${dollar}
hack.  I don't think it is worth it.  if we want to support
associative arrays, let's do it explicitly.

I completely agree.

                                Ned