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

[Henry Seiden]

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/85c57809/attachment.htm>