#944 Enigmail makes Thunderbird 60 unacceptable slow

[Björn Voigt]

If the Enigmail Add-On is activated in Thunderbird, some operations in Thunderbird get very slow.

Opening the new message window:
- with Enigmail activated: around 3 seconds
- without Enigmail activated: around 1 second

Opening an existing message with 5 recipients as new:
- with Enigmail activated: around 19 seconds (the window openes with a busy script message box; the user is asked, if he wants to stop the script chrome://enigmail/content/enigmailMsgComposeOverlay.js:2872
- without Enigmail activated: around 1 secons, no warning

Also changing recipients of a new mail and other operations get much slower with Enigmail activated.

The technical reason is unknown. But with "strace" I see many failed attempts to open cert9.db-journal:

stat("/home/myuser/.thunderbird/1amwr7kn.Default User/cert9.db-wal", 0x7ffdd4ba4280) = -1 ENOENT (No such file or directory)

[Patrick Brunschwig]

The problem is in querying S/MIME certificates (which is the cert9.db file). See also https://sourceforge.net/p/enigmail/forum/support/thread/d17f9408f5/?limit=25#6237

Querying that database (using the standard Thunderbird function for doing this) seems to be very slow if you have many certificates.

As I am using the standard function of Thunderbird for doing that, I currently don't see how I could possibly improve the speed.

[Björn Voigt]

So deleting unneeded certificates will accelerate Enigmail?

Currently I have 10 own certificates and around 200 certificates from other persons. Most persons I do not know and the certificates are expired. Most of them come from Seamonkey, because I converted a Seamonkey profile with the Thunderbird assistant. In fact I use Thunderbird, because Seamonkey got unexaptable slow with the latest Enigmail updates. So this bug also applies for Seamonkey (tested with Seamonkey 2.49.4).

Could you please describe, what Enigmail does, if a new message window is opened? In the forum you say, that isSmimeEncryptionPossible() is frequently called. Why?

[Patrick Brunschwig]

By default, Enigmail does opportunistic encryption. That is, if Enigmail finds keys or certificates for all recipients, it will enable encryption; otherwise it won't. This applies to both OpenPGP and S/MIME.

Thus: when opening a composer window, and whenever you type a recpient into the to/cc/bcc field, then Enigmail will try to determine if the message can be encrypted, and with which protocol (S/MIME or PGP/MIME).

From your description, and also on the forum, it looks like the lookup of email addresses in the S/MIME certificate store is very slow. Querying the OpenPGP keys is much faster - my keyring as more than 1000 keys and works perfectly fine.

You might therefore want to turn off opportunistic encryption ("encrypt if possible"), and enable/disable encryption only manually. You can do this in the Enigmail preferences.

[Björn Voigt]

Thanks for explaining.

Currently I use both S/MIME (with Thunderbird functions) and PGP (with Enigmail). The opportunistic encryption functionally I also use with Thunderbird. It works with disabled Enigmail. But the builtin function seems to be much faster then the opportunistic encryption function of Enigmail. So probably Thunderbird has a faster access to the certificates database compared with the access from the Enigmail Add-On.

I do not know the code good. But may be it is possible to avoid creating a new instance of "Components.interfaces.nsISMimeJSHelper" everytime when this.isSmimeEncryptionPossible() is called?

try {
  if (!gMsgCompose.compFields.hasRecipients) return false;
  Components.classes["@mozilla.org/messenger-smime/smimejshelper;1"]
    .createInstance(Components.interfaces.nsISMimeJSHelper)
    .getNoCertAddresses(gMsgCompose.compFields,
      missingCount,
      emailAddresses);
}
catch (e) {
  return false;
}

[Tiber]

May I revive this thread - I'm facing the exact same problem and it causes severe headaches. We've been using enigmail for over ten years in our community now, so we're relying quite heavily on it. Since encryption has become more en-vogue, more people have started to adopt S/MIME, at the same time.
From my perspective it seems as if everything worked fine until upgrading to enigmail 2.0 - and for the layman it seems as if this was the version where enigmail started to include S/MIME?
The situation currently is seriously unacceptable, as hitting reply-to-all on an email with over 5 recipients, even if no encryption is involved whatsoever (no recipient is signing/encrypting nor has certificates), stalls thunderbird entirely for up to minutes.
I've tried disabling opportunistic encryption, but in 2.0.9 do not find any corresponding option in the preferences or settings. Playing with other options hasn't changed anything.

So, may be naive but in an act of self-defence: how do I disable S/MIME in enigmail completely (thunderbird does a good job itself, with enigmail disabled, so I seem to need enigmail only for pgp)?

Thanks!
-- ts

[Patrick Brunschwig]

The option to disable opportunistic encryption is called "Encrypt if possible", and can be found in the Enigmail Preferences under Sending .

[Björn Voigt]

There is no such option. I found an option "Automatically send encrypted" with the values "Never" and "If possible".

[Patrick Brunschwig]

Set the value to "Never".

[Patrick Brunschwig]

I increased the delay between typing and calling the S/MIME logic depending on the number of certificates.

Could you try the following build and let me know if it slows down Thunderbird less:
https://enigmail.net/download/nightly/enigmail-nightly-enigmail-2.0-branch-all.xpi

[Tiber]

Thanks a lot!

Last tests: with the plugin from the repository reply to all with 12 recipients (no one with any gpg key or S/MIME certificate) stalls the reply window for around 40 seconds, closing the window (discarding changes) stalls TB for about 20 seconds.

With the nightly build taken from the link reply to all for the same email allows me to start typing, then stalls the reply window for around 10 seconds, then seems to work fine. Closing (discarding changes) does not seem to stall anything.

Setting to "Never" removes any delays/stalling ("Confirm before sending" seems to help not to forget to encrypt to people with keys...)

Thanks again!