> I tested the latest OE (ver 6.00.2800.1123), and proved it does not > enbug. All right, but this does not mean you don't have to take care
> this kind of broken words. As some MUAs still do a broken encoding,
> because of a difficulty around character set conversion and escape
> sequences of ISO-2022-*, I wish your code be a little more flexible
> though it's not RFC standard.
Well, then the question is if we enforce an upper limit or not. I think
a fixed limit is sensible, after all it's to support rare and broken MUAs,
so there is no "correct" solution anyway. How about 1KB?
A further question is if there should be a configuration or a compile-time
option to increase the 75-character RFC limit. A configuration option
does not cost much, perhaps the highest cost is enlarging the manual.
Any suggestions?
> Anyway, your sieve.c is good enough for multi-byte filtering.
So the conversion to UTF-8 _and_ matching non-ASCII strings works?
