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...
I agree completelhy with what Arnt said, but I thought I should point out
that this is covered in RFC 5230 section 4.2. In sumnmary, responses are
tracked on the basis of both the message content and recipient. There's the
further nuance that the content that's tracked is what's there *before*
variable subs.
As for how this would interact with a hypothetical hold-until sort of
capability, I really haven't thought it all the way through, but there's
definitely an interaction, and it's an ugly one: Ideally you'd want the
duplication check done at the point where the hold is over. But in order
to get the interaction with variables right you'd have to save both the
expanded and unexpanded message for use in this comparision.
Now, you can probably cheat by just storing the hash, but in my implementation
at least we do this check as part of Sieve evaluation. I'm not eacfly sure how
we'd arrange to defer this check, but it most certainly is no longer an obvious
"just use FUTURERELEASE" thing now.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve