Backported to 2.2 but not yes tested with 2.2

Sorry, I just found out, that windows caps the filename earlier than max length, so my former tests were invalid.

All mails touched by gpgol should already have a GPGOL_UID_DASL. So to replicate:

1. Send a new encrypted mail (e.g. Edward -> Ted)
2. Don't open that mail, but open the context menu: Move -> Other Folder ...
3. Select a subfolder of INBOX and click OK -> the mail is not moved

Tested with VS-Desktop-3.3.90.8-Beta and the test gpgol.dll from 2025-09-10 and the same test mail from the original report:
The spawning does not occur any more. (Tested with Outlook setting "show as text only" and without.)

Andre mentioned in 10721b1dccf4 that "Closing the mail this early might also have contributed to
endless loops of read + close" which is what we see here as well

How to test this? The follwing happens for an attachment of an encrypted mail on gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10:

Moving an encrypted message on Gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10 into an inbox subfolder of Ted.Tester and back works for me, too. Does this confirm, that it's working now?

re 1: Only if the option --auto-key-upload is used/configured.
re 2: Do not configure --auto-key-upload but give it on the command line.
re 3: Do not use --auto-key-upload - maybe I should add a --no-auto-key-upload option.

Hi
I have some questions about the "auto-key-upload: If an LDAP keyserver is configured (in dirmngr), upload a newly created key directly to that server" feature:

1. If an LDAP keyserver is configured, will every newly created key be uploaded? Is this upload behavior enabled by default?
2. Even with an LDAP keyserver configured, what if we don’t want to upload by default? If we prefer manual approval or want to upload only a specific subkey, how should we handle that?
3. What about keys created for testing, temporary use, or personal privacy-sensitive purposes that we don’t want others to discover?

People who use GPG tend to care deeply about privacy and don’t want to upload or expose unnecessary information.

The culprit seems to be commit rO6cb4ccf4d8db03e9922984d9c5f5bf7f8806954d but a brief inspection does not show any problematic code. Thus this might be due to an Outlook peculiarity.

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10
(tested with 10 restarts)

looks correct

Mostly looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10

nr.1
nr.2
schwarz
weiß

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10

works in vsd3.3.3, tested with VS-Desktop-3.3.90.8-Beta

The gold rule of tab order is that tab order follows the usual reading direction, i.e. line by line from left to right. If you press Enter after entering the password in the first input field then the focus should jump to the second input field.

Looks good to me on gpg4win-5.0.0-beta357 @ win10:

The fix should be available in gpg4win-5.0.0-beta350.