Sent mail stuck in Draft folder

Description

It’s a random issue and it does not seem related to the IMAP provider: I have several email accounts, all of them are mapped on IMAP. Every time I send an email I have to double check the Draft folder as more often than I’d like to say, my emails are stuck there until I open the email from the Draft folder and hit Send again.
This happens with my Google account, GSuite account and other accounts I am not sure you are bothered with (I’m in italy and use a certified email protocol called PEC for communication with my town/services/gov services).
The issue happens a lot more often when my email has attachments (usually pdf), but that’s the only thing I can notice

To Reproduce…

Steps to reproduce the behavior:

Expected Behavior

My email shouldn’t stick in the Draft folder

Screenshots

Setup

  • OS and Version:
    XUbuntu 20.04
    • Installation Method:
      snap
  • Mailspring Version:
    mailspring 1.10.3 517 latest/stable foundry376✓ -

Additional Context

This happens to me all the time, without any indication that the email has not been sent. I have had several important emails not go through without me noticing for days. It does not matter if it is a reply to an email chain or a new email. It is not consistent whatsoever, as far as I can tell. The last time it happened was to an Outlook account, but I think it affects my Gmail accounts, too.

OS and Version: Manjaro 22.1.0
Installation Method: Arch Linux AUR (using the yay AUR helper)
Mailspring Version: 1.10.8

I just noticed that this is likely the same issue as this one:

The same issue for me on 29 Oct. 2023. Snap version of Mailspring (assume the latest version). Ubuntu 22.04.3 with Gnome 42.9 and Wayland.

It’s April 4th, 2024. I’m running Ubuntu 2204 with the latest version of mailspring and this is still an issue. I’ve had it for 3 years.

June 2024, having the same issue on Pop!_OS 22.04 for several years. I missed sending couple very important mails to a point where I use Mailspring only for reading.