Subject: Message uniqueness in editheader

From: Simon Josefsson <[email-masked]>
Date: Sat, 03 May 2003 20:12:49 +0200

RFC 3028 says:

,----
| 2.10.3.  Message Uniqueness in a Mailbox
| 
|    Implementations SHOULD NOT deliver a message to the same folder more
|    than once, even if a script explicitly asks for a message to be
|    written to a mailbox twice.
| 
|    The test for equality of two messages is implementation-defined.
| 
|    If a script asks for a message to be written to a mailbox twice, it
|    MUST NOT be treated as an error.
`----

It may be useful to discuss message uniqueness in the editheader
draft, so that the following code is well defined:

fileinto "INBOX.foo"
addheader "X-Sieve-Filtered" "<[email-masked]>";
fileinto "INBOX.foo"

Otherwise, it seems to me that

1) add original message to INBOX.foo
2) add modified message to INBOX.foo
3) add both original and modified message to INBOX.foo

can all be valid behavior, which I believe is unfortunate.

Suggested new section 6 below.

Note the wording that says which order the fileinto commands must be
executed.  Perhaps the specification doesn't have to guarantee the
order messages are inserted.

,----
| 6. Interaction with Sieve and other Sieve Extensions
| 
|    Tests and actions such as "exist" or "header" that examine
|    headers MUST examine the current state of a header as modified
|    by any actions that have taken place so far.  As an example,
|    in the following example, the if statement will always be true,
|    regardless of whether the message contains the header or not.
| 
|      addheader "X-Hello" "World";
|      if header :contains "X-Hello" "World" {
|        fileinto "INBOX.hi"
|      }
| 
|    Actions that create messages in storage or in transport to
|    MTAs MUST store and send messages with the current set of
|    header fields.
| 
|    A message modified by addheader, deleteheader, or replaceheader
|    MUST NOT be considered the same as the original message.  Compare
|    the discussion about message uniqueness in section 2.10.3 of RFC
|    3028.  This means the following code will always insert two
|    messages, the first one is always the original message and the
|    second the modified one.
| 
|      fileinto "INBOX.foo"
|      addheader "X-Sieve-Filtered" "<[email-masked]>";
|      fileinto "INBOX.foo"
`----

---

From: Jutta Degener <[email-masked]>
Date: Mon, 5 May 2003 11:42:53 -0700

It's a good idea to supply an example, and I think your
choice of always considering different messages different
is a good one.

The reason that I stayed so vague was worry that a message
store could consider two messages with the same ID to the
same user "the same message" and drop one of them.  I wouldn't
want to disrupt sieve compatibility with such a message store.
But maybe I should wait until faced with one; I don't know if
anyone actually does this.

But rather than writing it like this

> |    MUST NOT be considered the same as the original message.

I'd rather go by results and say that a message that is textually
different from the original is a different message and mustn't be
dropped.

That would allow a message store to drop the second and following
of an exactly identical message, which is something I'd still
like to allow.

Jutta

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 05 May 2003 21:25:06 +0200

> anyone actually does this.

I see.  I think this is a good point.  I believe my Cyrus installation
prune duplicates, based on Message-Id, although it is an extra
feature, not part of the message store.

Perhaps include a discussion of this?  A warning to the user that
filing the message several times, even if they are altered by the
add/delete/replace commands, may not do what she expects, because of
Message-Id duplication checks.

> of an exactly identical message, which is something I'd still

Sounds good.