none
Sent email using the “SendMail” AES command are not saved in the Sent Items folder. RRS feed

  • Question

  • I am developing a mobile client (WinRT) that sends emails using the “SendMail” AES command. The Exchange server has the protocol version 14.1. The emails being sent do reach their recipients. However, the emails are not being saved in the “Sent Items” folder of the account that I use to send emails. I do set the “SaveInSentItems” in the command request (see below).

    If I send emails from my test account manually (using a standard web client) then I can see the emails being saved in “Sent Items”. That leads me to believe that the account is set correctly and probably there is something wrong with my request. .

    I also set the “SaveInSent=T” query parameter in the URL although I think for a protocol of V 14.1 that is not needed. Initially the URL was constructed without “SaveInSent=T” and it seems that this makes no difference.

    Any ideas why the emails are not being saved in the “Sent Items” folder?

    Here are some examples of the URL and the SendMail command that I tried:

    http://<...>.com/Microsoft-Server-ActiveSync?Cmd=SendMail&SaveInSent=T&User=<...>&DeviceId=b906e1ec32c34514b8731a23f4b94992&DeviceType=WInRT

    http://<...>.com/Microsoft-Server-ActiveSync?Cmd=SendMail&User=<...>&DeviceId=b906e1ec32c34514b8731a23f4b94992&DeviceType=WInRT

    =======================================

    <SendMail xmlns="ComposeMail">

      <ClientId>9cf805d9-8f44-40c5-8ca6-c58753eee256</ClientId>

      <SaveInSentItems />

      <Mime><![CDATA[From: awemail9

    To: test@outlook.com

    Subject: TC-01

    MIME-Version: 1.0

    Content-Type: text/plain; charset="iso-8859-1"

    Content-Transfer-Encoding: 7bit

    This is the email body content.]]></Mime>

    </SendMail>

    =======================================

    <SendMail xmlns="ComposeMail">

      <ClientId>96edc2e1-eda7-4e0e-9fb5-9b25a3b5b9a8</ClientId>

      <SaveInSentItems />

      <Mime><![CDATA[From: awemail9

    To: test@outlook.com

    Subject: TC-01

    MIME-Version: 1.0

    Content-Type: text/plain; charset=utf-8

    Content-Transfer-Encoding: 7bit

    This is the email body content.]]></Mime>

    </SendMail>

    =======================================

    <composemail:SendMail xmlns:composemail="ComposeMail">

      <composemail:SaveInSentItems />

      <composemail:ClientId>a5244d09-abbe-4d5e-bc31-06dcf4c6eccd</composemail:ClientId>

      <composemail:Mime><![CDATA[From:

    To: test@outlook.com

    Subject: C-06

    MIME-Version: 1.0

    Content-Type: text/plain; charset=utf-8

    Content-Transfer-Encoding: base64

    VGhpcyBpcyBhIHRlc3QgYm9keS4NCg==

    ]]></composemail:Mime>

    </composemail:SendMail>

    Thursday, January 30, 2014 7:48 PM

Answers

  • Hello Josh,

    The issue can no longer be reproduced. At this point I assume that the team that administers the Exchange Server may have changed certain settings at Exchange Server level. I've contacted them to try to figure out the root cause.

    I already collected Fiddler traces at the time this issue still happened but at this point I don't think the client caused this issue. Let me know if you think this Fiddler trace is of any interest to you and I will send them your way.

    Ladi



    • Marked as answer by Ladi Molnar Tuesday, February 4, 2014 11:05 PM
    • Edited by Ladi Molnar Tuesday, February 4, 2014 11:06 PM
    Tuesday, February 4, 2014 11:00 PM

All replies

  • Hi Ladi,

    A colleague will contact you soon to investigate this issue.

    Regards,

    Mark Miller | Escalation Engineer | Microsoft Open Protocols Team

    Thursday, January 30, 2014 9:29 PM
  • Hi Ladi Molnar, I am the engineer who will be working with you on this issue.

     

    The information you have provided is useful, however a Fiddler trace would contain more information that is needed to properly troubleshoot your issue. Please capture a trace containing the request and response messages and send that to me at dochelp(at)microsoft(dot)com.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Thursday, January 30, 2014 10:31 PM
    Moderator
  • Hello Josh, my apologies for the delay. I am going to send you today a Fiddler trace.
    Tuesday, February 4, 2014 9:49 PM
  • Hello Josh,

    The issue can no longer be reproduced. At this point I assume that the team that administers the Exchange Server may have changed certain settings at Exchange Server level. I've contacted them to try to figure out the root cause.

    I already collected Fiddler traces at the time this issue still happened but at this point I don't think the client caused this issue. Let me know if you think this Fiddler trace is of any interest to you and I will send them your way.

    Ladi



    • Marked as answer by Ladi Molnar Tuesday, February 4, 2014 11:05 PM
    • Edited by Ladi Molnar Tuesday, February 4, 2014 11:06 PM
    Tuesday, February 4, 2014 11:00 PM
  • Hi Ladi, since the problem is no longer occurring there's no real need to send me the trace. It's possible that there could be something in the response that will tell us why the problem was occurring. However, since it may have been a server side configuration issue there might not be anything at all.

     

    If you see the problem again collect a new trace and let me know.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Wednesday, February 5, 2014 3:19 PM
    Moderator