On Thu, Feb 4, 2010 at 3:44 PM, Derek Diget
<derek(_dot_)diget+ietf-mta-filters(_at_)wmich(_dot_)edu> wrote:
On Feb 4, 2010 at 14:01 -0500, Barry Leiba wrote:
=>
=>> Thought experiment: what if :time referred to a time of day? All
=>> vacation notices would be batched and sent at that time of day. What
=>> might be a use case for this?
=>
=>Mm. ":time 00:00:00" to send the (de-duped) batch at midnight. I
=>can't really see the need for that. For the most part, you'd want the
=>first notice ASAP, and just have duplicates suppressed after that,
=>until the interval expires.
=>
=>The only reason I could see for delaying even the first notice until a
=>designated time would be if you wanted to be able to cancel them if
=>something has changed. Like, maybe, "Don't tell people I'm gone
=>unless I'm not back by 3:00." Even with that, what happens when you
=>get back at 3:01? No, that just seems like a solution no one's asked
=>for nor needs.
De-lurking...I am not the experts you all are.
Welcome!
Should there be something said on how implementations handle deltas to the
:time (or :seconds) window with respect to the previous response history
database? Does a change to the sieve remove/wipe the previous response
tracking history? I don't see any mention of that in RFC 5230. For
example...
Fred has a vacation rule with responses set for every 10800 seconds (he
is in a morning meeting). Wilma sends a message to Fred at 10:30 and
receives a vacation response since it is the first message she has sent
to Fred that day. Fred gets out of his meeting and modifies his
vacation sieve at 11:50 as he heads out to lunch with a :time now set to
5400. (He might or might not change the reason string.) Wilma sends
another message to Fred at 12:00 that would "match" her first message
and not have caused a response under the original rule. Does Fred's
modification of the filter cause the sieve system to remove/wipe/clean
its response tracking history and thus cause a new response to Wilma's
12:00 message?
The reason I ask is that I see with user's being able to set vacation
replies using seconds they might connect their
Twitter/MySpace/Facebook/etc account status with vacation rules. They
update their ${SOCIALSITE} status and it updates their vacation sieve
rule with their new status message. :) or :( depending our the side of
fence you stand. And I could see same thing in the IM/presence world,
too.
If this is addressed somewhere sorry for wasting your time.
The question of when to respond is addressed, but your question is
entirely valid. In short, no, the response tracker should be separate
from the script.
From RFC 5230, Section 4.2, "Previous Response Tracking":
...
Tracking is not just per address, but must also take the vacation
response itself into account. A script writer might, for example,
have a vacation action that will send a general notice only once in
any two-week period. However, even if a sender has received this
general notice, it may be important to send a specific notice when a
message about something timely or something specific has been
detected.
A particular vacation response can be identified in one of two ways.
The first way is via an explicit :handle argument, which attaches a
name to the response. All vacation statements that use the same
handle will be considered the same response for tracking purposes.
The second way is via a synthesis of the :subject, :from, :mime, and
reason vacation command arguments. All vacation actions that do not
contain an explicit handle and that use an identical combination of
these arguments are considered the same for tracking purposes.
...
In the "second way" paragraph, the parameters :subject, :from, :mime,
and the reason are specified as the ones to use in constructing a
tracking handle. Omitted from the list is :days, probably for exactly
the reason you're asking about. I think what most implementations will
do is (implementers please correct me!):
Receive message
Run the sieve on the message
Vacation action:
Calculate the handle for the action
Look up the handle - recipient pair last response time
Is the current time - last response > :days?
Yes: send a vacation response
No: take no action
Later in Section 4.2:
...
Implementations are free to limit the number of remembered responses;
however, the limit MUST NOT be less than 1000. When limiting the
number of tracked responses, implementations SHOULD discard the
oldest ones first.
No mention is made of keeping or wiping the response tracking log when
the sieve is updated, but it reads like we're just assuming that you
wouldn't do that :)
Cheers,
Aaron
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve