[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 137106] Moving of imported (text) mails into IMAP folders fails
From:       Andreas Gungl <a.gungl () gmx ! de>
Date:       2006-11-13 9:24:28
Message-ID: 20061113092428.16867.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=137106         
a.gungl gmx de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From a.gungl gmx de  2006-11-13 10:24 -------
Based on your descriptions I can explain what happens:

You save a message as file. KMail uses the "mbox" format when storing the message in \
a file. (KMail is even able to store more / all messages of a folder in a file.) Mbox \
means an additional "From" line at the beginning of each message. That line has no \
colon after "From", and it is no header.

You import that file as "Plain formatted". The import treats the file as a valid \
message and leaves the "From" line at the start in the message. From the POV of the \
import, this is correct. However, KMail ends up with an invalid message in the \
created folder. If you re-export the message, you'll end up with a second From line \
in the created file in mbox format as KMail doesn't check the message for format \
errors but simply adds the line.

The problem is the import which should have been done using the "mbox" format option. \
If you use that option to import the file, the leading From lines are stripped. This \
is expected behavior and works fine.

After all, it's you choosing the wrong format in the import program. The question is \
how KMailCVT can be improved to detect such problems. It might be able to warn the \
user. I'll close that report as Invalid, as KMail can't be blamed here for having \
problems with an injected invalid message. Solving this in KMail would mean to check \
each message again and again for possible modifications and format errors which would \
end up in a really dramatic performance drop.

However, you can file a report against KMailCVT for an improvement of the import \
process. There, it would make sense to add checks or deal with possibly wrong \
selections of the users.


[prev in list] [next in list] [prev in thread] [next in thread]