Jacques Beaudoin wrote:
> Could dbmail-imap be modified to ignore the character set field since it
> does not nead it.
Probably, but you do want some sanity check there. In 2.0 all
search/sort actions are performed in-memory by the imap daemon, and
*not* by the database. All the calls doing the comparisons and searches
are only guaranteed for us-ascii. While iso-8859-1 will probably work as
well, utf-8 is out of the question.
For 2.1 things have improved with the new search/sort framework. Now all
header searches and *all* sorts are performed directly by the database
engine. This means that we're set to support whatever charset the
database will support, meaning pretty much any. Only exception is
body-searches. And that will need to be addressed by using a utf8 clean
set of interfaces in (at least) that part of the code.
Since I'm pretty sure iso-8859-1 is ok for imap searches in 2.0, I've
enabled this. Fix is also available in svn dbmail_2_0_branch
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
diff --git a/imapcommands.c b/imapcommands.c
index 2ca41ca..37e38f5 100644
--- a/imapcommands.c
+++ b/imapcommands.c
@@ -2201,7 +2201,7 @@ int _ic_search(char *tag, char **args, C
return 1;
}
- if (strcasecmp(args[1], "us-ascii") != 0) {
+ if (strcasecmp(args[1], "us-ascii") != 0 && strcasecmp(arg[1], "iso-8859-1") != 0) {
ci_write(ci->tx,
"%s NO specified charset is not supported\r\n",
tag);
