Created attachment 85911 [details] output of kmail with wrong signature DHL an important logistics provider in Germany and Worldwide has a new service, they sign their mails s/mime to avoid scams. This is very nice but fails with KMAIL. The signature is shown as invalid. DHL answered as follows: vielen dank für Ihre Information. Wir haben den Sachverhalt von der zuständigen IT-Abteilung untersuchen lassen. Dieses Problem ist uns bereits bekannt und tritt vereinzelt bei älteren E-Mail-Clients (zum Beispiel MS Outlook 2003 / Express) auf. Diese E-Mail-Clients haben gelegentlich Schwierigkeiten mit der verwendeten Technologie (hier: "nested multipart"). Wir arbeiten zur Zeit daran eine Lösung auch für diese Art der Email-Clients bereitzustellen. Now...I hope that we are not on the level of "older email clients like MS outlook/express! They claim the reason is incapacity of the client side to elaborate "nested multpart messages". I think this is an important feature given the size of DHL. Other providers may get more serious on signing too. Possible duplicate by search: 300142 In attachment the output as pdf of the error in kmail
I suggest that this bug may also be related to the following reports: https://bugs.kde.org/show_bug.cgi?id=331991 https://bugs.kde.org/show_bug.cgi?id=322932 https://bugs.kde.org/show_bug.cgi?id=332036 Is it possible to attach a showcase email which fails to validate? Further, can you verify that other clients (e.g. thunderbird) recognize the same email a correctly signed?
showcase email: not from my part sorry (as it was eliminated, I did not even think DHL would reply) but....as they where so compliant, open and friendly (and seem more than interested to get the problem fixed) you could contact them officially from KDE for solving the issue and ask to put their technical staff in contact with you. They will send you any example you may need I am dead sure. Phishing@deutschepost.de is "your man" for so to say. They covered it. The duplicates: I do not use bogofilter (with which I had several issues in the past) but spamassassin. The mail in question was not filtered actively but stayed in the original mailbox. Of course filters where on. Of course the filters work "on and off" like in all kmail versions since the change to akonadi, I have filter logging running (felt since a decade), if it helps you we could see if in the log there is something interesting "the day the thing arrived". As for the signature bug you mentioned (332036), this is for gpg, if this is s/mime that is having identical issues, well I do not know. Hold in mind however that it "must/should" be an issue with html messages (and unfortunately this is practically the only signed s/mime html email I receive in an entire year) because I receive gpg signed messages from Cert-Bund every second day and they are filtered, mangled, classified, rattled, shaken and rock and roll.........and perfectly validly signed at the end of the process. Regards
I believe I may have stumbled on the same issue, I've decided to open an account in a new bank, and their emails display with red border, indicating bad signatures. Enigmail shows them as properly signed. My old bank sends me two types of mail -- short, plain notifications and longer monthly operations sheet. Both of these messages are displayed as properly signed (green). The first is plain text, so no multipart, the second is plain text + attachment (multipart/mixed). Their structure is as follows: └┬╴multipart/signed 8623 bytes ├─╴text/plain 165 bytes └─╴application/pkcs7-signature attachment [smime.p7s] 6322 bytes └┬╴multipart/signed 12013 bytes ├┬╴multipart/mixed 3757 bytes │├─╴text/plain 576 bytes │└─╴text/html attachment [wyciag_140310_0064.html] 2700 bytes └─╴application/pkcs7-signature attachment [smime.p7s] 6322 bytes The mail that doesn't verify properly comes from my new bank from my mobile phone company. Their structure is: └┬╴multipart/signed 16824 bytes ├┬╴multipart/mixed 9015 bytes │├┬╴multipart/alternative 2316 bytes ││├─╴text/plain 11 bytes ││└─╴text/html 1922 bytes │└─╴image/gif attachment [logo.gif] 6350 bytes └─╴application/pkcs7-signature attachment [smime.p7s] 5738 bytes └┬╴multipart/signed 416624 bytes ├┬╴multipart/mixed 408790 bytes │├─╴text/html 3631 bytes │├─╴image/png attachment [obrazek.png] 14070 bytes │└─╴application/octet-stream attachment [Konto_osobiste_potwierdzenie_zlozenia_wniosku.pdf] 390385 bytes └─╴application/pkcs7-signature attachment [smime.p7s] 5738 bytes └┬╴multipart/signed 2035149 bytes ├┬╴multipart/mixed 2027351 bytes │├┬╴multipart/alternative 19378 bytes ││├─╴text/plain 9492 bytes ││└─╴text/html 9491 bytes │├─╴application/pdf attachment [TOiP konta osobiste.pdf] 493338 bytes │├─╴application/pdf attachment [Oswiadczenie o odstapieniu.pdf] 118304 bytes │├─╴application/pdf attachment [Regulamin obslugi produktow Alior Sync.pdf] 990750 bytes │├─╴application/pdf attachment [iKonto_umowa_zintegrowana.pdf] 383735 bytes │├─╴application/pdf attachment [obrazek.png] 14070 bytes │└─╴image/gif attachment [Sync.gif] 6350 bytes └─╴application/pkcs7-signature attachment [smime.p7s] 5738 bytes └┬╴multipart/signed 186026 bytes ├┬╴multipart/mixed 181229 bytes │├┬╴multipart/related 101720 bytes ││├─╴text/html 4567 bytes ││├─╴image/jpeg [playLogo.jpg] 2962 bytes ││├─╴image/jpeg [awizo3.jpg] 3124 bytes ││└─╴image/jpeg [awizo1.jpg] 90470 bytes │└─╴application/pdf attachment [6303039_K_00000879_03_14_K.pdf] 79151 bytes └─╴application/pkcs7-signature attachment [smime.p7s] 2926 bytes All of the above verify as proper in Thunderbird/Enigmail. I was able to extract the signature and message from my old bank's messages and verify them on the command line with gpgsm, the same procedure seems not to work with the other messages -- the hash seems to be corrupt.
As the information in the e-mails above is semi sensitive, I can post only the first one here. As this is an invitation to open a bank account, I can send it to anyone when provided with an address, if necessary.
Created attachment 86089 [details] X.509 signed message with a signature that validates in thunderbird, but not in KMail.
I added two X.509 signed files -- one is an eml file from Roundcube (which signature I am able to verify on the command line) and another that is saved from kmail (which has an invalid hash due to some blank lines being added).
Created attachment 86113 [details] Original e-mail with signature
Created attachment 86114 [details] The same e-mail as saved by kmail (invalid signature)
Probably, Bug #334066 describes the very same problem. I attached two sample emails there, one from the German department for security in information technology and one from the PGP global directory verification service, which both are shown as signed invalidly by KMail. I hope this helps …
Please make (In reply to Tobias Leupold from comment #9) > Probably, Bug #334066 describes the very same problem. Please do not miy the both bugs: * This one is about smime signatures. * #334066 is about pgp signatures. Actually it is hard for me as dev to get the relevant information. So many thanks for uploading sample mails. That make me easy to test. Did you upload only messages with valid signatures? Do they all be valid in thunderbird? https://bugs.kde.org/attachment.cgi?id=86114 - What did you done here? Please add comments to all attachments what is expected, where you test it...
The file https://bugs.kde.org/attachment.cgi?id=86113 is an eml file saved from under the webmail client Roundcube ("Save as EML"). The other file (https://bugs.kde.org/attachment.cgi?id=86114) is the same mail, but now normally fetched by KMail and saved as EML in KMail. Although I do not remember the procedure, the first file passes validation ont the command line and in Thunderbird, the second one does not pass the validation. If one opens the first file in KMail, its signature isn't validated, probably because KMail mangles the content. Diff shows that these files differ only slightly by a few empty lines.
Git commit abca7ffa2be4664bfeee381a08532bf37fd98bcb by Sandro Knauß. Committed on 13/03/2015 at 20:54. Pushed by knauss into branch 'KDE/4.14'. KMIME: Do not add additional newlines, while parsing mails. If testing the signature status of mails, than nothing is allowed to change. Because the number of newlines, that seperates head and body is not specified. So make sure that at least two are written. Related: bug 332036 FIXED-IN: 15.04 M +9 -6 kmime/kmime_content.cpp M +4 -1 kmime/kmime_header_parsing.cpp M +0 -1 kmime/tests/auto/contenttest.cpp M +23 -3 kmime/tests/auto/messagetest.cpp M +1 -0 kmime/tests/auto/messagetest.h A +49 -0 kmime/tests/data/mails/dontchangemail.mbox http://commits.kde.org/kdepimlibs/abca7ffa2be4664bfeee381a08532bf37fd98bcb
Git commit 90517fa3777615a801236787e11b691480720370 by Sandro Knauß. Committed on 13/03/2015 at 20:54. Pushed by knauss into branch 'KDE/4.14'. KMIME: Do not add additional newlines, while parsing mails. If testing the signature status of mails, than nothing is allowed to change. Because the number of newlines, that seperates head and body is not specified. So make sure that at least two are written. Related: bug 332036 FIXED-IN: 4.14.7 REVIEW: 122933 M +18 -12 kmime/kmime_content.cpp M +4 -1 kmime/kmime_header_parsing.cpp M +0 -1 kmime/tests/auto/contenttest.cpp M +22 -3 kmime/tests/auto/messagetest.cpp M +1 -0 kmime/tests/auto/messagetest.h A +49 -0 kmime/tests/data/mails/dontchangemail.mbox http://commits.kde.org/kdepimlibs/90517fa3777615a801236787e11b691480720370