[Evolution-users] Sent messages using Microsoft 365 are seen in outlook web as Draft

[Milan Crha]

On Wed, 2025-08-13 at 10:29 +0200, ogio.spam via evolution-users wrote:
> The problem is that the most important option (save reply in the
> folder of the original message) is not applicable.

	Hi,
I suppose you mean: not applicable without "gaining" the draft flag.

I did not know we talk about the "save reply in the folder of the
original message". It explains what you see and, also with your tests,
voids my previous "the Graph API has a bug". Then sending the message
and let the server save it to the Sent Items does _not_ add the draft
flag (as all is done on the server and by the server). That's good.

Saving to the original folder means appending the message to the
folder. The related code in the sources contains this comment:

  /* As of 2024-09-26, cannot upload message directly to the folder_id, because the server returns:
     {"error":{"code":"UnableToDeserializePostBody","message":"were unable to deserialize "}}
     thus upload to the Drafts folder and then move the message to the right place. */

The problem is that the "isDraft" flag [1] is described as:

    Indicates whether the message is a draft. A message is a draft if
    it hasn't been sent yet.

which probably means even if the message is created in other than the
Drafts folder it would have set the flag. I cannot test it due to the
above bug/code-comment.

> Can this be usefull in order to change the behaviour of sending
> message and moving it after it appear in sent folder?

I see, I know what you mean. The answer is yes... mostly. The 'yes' is
for 'yes, it would work and might get rid of the isDraft flag on the
messages'. The 'mostly' is for 'doing so would be somehow complicated".

There are several obstacles here:
a) the API does not return the ID of the added message in the Sent
   Items folder, thus one would need to search for it in that folder,
   which could mean some errors in some cases, apart of taking some
   time to find the message
b) the message send works as follows:
   - evolution asks some part of the code to send the message
   - when succeeded, the evolution asks another part of the code
     to save the sent message to the sent folder, according to
     the account settings and such. It can skip this, if the sending
     part claimed it saved the sent message;
   These two parts of the code do not know about each other.
c) the sent message saved by the server can be slightly different
   from the original message (mostly removed evolution-related headers)

I'm not saying it's impossible to do, the evolution-ews can access the
needed information (apart of the sent message ID on the server), it
just might be for some price.

If you'd like to, feel free to fill an enhancement request against the
evolution-ews project [2]. If there is no better workaround at the
moment, then it can be it. No promises when I'd get to it, though.

	Thanks and bye,
	Milan

[1] https://learn.microsoft.com/en-us/graph/api/resources/message?view=graph-rest-1.0
[2] https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/