> 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.)
The header may well be longer than 76 characters indeed, but a single
MIME word must not. If it is, it is not a MIME word, and must be treated
literally. A long header must consist of multiple concatenated MIME
words, which is why white space between MIME words is removed during
the decoding process.
The rationale for that is to limit the look-ahead in the decoding
process and it makes the code easier to implement it that way it is
defined.
> 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?
Once Sieve is officially part of Exim, of course the single module
should be split and code be refactored. For now, it is very convenient
that sieve.c is quite independent of Exim, because I can still change
interfaces without interfering with anything else.
> 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.
The sieve code can deal with NUL characters, that's why it uses its
own string functions. The IETF mta-filter group basically showed me
that nobody thought about MIME encoded NUL characters, because Sieve as
defined by the RFC could never match them. Most everybody agreed that
NUL characters should not terminate things, but there was no agreement
otherwise.
Although I violate the RFC by using \0 to denote NUL instead of '0'
(note that it is not recommended by the RFC to quote regular characters,
so this is not as bad as it sounds), I would not want to fo further and
break e.g. octet matches. Standard Sieve will never match headers with
NUL characters, but your suggestion would break it.
Apart from that, replacing NUL by something else makes it impossible
to sort out mails with NUL characters in e.g. the subject, though.
Given the bugs MUAs have in that area, I don't want to miss that feature.
I can't think of how to abuse those bugs so far, but that does not mean
there is no application for them.
Michael
