Depending on the setting of reject8bit in -imapd.conf(5), deliver either rejects messages with -8-bit-set characters in the headers or changes these -characters to ‘X’. This is because such -characters can’t be interpreted since the character -set is not known, although some communities not well-served -by US-ASCII assume that those characters can be used to -represent characters not present in US-ASCII.
+imapd.conf(5), deliver either rejects/accepts +messages with 8-bit-set characters in the headers. If we +accept messages with 8-bit-set characters in the headers, +then depending on the setting of munge8bit, these +characters are either left un-touched or changed to . This +is because such characters can’t be interpreted since +the character set is not known, although some communities +not well-served by US-ASCII assume that those characters can +be used to represent characters not present in US-ASCII.A method for encoding 8-bit-set characters is provided by RFC 2047.
diff -Naur cyrus-imapd-2.2.4.orig/imap/message.c cyrus-imapd-2.2.4/imap/message.c --- cyrus-imapd-2.2.4.orig/imap/message.c Fri Feb 27 18:44:55 2004 +++ cyrus-imapd-2.2.4/imap/message.c Thu May 20 19:15:23 2004 @@ -227,6 +227,7 @@ int n; int sawcr = 0, sawnl; int reject8bit = config_getswitch(IMAPOPT_REJECT8BIT); + int munge8bit = config_getswitch(IMAPOPT_MUNGE8BIT); int inheader = 1, blankline = 1; while (size) { @@ -262,7 +263,7 @@ /* We have been configured to reject all mail of this form. */ if (!r) r = IMAP_MESSAGE_CONTAINS8BIT; - } else { + } else if (munge8bit) { /* We have been configured to munge all mail of this form. */ *p = 'X'; diff -Naur cyrus-imapd-2.2.4.orig/imap/spool.c cyrus-imapd-2.2.4/imap/spool.c --- cyrus-imapd-2.2.4.orig/imap/spool.c Thu Mar 4 17:09:34 2004 +++ cyrus-imapd-2.2.4/imap/spool.c Thu May 20 19:16:52 2004 @@ -140,6 +140,7 @@ state s = NAME_START; int r = 0; int reject8bit = config_getswitch(IMAPOPT_REJECT8BIT); + int munge8bit = config_getswitch(IMAPOPT_MUNGE8BIT); const char **skip = NULL; if (namelen == 0) { @@ -266,7 +267,7 @@ form. */ r = IMAP_MESSAGE_CONTAINS8BIT; goto ph_error; - } else { + } else if (munge8bit) { /* We have been configured to munge all mail of this form. */ c = 'X'; diff -Naur cyrus-imapd-2.2.4.orig/lib/imapoptions cyrus-imapd-2.2.4/lib/imapoptions --- cyrus-imapd-2.2.4.orig/lib/imapoptions Wed May 5 20:53:09 2004 +++ cyrus-imapd-2.2.4/lib/imapoptions Thu May 20 19:15:23 2004 @@ -454,6 +454,12 @@ { "mboxlist_db", "skiplist", STRINGLIST("flat", "berkeley", "skiplist")} /* The cyrusdb backend to use for the mailbox list. */ +{ "munge8bit", 1, SWITCH } +/* If enabled, lmtpd munges messages with 8-bit characters. These characters + are changed to . If \fBreject8bit\fR is enabled, setting \fBmunge8bit\fR + has no effect. (A proper soultion to non-ASCII characters in headers is + offered by RFC 2047 and its predecessors.) */ + # xxx badly worded { "mupdate_connections_max", 128, INT } /* The max number of connections that a mupdate process will allow, this @@ -654,9 +660,7 @@ { "reject8bit", 0, SWITCH } /* If enabled, lmtpd rejects messages with 8-bit characters in the - headers. Otherwise, 8-bit characters are changed to `X'. (A - proper soultion to non-ASCII characters in headers is offered by - RFC 2047 and its predecessors.) */ + headers. */ { "rfc2046_strict", 0, SWITCH } /* If enabled, imapd will be strict (per RFC 2046) when matching MIME diff -Naur cyrus-imapd-2.2.4.orig/man/deliver.8 cyrus-imapd-2.2.4/man/deliver.8 --- cyrus-imapd-2.2.4.orig/man/deliver.8 Sat May 25 21:57:47 2002 +++ cyrus-imapd-2.2.4/man/deliver.8 Thu May 20 19:15:23 2004 @@ -147,8 +147,10 @@ Accept messages using the LMTP protocol. .SH NOTES Depending on the setting of \fBreject8bit\fR in \fBimapd.conf(5)\fR, deliver -either rejects messages with 8-bit-set characters in the headers or -changes these characters to `X'. +either rejects/accepts messages with 8-bit-set characters in the headers. +If we accept messages with 8-bit-set characters in the headers, then depending +on the setting of \fBmunge8bit\fR, these characters are either left un-touched +or changed to . This is because such characters can't be interpreted since the character set is not known, although some communities not well-served by US-ASCII assume that those characters can be used to represent characters not