If an email contains more than one CC header, only the first one is viewed. Reproducible: Always Steps to Reproduce: Open the following mail: From userFrom@server.org Mon Nov 23 15:23:30 2015 Return-Path: <userFrom@server.org> From: From User <userFrom@server.org> To: To User <userTo@server.org> Subject: The subject CC: First User <user1@server.org> CC: Second User <user2@server.org> CC: Third User <user3@server.org> Date: Mon, 23 Nov 2015 16:23:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Mail body. Actual Results: Only First User <user1@server.org> is viewed in CC. Expected Results: First User <user1@server.org>, Second User <user2@server.org>, Third User <user3@server.org> shall be viewed in CC. Console output of “kmail --version”: kmail2 5.0.3 Console output of “kmail” after opening the mail via “File/Open…”: log_kmail: url : QUrl("") couldn't create slave: "Unable to create io-slave:\nklauncher said: Unknown protocol 'kfiledialog'.\n" KSambaShare: Could not find smb.conf! "/subscriber/kmail2_4944_mWQqPp" connectToServer "/tmp/akonadi-toni.fYWxag/akonadiserver.socket" "/subscriber/kmail2_4944_29JLH1" connectToServer "/tmp/akonadi-toni.fYWxag/akonadiserver.socket" "/subscriber/kmail2_4944_AaX2gW" connectToServer "/tmp/akonadi-toni.fYWxag/akonadiserver.socket" "/subscriber/kmail2_4944_LOQYy1" connectToServer "/tmp/akonadi-toni.fYWxag/akonadiserver.socket" this does not work on a KActionCollection containing actions! org.kde.akonadi.ETM: GEN true false true org.kde.akonadi.ETM: collection: QVector() org.kde.akonadi.ETM: GEN true false true org.kde.akonadi.ETM: collection: QVector() org.kde.akonadi.ETM: GEN true false true org.kde.akonadi.ETM: collection: QVector() Connected to "Akonadi" , using protocol version 51 Server says: "Not Really IMAP server" Connected to "Akonadi" , using protocol version 51 Server says: "Not Really IMAP server" Connected to "Akonadi" , using protocol version 51 Server says: "Not Really IMAP server" Connected to "Akonadi" , using protocol version 51 Server says: "Not Really IMAP server" log_messageviewer: Node UNprocessed: 0x24434a0 log_messageviewer: Node UNprocessed: 0x24434a0 log_messageviewer: ======================================== "<div class=\"noquote\"><div dir=\"ltr\">Mail body.</div><br/></div>" ====================================== log_messageviewer: SET NODE: 0x24434a0 true log_messageviewer: Node processed: "" "Content-Type: text/plain; charset=\"utf-8\"" log_messageviewer: KMMsgEncryptionState: 78 log_messageviewer: KMMsgSignatureState: 78 org.kde.akonadi.ETM: Subtree: 89 QSet(89, 90, 96) org.kde.akonadi.ETM: Subtree: 129 QSet(129, 131, 130, 134) org.kde.akonadi.ETM: Subtree: 12 QSet(12) org.kde.akonadi.ETM: Subtree: 1 QSet(136, 135, 1) org.kde.akonadi.ETM: Fetch job took 121 msec org.kde.akonadi.ETM: was collection fetch job: collections: 11 org.kde.akonadi.ETM: first fetched collection: "Search" org.kde.akonadi.ETM: Subtree: 119 QSet(119) org.kde.akonadi.ETM: Subtree: 89 QSet(101, 100, 89, 90, 94, 99) org.kde.akonadi.ETM: Subtree: 129 QSet(129, 131, 130, 134) org.kde.akonadi.ETM: Subtree: 12 QSet(12) org.kde.akonadi.ETM: Subtree: 1 QSet(136, 135, 1) org.kde.akonadi.ETM: Fetch job took 126 msec org.kde.akonadi.ETM: was collection fetch job: collections: 15 org.kde.akonadi.ETM: first fetched collection: "Search" org.kde.akonadi.ETM: Subtree: 125 QSet(125) org.kde.akonadi.ETM: Subtree: 14 QSet(14) org.kde.akonadi.ETM: Fetch job took 126 msec org.kde.akonadi.ETM: was collection fetch job: collections: 2 org.kde.akonadi.ETM: first fetched collection: "Notes"
This bug has never been confirmed for a Kontact version that is based on KDE Frameworks, except possibly a Technology Preview version 5.0.x. Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the opportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it. Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12, preferably more recent), please open a new one unless it already exists. Thank you for all your input.