Date: Wed, 17 Feb 1999 11:37:58 +0100
From: Michael Salmon <Michael(_dot_)Salmon(_at_)uab(_dot_)ericsson(_dot_)se>
| > | 2.10.3. Message Uniqueness in a Mailbox
| > |
| > | Implementations SHOULD NOT write a message to a mailbox where a copy
| > | of it already exists, even if a script explicitally asks for a
| > | message to be written to a mailbox twice.
| > |
| > | The test for equality of two messages is not defined by this memo.
| >
| > I think that this is a little tough although of course it isn't
| > mandatory. Perhaps it should be mandatory for a script to not deliver
| > more than once to a mailbox .
|
| I'm not sure what you want. That language is weasily enough to allow an
| awful lot, quite possibly too much.
|
| The reason for that second paragraph is that I consider two messages
| with the same message-id equal enough, but others will want to compare
| bodies in some meaningful way.
What I meant was that a message must be actively delivered into a
mailbox twice during a single execution of the script. It would be nice
if it could suppress the duplication of existing messages but I think
that that could be too hard in some cases.
I don't understand your first sentence. I can't find a case where I
want to write a message to a mailbox twice, ever. So I've written this,
which says you shouldn't do that.
Do you want implementations to be able to write a message to a mailbox
twice? Why?
Implementations are supposed to avoid writing messages to mailboxes if
copies of the messages already exist. They are allowed to do so if they
really want to.
What would you like the document to say?
Should a message that is identical to a message that has been stored
and then deleted be considered a duplicate? I think that it is
acceptable but should not be mandatory.
Because I didn't define equality, that's a reasonable behavior. (That
is the behavior I want.)
| > What should happen if a require is not satisfied? I would guess that a
| > required extension would be checked when the script was loaded but what
| > happens if an extension is removed?
|
| The script doesn't run at all. I've added this sentence to 2.10.5:
|
| | If a script does not understand an extension declared with require,
| | the script must not be used at all.
Good, does the action of sieve in this case need to be defined. As I
see it there are 2 possibilities,
1) perform a keep i.e. pretend that the script is null
2) write the message back into the queue
In both cases an error message should be written into the mailbox I
think, though preferably never more than one.
We punted on this as a quality of implementation issue. I believe the
correct behavior is (1) (writing back to the queue when I've gone on
vacation is not what I want) but it was decided not to define it.
Another thing that comes to mind is when are requires examined? Can
they exist inside if statements? I can see advantages to that but it
also seems to leave the way open for behaviour that is hard to debug.
I would make requires magical but I believe following from the lack of
definitions of failure behavior described above, we can't define this
unless we define error behavior.
I'm not sure I like what's in the document, but because some folks have
expressed desire not to demand seperate parse/evaluate/execute stages,
anything that suggested such behavior was removed.
| > | In order to prevent mail loops, an implementation MUST refuse to
| > | filter a message that it has already filtered once; that is, a
| > | message must not pass through a given server twice.
| >
| > This seems excessive to me, especially as servers are becoming larger
| > and larger all the time. I think that mail loops would be prevented if
| > a message could only be kept or discarded when it had been seen twice
| > by the same user.
|
| How would one write such a script?
What I had in mind was that redirect was a null action on any message
that had been seen. If nothing else was done then an implicit keep
would be performed.
| | In order to prevent mail loops, implementations must prevent messages
| | from passing through a given user twice.
I agree, it seems to fit in well with 2.10.3, in the best of all
possible worlds no matter what strange things you do you only get one
copy of a message.
I think what you're asking for is that a Sieve script ignores
"redirects" if it's seen this message before, possibly detectable by the
addition of a header. That's not a bad idea, actually. Anyone else
care for this?
--
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>