Environment: Thunderbird Portable 9.0.1 on Windows XP Pro (32 bit).
Thunderbird Portable is run from the local hard drive (not from a USB one).
Thunderbird Portable has been upgraded from earlier versions gradually.
Scenario:
Installed automatically (from TERENA Personal CA) a personal certificate in Firefox Portable 9.0.1. I created certificate backup and imported into Thunderbird Portable (9.0.1), then I enabled in an account signing and encryption using this certificate. The account includes copied mail. Signed messages sent using this account cannot be verified.
THIS PROBLEM DOES NOT OCCUR WITH A FRESH INSTALLATION OF THUNDERBIRD (NOT PORTABLE). It also does not occur with other mail clients (e.g. MS Outlook).
However, using other certificates, like the ones generated here: https://digitalid.verisign.com/client/class1Netscape.htm, we can create verifiable messages. (Edit: This, after subsequent investigation, seems irrelevant. The problem is with the account, not with the certificate.)
Why Thunderbird Portable cannot send a signed mail message which can be verified successfully, when mail folders have been copied (migrated) from elsewhere (another TB installation)? And why this does not happen in Thunderbird (standalone)?
Any advice?
Thanks,
Nick
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
New test showed that this problem does not occur with a fresh installation of Thunderbird Portable (9.0.1).
Could something in the installation have missed upgrade or got broken during such procedures?
How can I "refresh" (the security library ?) of my gradually upgraded installation of Thunderbird Portable to help avoid this situation?
Thanks,
Nick
I have tried multiple times to do a clean TB Portable installation. As soon as I create a new account and import my certificate, I can sign messages and they are successfully verified (by the recipient).
Yet, when I manually copy in the Mail directory of the new account (e.g. in Mail\pop.example.com) all my (many!) mail folders from the respective Mail directory of my current TB installation (note: named differently, e.g. Mail\mail.example.org) in order to do a full migration, everything works, but signed messages fail verification at the recipient end.
It happens like that every time with TB Portable. It does not happen with TB Standard (Normal version). There is no issue there.
Why TB account with all my (older, copied) mail behaves differently than a clean one (in TB portable)?
but as I also use certs with TB, I can try to think what may cause such behaviour.
I have to say first, that for long time the only reliable TB which worked with certs was version 2.x
OK now, certs are tightly coupled with the e-mail identity, that means the name and the e-mail address has to be exactly as stated in the cert. If this goes wrong then results will be bad.
As you say the issue arises first when all parts of the mail folder is imported and not before (!) I would say that one of the mail accounts is picked when signing and in fact it should not.
How many mail accounts do you have in the full mail folder?
Do you have with some accounts more then one identity?
What I would try as next:
have solid backup of all profile etc somewhere
import whole mail folder into the freshly set up TB portable.
Problem will come up
Then delete from that install mail accounts and their respective local folders and identities one by one and see if you can clear the problem.
Also close search in the signed received mail may give some traces as what is going wrong.
First what does the cryptomodule say? Why is it not verified? Is it signed with the right key?
Or is it signed with a key which does not belong to the apparent sender?
Or is it just that the mail was mutilated under way? (Sender and signer are correct, but hash does not correspond)
When you look at the source of the mail, is the sender there exactly corresponding to the data in the certificate used?
Next test:
try mails as plain text only, no fancy formating, here you might see more then when all is obscured by some invisible html formating!
You could also try to disable the certificate signing in some accounts, as you say you have more then one apparently.
-----
>(e.g. in Mail\pop.example.com) all my (many!) mail folders from the respective Mail directory of my current TB installation (note: named differently, e.g. Mail\mail.example.org) in order to do a full migration,
Otto Sykora
Basel, Switzerland
Thanks for the reply.
Let's see the steps one by one:
1. I do a clean TB Portable install.
2. I create an account (POP) and I import a personal certificate. So TB now has one account only with one identity only.
3. I send signed messages from that account without problems, and they are verifiable from the recipient. (Expected behavior)
4. The above account TB Mail folder is:
"c:\mytb\Data\profile\Mail\mail.example.com".
The folder contains:
11/01/2012 07:54 μμ . 11/01/2012 07:54 μμ .. 11/01/2012 02:53 μμ 0 Inbox 11/01/2012 07:53 μμ 2.179 Inbox.msf 11/01/2012 07:52 μμ 22.476 Sent 11/01/2012 07:54 μμ 3.732 Sent.msf 11/01/2012 02:53 μμ 0 Trash 11/01/2012 03:28 μμ 1.337 Trash.msf 6 File(s) 29.724 bytes5. Now I delete the above files and I copy my mail folders from my current installation. Here is the new content:
11/01/2012 08:08 μμ . 11/01/2012 08:08 μμ .. 31/03/2011 08:05 πμ 0 Archives 11/01/2012 10:34 πμ 2.970 Archives.msf 11/01/2012 10:21 πμ Archives.sbd 15/11/2011 11:16 πμ 191.555 Bind-DLZ 11/01/2012 10:08 μμ 16.275 Bind-DLZ.msf 10/12/2010 09:31 μμ 181.394.656 Clips 1 23/10/2011 12:26 μμ 42.029 Clips 1.msf 12/01/2012 08:51 πμ 90.493.348 Cron Jobs 12/01/2012 08:51 πμ 1.084.926 Cron Jobs.msf 11/01/2012 07:49 μμ 4.109 dir.txt 11/01/2012 08:13 μμ 1.498 dir.txt.msf 10/12/2010 09:29 μμ 13.487.286 Documents 23/10/2011 12:20 μμ 4.135 Documents.msf 12/01/2012 08:51 πμ 27.013.956 Dovecot 12/01/2012 08:51 πμ 4.871.311 Dovecot.msf 12/01/2012 10:13 πμ 26.263.673 Drafts 12/01/2012 10:16 πμ 517.063 Drafts.msf 10/12/2010 09:29 μμ 51.682.632 DS 19/12/2011 10:12 μμ 8.509 DS.msf 19/11/2008 02:02 μμ 0 Faxes 22/12/2011 04:11 μμ 3.368 Faxes.msf 12/11/2008 09:43 πμ 80 filterlog.html 11/01/2012 11:32 μμ 6.647.920 horde 11/01/2012 11:34 μμ 892.597 horde.msf 12/01/2012 10:28 πμ 2.337.282.112 Inbox 12/01/2012 10:29 πμ 11.486.118 Inbox.msf 11/01/2012 10:21 πμ Inbox.sbd 20/07/2010 02:43 μμ 31.375 Infected Items 22/12/2011 01:00 μμ 3.781 Infected Items.msf 12/01/2012 08:51 πμ 107.370.152 IronPort Reporting 12/01/2012 08:51 πμ 227.638 IronPort Reporting.msf 12/01/2012 09:09 πμ 7.315.633 Junk 12/01/2012 10:35 πμ 21.926 Junk.msf 12/01/2012 08:51 πμ 18.125.618 Logwatch 12/01/2012 10:10 πμ 3.171.763 Logwatch.msf 12/01/2012 10:11 πμ 412.290 Maia 12/01/2012 10:11 πμ 35.762 Maia.msf 12/01/2012 08:51 πμ 43.295.579 Mondo 12/01/2012 08:52 πμ 982.186 Mondo.msf 02/01/2012 10:31 πμ 3.182 msgFilterRules.dat 02/09/2003 05:48 μμ 0 n@eo 09/10/2011 01:33 μμ 3.275 n@eo.msf 11/01/2012 10:21 πμ n@eo.sbd 10/01/2012 11:00 πμ 3.314.850 NetDisco 11/01/2012 10:34 πμ 277.215 NetDisco.msf 10/06/2011 10:55 μμ 17.405.395 Network 21/12/2011 04:47 μμ 8.415 Network.msf 11/01/2012 07:23 μμ 656.226 nfsen 11/01/2012 08:08 μμ 30.868 nfsen.msf 11/01/2012 12:23 πμ 647.322 OpenDKIM 11/01/2012 12:26 πμ 86.013 OpenDKIM.msf 09/04/2011 10:47 πμ 70.673 OpUtils 11/01/2012 12:22 πμ 13.020 OpUtils.msf 12/01/2012 09:09 πμ 8.883.398 Pdns 12/01/2012 09:09 πμ 1.318.409 Pdns.msf 30/12/2011 04:09 μμ 188.003.418 Photos 30/12/2011 04:09 μμ 35.016 Photos.msf 12/01/2012 08:51 πμ 20.639 popstate.dat 12/01/2012 08:51 πμ 58.104.474 Postfix 12/01/2012 10:10 πμ 6.298.864 Postfix.msf 11/01/2012 08:31 μμ 4.222.127 ProFTPd 11/01/2012 09:37 μμ 313.430 ProFTPd.msf 10/12/2010 09:30 μμ 20.389.369 Promo 07/10/2011 11:15 μμ 5.549 Promo.msf 11/01/2012 08:23 μμ 717.661.083 Sent 11/01/2012 09:42 μμ 4.208.575 Sent.msf 24/10/2011 10:10 πμ 1.965.419 Squid 11/01/2012 10:34 πμ 318.936 Squid.msf 12/01/2012 10:12 πμ 766.607 Squirrelmail 12/01/2012 10:12 πμ 30.185 Squirrelmail.msf 01/08/2003 10:17 πμ 0 Templates 11/01/2012 10:34 πμ 2.503 Templates.msf 12/01/2012 10:11 πμ 6.807.691 Trash 11/01/2012 06:03 μμ 74.571 Trash.msf 29/11/2011 12:22 μμ 0 work folder 05/12/2011 08:44 μμ 2.641 work folder.msf 73 File(s) 3.976.335.187 bytes6. Now we have the initial clean installation, with the initial one account, its certificate and the same (one) identity; the only difference is that we have replaced mail folders/files. The certificate is always the same, the account sender address still matches one of the email addresses included in the Certificate's Subject Alt Name Extension.
7. Now, I send signed messages from this account and they cannot be verified at the recipient end. (Verification fails.)
8. If I follow the same steps in Thunderbird standalone, this issue does not occur. I can still send signed messages after having copied the above mail folders/files, and they are verified successfully by the recipient.
9. In all tests I send ISO-8859-1 messages to avoid charset issues.
10. When I receive one of such signed messages (bcc'd) to my own TB Portable (the one that send the message), TB does not give any indication that there is a verification problem. The cert is the right one, the mail sender address matches one of the addresses in the Certificate Subject Alt Name extension. (Note: There is no E attribute in the Certificate Subject.) TB's "Message Security" box displays as the email address the first of those included in the Certificate Subject Alt Name and shows the message: "This message includes a valid digital signature. The message has not been altered since it was sent." Yet, ALL RECIPIENTS (except me) cannot verify the message successfully.
I repeat that this issue does not occur, if the above steps are followed in a TB standalone installation. It only occurs with TB Portable.
11. For example, here is a verification effort on a linux mail server (upon a signed message I sent, lying in an IMAP mailbox of a recipient):
I repeat that my TB Portable seems to be verifying the message correctly!
12. By contrast, here is a successfully verified message:
I hope the above can help in resolving this issue.
Nick
but, you state that you can verify well your copy.
Now it would be nice to know what does the recipients client refuse or what it claims is wrong?
Can you receive with some other computer, other address etc?
Is the message mutilated or does the account not match? This has to be found out now as next.
Then as I said, I would delete the accounts one by one and see if the things improve. It still can be that one of the added accounts is interfering somehow.
Also check the ability to send all in plain text in contrary to html etc.
Check the formating of each account, particularly where same name etc is used.
what operating system and what mail client is on the other side?
you can also try to contact me via myusername(at)usa(dot)net
then we can exchange public keys and I will try to verify with more then one client.
Otto Sykora
Basel, Switzerland
>Verify error:unsupported certificate purpose
Otto Sykora
Basel, Switzerland
I have confirmed that the problem occurs only when I send mail from a TB Portable account with migrated/copied folders/mails (as I described above) AND ONLY when the recipient is checking the mail using OpenSSL.
So, if the recipient is verifying with Thunderbird (any version) on Windows or Outlook, verification works fine.
However, if the recipient is verifying using OpenSSL directly (command line) or indirectly (e.g. in Thunderbird/Linux or in Squirrelmail with SMIME plugin or in Horde with S/MIME enabled), then verification fails.
I can't explain this behavior, but that is what's happening!
(I'll send a direct mail as well for testing).
Nick
Following ottosykora's advice, I deleted ALL cert selections from the security settings of ALL accounts, then deleted ALL my personal certificates themselves.
Finally, I deleted the file cert8.db.
Then I re-imported my key pair and configured the security settings (cert selections) in the involved account.
Thus, signing works well at last.
After MANY hours of testing, I still can't tell exactly what causes things to break.