> Yes, I wish I knew that before. I will scour it.
> (but, wait, where is it?)
http://www.moria.de/~michael/sieve/
> I did not think of =00 (but it does not result in buffer overflow).
It should not terminate the string, either. This is the issue that
was discussed on this list before: The Exim string model. As it is,
Exim uses an explicit length count in many places, but not everywhere.
If headers are automatically converted, =00 should decode to \0,
thus enforcing that Exim is able to deal with it. Using a string data
structure that contains a length and capacity count would remove many
explicit variables from Exim and make the code easier to understand,
but it is also quite some work.
That's why I did not add a decoding function to Exim but convert headers
inside the Sieve code.
> As Philip mentioned, ordinary users do not (or do not want to)
> understand character sets or encodings. As Sieve wants all headers to
> be UTF-8 (described in Sieve spec, 2.7.2), we'd better convert all
> headers to UTF-8 unless some build options are specified.
No further build options, please. A configuration or filter option
could specify an optional target character set.
> > I already introduced HAVE_ICONV in the OS header files for Linux, Solaris
> > and HP-UX for Sieve support, so you can rely on using that.
>
> Uh-huh, iconv are sometimes buggy, however, in some implementations.
> Some iconv uses "UTF8" not "UTF-8", "EUCjp" not "EUC-JP". I think we
> should leave a choice in the build time configuration to users.
I know, but it should be up to the admin to ensure that iconv can
process MIME character set names. HP-UX 11 only requires to add
some character set aliases. Of course you could also link against GNU
libiconv.
Michael
