+----- On 16 Feb 1999 17:26:53 EST, Tim Showalter writes:
| > Date: Tue, 16 Feb 1999 11:01:03 +0100
| > From: Michael Salmon <Michael(_dot_)Salmon(_at_)uab(_dot_)ericsson(_dot_)se>
|
| > | Implementations decode header charsets to UTF-8. Two strings are
| > | considered equal if their UTF-8 representations are identical.
| > | Implementations should decode charsets represented in the forms
| > | specified by [MIME] for both message headers and bodies.
| > | Implementations must be capable of decoding US-ASCII, ISO-8859-1,
| > | the ASCII subset of ISO-8859-* character sets, and UTF-8.
| >
| > I think that ISO-8859-15 would be more appropriate than -1, it fixes
| > the bugs in -1 and adds the euro.
|
| For better or worse, I believe 8859-1 is more common and should be
| required, but I don't have a string opinion on the subject.
|
| Is this not the case?
It is the case today but it is unlikely to be the case when sieve
become a standard. The most important reason is the replacement of the
generic money symbol (0xa4 ¤) with the euro symbol but it also includes
some of the characters that they missed in Latin1.
[...]
| > [...]
| > | 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.
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.
| > 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.
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.
[...]
| > [...]
| > | 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.
| I think that this should be on a per-user basis, not a per-server basis,
| and I'll fix it accordingly:
|
| | In order to prevent mail loops, implementations must prevent messages
| | from passing through a given user twice.
|
| I think this is what I intended, and I believe it's a clear improvement.
|
| I only want to discuss the case where a user relays a message to himself
| (i.e., a loop). Two messages with the same message-id can have
| different return-path values (say, if one hits a mailing list) and I
| don't want to require anything in that case; that's normal and fine and
| scripts should handle it accordingly.
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.
/Michael