Hello, Here is the case: Cyrus IMAPd is annoyingly strict when it comes to following RFC's. For example, if a message contains NUL characters or "bare" newlines (only "\n", not "\r\n"), it gets rejected. There is no configuration option in imapd.conf for tuning this behaviour. This can be very problematic in several cases: - Broken MUAs sending out non-standard messages. Cyrus developers tell us "not to send broken messages", but unfortunately this does not apply in real world. Many webmails, press releases and so on are sent out in more or less malformed form. - During migration from some other mail system to Cyrus. Especially if you're doing IMAP-->IMAP copy (so one can preserve the message flags, such as \SEEN), things get nasty. You have to either massage the messages in the old server and fix them to be RFC-compliant before migration or patch the Cyrus to be more forgiving. Otherwise you will not be able to transfer your old mailboxes. It's possible to partially tackle this problem by using some content filter at SMTP level and replace all the illegal stuff to be RFC-compliant, but I think that is very unnecessary overhead. Postfix is very fast without any external content filtering, but not so fast if it has to spawn (for example) /usr/bin/tr for every message. Due to structure of Postfix, it's not currently possible to remove NULs via a more light regexp mapping. Thus I suggest a new USE flag ("allownonstandard", perhaps?), which would add a new configuration option to imapd.conf. I'll leave the actual coding to you Gentoo wizards :), but this should help you to get started. After the patch below I was able to migrate even a very broken mailbox (my spam folder with 15 000 messages) from an old uw-imapd to Cyrus. The patch below relaxes Cyrus behaviour, allowing it to pass through messages with both NUL characters and bare newlines. Still needed is the configuration option and documentation part for it. --- --- imap/spool.c.original 2006-01-12 11:11:36.000000000 +0200 +++ imap/spool.c 2006-01-12 11:12:42.000000000 +0200 @@ -433,2 +432,0 @@ - r = IMAP_MESSAGE_CONTAINSNULL; - continue; /* need to eat the rest of the message */ @@ -438,2 +435,0 @@ - r = IMAP_MESSAGE_CONTAINSNULL; - continue; /* need to eat the rest of the message */ @@ -457,2 +452,0 @@ - r = IMAP_MESSAGE_CONTAINSNULL; - continue; --- imap/message.c.original 2006-01-12 11:24:00.000000000 +0200 +++ imap/message.c 2006-01-12 11:27:27.000000000 +0200 @@ -241 +241 @@ - if (n != strlen(buf)) r = IMAP_MESSAGE_CONTAINSNULL; + /* if (n != strlen(buf)) r = IMAP_MESSAGE_CONTAINSNULL; */ --- imap/message.c.original 2006-01-16 09:24:42.000000000 +0200 +++ imap/message.c 2006-01-16 09:24:51.000000000 +0200 @@ -248 +248 @@ - if (!sawcr) r = IMAP_MESSAGE_CONTAINSNL; +/* if (!sawcr) r = IMAP_MESSAGE_CONTAINSNL; */
Created attachment 78716 [details] Modified ebuild for cyrus-imapd Modified ebuild with a new flag, "unsupported_allownull", in concordance with the previous "unsupported_8bit"; it depends on next attachment.
Created attachment 78717 [details, diff] Patch allowing emails with NULL in them to go through
With postfix 2.3 (coming soon), there is a "message_strip_characters" parameter that let postfix strip those NUL characters out or configure it to reject with "message_reject_characters". Would that work for you?
(In reply to comment #3) > With postfix 2.3 (coming soon), there is a "message_strip_characters" parameter > that let postfix strip those NUL characters out or configure it to reject with > "message_reject_characters". Would that work for you? Yes, that should be a reasonable way to fix this issue. You may resolve this bug at will. Thank you!
postfix 2.3 and according ebuilds are out, so maybe that one could be close ?
(In reply to comment #5) > postfix 2.3 and according ebuilds are out, so maybe that one could be close ? > and this one too. Thanks, Tuan
