Vlad Marchenko writes:

I've investigated this problem more than a year ago. It arised in OE 5.0, almost disappeared in OE 5.5 and returned in OE 6.0. Root of the problem is presence of non-ASCII (e.g. cyrillic) characters in message headers which Courier IMAP sends to client in response to FETCH ENVELOPE command. If you're using hacked Courier MTA or other MTA allowing non RFC 2047 compliant headers your maildirs inevitably would contain such a messages. Courier IMAP sends all headers as quoted strings assuming they can't contain non-ASCII chars (relying to courier MTA's strict RFC 2047 policy). When OE 5.0 or 6.0 see prohibited character in quoted string, it issues "parse error" and... totally forgets about affected message - nice behaviour, isn't it? OE 5.5 in contrast to its predecessor and successor accepts almost all prohibited characters in quoted strings (it doesn't like only control chars, e.g. 0x0d, and maybe some other exotic ones).

So release of OE 6 forced me to dust off my old 10-minutes msgenvelope.c patch (attached) which checks presence of non-ASCII chars and if so sends such string as binary literal (UW-IMAP-like behaviour). Non-ASCII symbols in some exotic places (e.g. addresses) are replacing by underscores. It worked smoothly for me with OE 5.0 and working now about 2 weeks with OE 6.0 without any problems (of course it works with all other versions of OE and Netscape).

After applying the patch, making imapd, stopping it, replacing by new one, setting correct owner and permissions and starting again you'll need to delete on client's machine .dbx'es for folders with unseen messages and download them again from server. All that spam will be in your hands!

Alexei.