User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0

Steps to reproduce:

When using an email account with only "S/MIME" configured, create a new email or reply to an email. It is configured that the email should be signed automatically.

Actual results:

Thunderbird selects "OpenPGP" instead of "S/MIME". The message can only be sent if "S/MIME" is selected manually.

Expected results:

As before, Thunderbird should select "S/MIME" when using an account with only "S/MIME" configured.

macOS 12.6, Thunderbird 102.3.3 (64-Bit)

For me it works for all new emails but not for replies with additional identities.
And I can't select "Prefer S/MIME" (S/MIME bevorzugen) for additional identities.

Same here, both on an Arch Linux and Fedora Workstation.

The temporary workaround is to create a PGP-Key for the E-Mail-Account and then change the preferred encryption technology to S/MIME.

same on Linux Xbuntu 22.04 and Thunderbird 102.7.1., it does not work for new and for reply emails. It works fine after manual selection of S/MIME

@cni7up94n thanks for the workaround. Thats very helpful.

Looking at all the S/MIME bugs in here I suggest to set "severity" to minor as its a pure usability point.
Seen it for years (at least 3)

With newly created profiles, auto-selecting S/MIME seems to work as expected. This behaviour broke for me after a "Failed to retrieve PGP key" error while sending via another identity of the same profile. The PGP key in question was saved on a not plugged in Yubikey.

Since this incident, one of my machines displays the behaviour described in this bug while another machine selects S/MIME as expected.

I have to redact my last statement. As soon as there is one identity configured for openPGP, this bug will occur.

Without knowing the code base at all, I did some digging and the reason seems to be that in the snippet below gSelectedTechnologyIsPGP always comes out as true when initially opening a new message window (prevIdentity = Null) without having the workaround present, i. e. configuredOpenPGP = true and therefore evaluating e2etechpref setting. Further checks for SMIME are behind an else if and are therefore not evaluated on first message compose window opening, but only when switching identities.

These should probably be two separate if blocks. One to set gSelectedTechnologyIsPGP = isOpenPGPAvailable; in case of initial opening and a second one to do the more elaborated technology check logic. Closing braces inserted by me.

File: https://hg.mozilla.org/comm-central/file/tip/mail/components/compose/content/MsgComposeCommands.js

if (!prevIdentity) {
    // For identities without any e2ee setup, we want a good default
    // technology selection. Avoid a technology that isn't configured
    // anywhere.
    gSelectedTechnologyIsPGP = isOpenPGPAvailable;
//} <-- insert this to fix
    if (configuredOpenPGP) {
      if (!configuredSMIME) {
        gSelectedTechnologyIsPGP = true;
      } else {
        // both are configured
        let techPref = gCurrentIdentity.getIntAttribute("e2etechpref");
        gSelectedTechnologyIsPGP = techPref != 1;

        // TODO: if !techPref, we might set another flag, and
        // decide dynamically which one to use, based on the
        // availability of recipient keys etc.
      }
    }
  } else if (
    gSelectedTechnologyIsPGP &&
    !configuredOpenPGP &&
    configuredSMIME
  ) {
    // If the new identity has only one technology configured,
    // which is different than the currently selected technology,
    // then switch over to that other technology.

    // However, if the new account doesn't have any technology
    // configured, then it doesn't really matter, so let's keep what's
    // currently selected for consistency (in case the user switches
    // the identity again).
    gSelectedTechnologyIsPGP = false;
  } else if (
    !gSelectedTechnologyIsPGP &&
    !configuredSMIME &&
    configuredOpenPGP
  ) {
    gSelectedTechnologyIsPGP = true;
  }

Thanks fumasu. You found the correct place that needs a fix, but I think we'll need a slightly different fix.
I'll mark this one as a duplicate of another bug, in which I want to fix this issue.