Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Unable to save mail in cyrus imapd #2828
Reported by felfert on 2 May 2010 11:43 UTC as Trac ticket #1486712
I'm using cyrus (2.3.7) and am trying to get RCMail 0.4-beta running.
In order to show CR and LF in the logs, i instrumented the existing logging slightly (now shown as \r and \n respectively). This change is attached in the first attachment (imap-debug.patch).
Will attach more stuff after submission ...
Comment by felfert on 2 May 2010 12:59 UTC
Description of the attached logs:
All Logging was done via syslog with my patch imap-debug.patch applied.
default-setup.log was created by composing a mail with a text attachment in HTML mode and hitting the "save" button. It can be clearly seen, that the default delimiter (automatically assigned to "\n") is utterly wrong and results in cyrus's response "NO Message contains bare newlines".
manual-delimiter.log was created by the same action after changing
$rcmail_config['mail_header_delimiter'] = "\r\n";
In this case, almost all content is sent correctly, except for two linefeeds in the plain-text part.
manual-delimiter-textonly.log finally shows success.
The problem is twofold:
Will report more findings when I have debugged the issue further ...
Comment by felfert on 2 May 2010 14:16 UTC
I just attached htmlmail-save-delimiterfix.patch which fixes the error seen in the testcase shown in manual-delimiter.log.
Comment by felfert on 3 May 2010 08:31 UTC
Replying to alec:
Comment by rgalps on 12 May 2010 17:27 UTC
I'm having a pretty much identical issue with 0.4-beta and cyrus imap, but instead of when saving a message, it occurs when sending a message that has an attachment:
May 12 18:08:06 mta1 roundcube: 18:08:06 +0100: User email@example.com [Message for xxx@xxx; 250: 2.0.0 Ok: queued as D058416D7
The error returned from cyrus is: "a NO Message contains bare newlines".
I've applied the patch suggested here (even thought it only seems valid for HTML emails) - it's had no affect, same problem. Doesn't matter what the attachment is (I've tried a tiny text file with 'hello' in it, and a 12MB file) always the same error. Save case with HTML / Plain Text emails.
I can provide a test IMAP account to replicate the issue if required.
Please let me know if any further is needed.
Comment by felfert on 12 May 2010 19:14 UTC
Replying to rgalps:
Comment by rgalps on 12 May 2010 19:24 UTC
Replying to felfert:
I can confirm that the patch does fix the issue as long as you have the mail_header_delimiter set - that was the step I was missing.
Hopefully this can be fixed a bit more eloquently so we don't have to manually set that config param in a later release.
Comment by felfert on 12 May 2010 20:33 UTC
Replying to rgalps:
I intentionally left that to the core developers. In my opinion, that variable should not be necessary at all (if all targeted IMAP servers stick to RFCs, it could simply be hard coded to "\r\n"). Unfortunately, there is nothing in the SVN commit logs mentioning the reason why it was made configurable in the first place. Anyway, the current implementation of setting it automatically depending on the OS of the host running the PHP script is definitively wrong. If variable at all, the "automatic" should depend on the IMAP server being used.
Comment by @alecpl on 13 May 2010 11:55 UTC
On http://pl.php.net/manual/en/function.mail.php is a note "If messages are not received, try using a LF (\n) only. Some poor quality Unix mail transfer agents replace LF by CRLF automatically (which leads to doubling CR if CRLF is used). This should be a last resort, as it does not comply with RFC 2822." This may be why mail_header_delimiter has been provided. If so, I think we could use "\r\n" everywhere and just convert if needed for mail() function (just right before its use).
Comment by @thomascube on 24 May 2010 12:30 UTC
I agree to Alec's suggestion. Roundcube doesn't know much about the IMAP backend and therefore should stick to RFC. But (fortunately) we know when an installation is using PHP's crappy mail() function and we could react on that by converting CRLF with the value configured in
BTW: it's correct that this mail() function and it's unpredictable behavior was the reason why we introduced the
Comment by mschiff on 2 Sep 2010 14:10 UTC
Sorry if reopening here is wrong, but I got the same issue with 0.4stable.
With the default setting of NULL (auto-detect) of mail_header_delimiter I am not able to store messages having attachments to the Sent folder (Cyrus IMAP)
After setting mail_header_delimiter to "\r\n" it works mostly.
But I found one reproducable case where the problem still occurs:
Looking at the imap debug logs that last header line looks abit odd (opened text file using vi so I can see the different line endings)
^M is a real CR (\r) (vi shows this because it did not convert the file due to existing LF endings)
So it seems RC seems to do some escaping on the last header line... thats why I see "\r\n\r\n" instead of ^M and another one in the next line.
Can anybody confirm?