Re: [Exim] mime (rfc-2047) decode patch

Pàgina inicial
Delete this message
Reply to this message
Autor: Michael Haardt
Data:  
A: exim-users
Assumpte: Re: [Exim] mime (rfc-2047) decode patch
> 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