mbox import 'loses' emails

[JNicoll]

Prerequisites

• [X] I have searched for duplicate or closed issues
• [ ] I can recreate the issue with all plugins disabled

Describe the issue

I'm using RC v1.6.5 which is installed on my mail provider's servers. I am not able to tweak how it is setup.

I have several mailboxes with this provider ... which is to say that I need to login to each of them separately in RoundCube.

I'm about to remove two of these mailboxes, so a few days ago I used RC's option to select, one folder at a time, the emails in each mailbox, then click "More...", "Download...", "Mbox format (.zip)".

Then, as a 'check' I unzipped each of these on my PC, then opened the mbox file in my text editor and used a regex pattern to count the well-formed inter-mail delimiters. For each such file the count of the delimiters matched the number of emails I'd seen in the source folder when I exported its mails, helping me be sure that every email had been exported.

Later, logged into the destination mailbox, I used the import option for each source folder, uploading the ".zip" files, ie NOT the mbox text files (just in case something about them having been accessed in a Windows text editor might have altered line endings or something).

In two instances the number of emails resulting from the import was smaller than the number that had been in the source folders.

I don't know how to tell whether the problem lies in the way that RC generated the mbox files during export, or in the way that it parses those during import.

In the instances I looked at, the symptom was that RC had failed to detect the end of one email (when importing data) so when I looked at such a mail via RC, I saw what seemed to be hundreds of lines of sig text, being the usual sig seperator, and content, followed by the headers and contents of the next email from the import file.

Looking at the import file in a text editor (on Windows), it's clear that the file does not have a blank line after such mails' sig lines before the delimiter line.

In the two instances I've seen, the email whose end is not delimited properly has been, both times, a copy of an email that I sent, rather than an incoming one.

That makes me wonder if the sig stored for my identities and thus used when I wrote the outgoing emails in the first place doesn't end in CRLF (or LFCR ?) when it should do? Perhaps when such an email is sent SMTP makes sure the email's end is marked properly (or there is a byte count involved) but the "log copy" stored on my provider's server maybe doesn't have the right ending ... and thus generation of the export file is incorrect.

What browser(s) are you seeing the problem on?

Firefox

What version of PHP are you using?

No response

What version of Roundcube are you using?

v1.6.5

JavaScript errors

No response

PHP errors

No response

[JNicoll]

Screenshots - what I see in RC -- note that my sig only contains one line of text - and what the corresponding part of the import file contained

[alecpl]

I'm unable to reproduce. Could you provide a sample. The fragment with these two email messages may be enough. But as a file, not pasted.

[JNicoll]

I don't know my way around this issue tracker; if I upload the actual zipped mbox (which is ~50 KB) is it just you that can see the content? Or do I need to create a test text file with obfuscated content, test that it doesn't import properly on the RC system I use, then upload that?

On other trackers I'd normally PM a URL to you... but that doesn't seem possible here.

[JNicoll]

Link emailed to you.

[alecpl]

Fixed. The missing empty line is not an issue anymore.

[JNicoll]

Thank-you!