[MlMt] Composed messages saved to a Drafts mailbox in MM v. 6238 and higher not visible on any other devices

[Henry Seiden]

Played around with alternate Mailboxes and names for an alternate folder 
for Drafts as some here have suggested. Apple devices are pretty 
persnickety about named folders with the word “Drafts” leading off 
and do not recognize them as an IMAP Folder.

Then I found that Drafts Folder contents eventually did show up in 
alternate non MM Apps and mobile devices using the generic Mail app in 
certain servers, so I’m going to check more thoroughly on each account 
with multiple devices.

Respectfully,

Henry Seiden
- -
Techworks Pro Co.
E: info<at>techworkspro<dot>com
W: http://techworkspro.com

On 2 Apr 2025, at 16:11, Henry Seiden wrote:

> Benny,
>
> Was able to delete the encryption and signing in PGP, which seems to 
> have restored operation of v6241 in Drafts Folder>Send. Don’t know 
> if it will affect the crashing issues.
>
> As to Drafts, it is still flaky and not shared to others even when no 
> new Network Framework is enabled. Sorry to say, that is a no-go for my 
> ever using Drafts folder.
>
> Can you tell me if there is a version of MM that supports a shared 
> Drafts folder and how to fall back to that as previously requested? 
> That folder appears to be tightly integrated to composing messages and 
> it doesn’t seems that I can back down from using it when composing a 
> new message. Hence when moving to a different device I lose my work.
>
> Respectfully,
>
> Henry Seiden
> - -
> Techworks Pro Co.
> E: info<at>techworkspro<dot>com
> W: http://techworkspro.com
>
> On 2 Apr 2025, at 9:29, Henry Seiden wrote:
>
>> Benny,
>>
>> Thanks for the interesting explanation and details as regards 
>> encryption/signing of messages affecting Drafts in this way. Never 
>> considered that as a possibility in terms of sharing the contents of 
>> the Drafts folder. Other apps (notably Mail) don’t make that 
>> accommodation (nor make the extensive support for PGP or S/MIME 
>> signing and encryption that MM does). I would call their support 
>> minimal, possibly concerning as security content processing.
>>
>> Respectfully,
>>
>> Henry Seiden
>> - -
>> Techworks Pro Co.
>> E: info<at>techworkspro<dot>com
>> W: http://techworkspro.com
>>
>> On 2 Apr 2025, at 9:14, Benny Kjær Nielsen wrote:
>>
>>> On 2 Apr 2025, at 13:50, Henry Seiden wrote:
>>>
>>>> So, I’m looking for confirmation that this is indeed occurring 
>>>> for all users and for your opinion (assuming you can replicate it) 
>>>> that  you consider this either a bug or some undocumented feature.
>>>
>>> It's likely undocumented, but I think I wrote to you in an earlier 
>>> email that this is expected behavior when signing/encrypting is 
>>> enabled in the composer window. You can call it a bug if you like, 
>>> but this is done to ensure that sending a signed or encrypted email 
>>> from A to B does not involve uploading intermediate unfinished 
>>> versions of the email. It might be a bit theoretical, but one could 
>>> imagine different scenarios for which this would be undesirable.
>>>
>>> I introduced this restriction when I realized that if encryption 
>>> failed (e.g., a missing certificate or something like that) then the 
>>> email would be uploaded unencrypted in its draft-state which was 
>>> obviously bad. It was not sufficient that MailMate would refuse to 
>>> send it. In other cases, MailMate could/should allow drafts to be 
>>> uploaded (at least optionally).
>>>
>>> -- 
>>> Benny
>>> _______________________________________________
>>> mailmate mailing list
>>> Unsubscribe: https://lists.freron.com/listinfo/mailmate
>> _______________________________________________
>> mailmate mailing list
>> Unsubscribe: https://lists.freron.com/listinfo/mailmate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20250402/66c2bb3e/attachment.htm>