Hello,
as defined by RFC 3028, Sieve scripts may not contain NUL characters.
MIME encoded headers may contain them (encoded), though, and there is
currently no way to match them with Sieve. For that reason I suggest
to change paragraph 2.4.2 of the RFC to define \0 being a representation
of the NUL character.
I know, that's quite a change, but it's quite a bug, too. ;-) Btw, both
Mutt and Outlook Express don't show anything after a MIME encoded NUL
characters, so they simply decode it and, given C strings, terminate the
string that way, because nobody ever thought about how to handle them.
If a sieve implementation is not subject to this bug, then most likely
it could support \0 pretty easy. Otherwise some work is required anyway
to fix the bug.
While extending the meaning of \, I suggest to use the Java \u notation
to specify unicode characters. Sieve scripts are written in UTF-8 for
good reasons, but being able to use non-ASCII characters without having
to use UTF-8 would be great. That's just an idea, though, and not really
required like \0 is.
I am currently writing my own sieve implementation as extension to Exim.
Hacking MIME decoding, I discovered the problem above and Tim Showalter
suggested I join the list. It's not the first issue I had with the RFC
so far, but the first that asks for a change in the language.
Michael