Hi Michael,
I am so sorry I haven't answer you for a week, in which exim 4.20
has been released.
On 2003/05/07 20:03:58, Michael Haardt wrote:
> > Yes, I wish I knew that before. I will scour it.
> > (but, wait, where is it?)
>
> http://www.moria.de/~michael/sieve/
I took a look at your sieve.c, and have some disagreement with you.
1. MIME encoded headers are NOT always shorter than 76 characters
long, though it's a violation of RFC. Many ISO-2022-* mailers
do this indeed. (eg. line 741, 747 in function expand_header.)
2. exim has its own Base64 decoding function in auths/b64decode.c.
Should we use the new one or the old one? What do you say about
having auths/qpdecode.c? (I'll say no, though)
3. How about separating sieve's string functions to another file,
so that other patch authors could use it?
> > 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.
Okay I see. I respect your opinion, as I'm rather new to this list.
But we should replace '\0' to '\\0' or '.' or something for the
usability.
> 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.
As you know, HAVE_ICONV is now in exim's official header.
I will check it.
--
Norihisa Washitake.
Dept of Earth Sciences, Sci, The University of Tokyo
nori@???,
http://washitake.com/
