EWS報告SendItem成功，但消息仍在草稿文件夾中

Question

我正在使用EWS託管API通過交換髮送電子郵件。當發送帶有附件的物品時，我首先做一個CreateItem然後一個SendItem。大多數情況下，這可以正常工作，但有時項目仍保留在草稿文件夾中，即使EWS報告SendItem成功。我怎麼知道這裏發生了什麼？

的EWS的消息我是從跟蹤看到的是第一CreateItem：

<?xml version="1.0" encoding="utf-8"?> 
    <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
    <soap:Header> 
     <t:RequestServerVersion Version="Exchange2013" /> 
    </soap:Header> 
    <soap:Body> 
     <m:CreateItem MessageDisposition="SaveOnly"> 
     <m:SavedItemFolderId> 
      <t:DistinguishedFolderId Id="drafts"> 
      <t:Mailbox> 
       <t:EmailAddress>amailbox@thedomain.com</t:EmailAddress> 
      </t:Mailbox> 
      </t:DistinguishedFolderId> 
     </m:SavedItemFolderId> 

     ... 

     </m:CreateItem> 
    </soap:Body> 
    </soap:Envelope> 
</Trace> 

我得到一個成功響應：

<?xml version="1.0" encoding="utf-8"?> 
    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> 
    <s:Header> 
     <h:ServerVersionInfo MajorVersion="15" MinorVersion="0" MajorBuildNumber="1104" MinorBuildNumber="3" Version="V2_22" xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" /> 
    </s:Header> 
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
     <m:CreateItemResponse xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"> 
     <m:ResponseMessages> 
      <m:CreateItemResponseMessage ResponseClass="Success"> 
      <m:ResponseCode>NoError</m:ResponseCode> 
      <m:Items> 
       <t:Message> 
       <t:ItemId Id="AAMkADExMmY0MTgzLWJmZmUtNDcxNi1iOTk0LWMzZTU3M2I3NjBkMwBGAAAAAABL/dBAdDByRbztYn12Cy/4BwCJZGY3HQ5zQpbF9WoRXD0sAAAAAAEPAACJZGY3HQ5zQpbF9WoRXD0sAAA6HNVuAAA=" ChangeKey="CQAAABYAAACJZGY3HQ5zQpbF9WoRXD0sAAA6JC4z" /> 
       <t:Attachments> 
        <t:FileAttachment> 
        <t:AttachmentId Id="AAMkADExMmY0MTgzLWJmZmUtNDcxNi1iOTk0LWMzZTU3M2I3NjBkMwBGAAAAAABL/dBAdDByRbztYn12Cy/4BwCJZGY3HQ5zQpbF9WoRXD0sAAAAAAEPAACJZGY3HQ5zQpbF9WoRXD0sAAA6HNVuAAABEgAQAGiKX5lgtuFLgfIBgyg4IwM=" /> 
        </t:FileAttachment> 
        <t:FileAttachment> 
        <t:AttachmentId Id="AAMkADExMmY0MTgzLWJmZmUtNDcxNi1iOTk0LWMzZTU3M2I3NjBkMwBGAAAAAABL/dBAdDByRbztYn12Cy/4BwCJZGY3HQ5zQpbF9WoRXD0sAAAAAAEPAACJZGY3HQ5zQpbF9WoRXD0sAAA6HNVuAAABEgAQADkNd4D6H0NAgxCM7uH6MGo=" /> 
        </t:FileAttachment> 
        <t:FileAttachment> 
        <t:AttachmentId Id="AAMkADExMmY0MTgzLWJmZmUtNDcxNi1iOTk0LWMzZTU3M2I3NjBkMwBGAAAAAABL/dBAdDByRbztYn12Cy/4BwCJZGY3HQ5zQpbF9WoRXD0sAAAAAAEPAACJZGY3HQ5zQpbF9WoRXD0sAAA6HNVuAAABEgAQAKu2RdYFlBVIiLyPxshNCZQ=" /> 
        </t:FileAttachment> 
        <t:FileAttachment> 
        <t:AttachmentId Id="AAMkADExMmY0MTgzLWJmZmUtNDcxNi1iOTk0LWMzZTU3M2I3NjBkMwBGAAAAAABL/dBAdDByRbztYn12Cy/4BwCJZGY3HQ5zQpbF9WoRXD0sAAAAAAEPAACJZGY3HQ5zQpbF9WoRXD0sAAA6HNVuAAABEgAQAJ2C2tyz2iJHm8XC9LmSkcA=" /> 
        </t:FileAttachment> 
       </t:Attachments> 
       </t:Message> 
      </m:Items> 
      </m:CreateItemResponseMessage> 
     </m:ResponseMessages> 
     </m:CreateItemResponse> 
    </s:Body> 
    </s:Envelope> 
</Trace> 

那麼請問發送並移動到SentItems：

<?xml version="1.0" encoding="utf-8"?> 
    <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
    <soap:Header> 
     <t:RequestServerVersion Version="Exchange2013" /> 
    </soap:Header> 
    <soap:Body> 
     <m:SendItem SaveItemToFolder="true"> 
     <m:ItemIds> 
      <t:ItemId Id="AAMkADExMmY0MTgzLWJmZmUtNDcxNi1iOTk0LWMzZTU3M2I3NjBkMwBGAAAAAABL/dBAdDByRbztYn12Cy/4BwCJZGY3HQ5zQpbF9WoRXD0sAAAAAAEPAACJZGY3HQ5zQpbF9WoRXD0sAAA6HNVuAAA=" ChangeKey="CQAAABYAAACJZGY3HQ5zQpbF9WoRXD0sAAA6JC4z" /> 
     </m:ItemIds> 
     <m:SavedItemFolderId> 
      <t:DistinguishedFolderId Id="sentitems"> 
      <t:Mailbox> 
       <t:EmailAddress>amailbox@thedomain.com</t:EmailAddress> 
      </t:Mailbox> 
      </t:DistinguishedFolderId> 
     </m:SavedItemFolderId> 
     </m:SendItem> 
    </soap:Body> 
    </soap:Envelope> 
</Trace> 

而且我得到一個成功的NoError迴應：

<?xml version="1.0" encoding="utf-8"?> 
    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> 
    <s:Header> 
     <h:ServerVersionInfo MajorVersion="15" MinorVersion="0" MajorBuildNumber="1104" MinorBuildNumber="3" Version="V2_22" xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" /> 
    </s:Header> 
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
     <m:SendItemResponse xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"> 
     <m:ResponseMessages> 
      <m:SendItemResponseMessage ResponseClass="Success"> 
      <m:ResponseCode>NoError</m:ResponseCode> 
      </m:SendItemResponseMessage> 
     </m:ResponseMessages> 
     </m:SendItemResponse> 
    </s:Body> 
    </s:Envelope> 
</Trace> 

這些都是由相同的託管ThreadId跟蹤，所以我很確定它們都對應於相同的項目。

我不使用交換模擬。我正在使用用戶名&進行身份驗證，並使用發送項目的郵箱的憑據進行密碼驗證。

EDIT（5月22日）：

我已經添加了X-AnchorMailbox頭到我的請求，並升級至EWS託管API 2.2（用2.1，雖然自SOAP消息直視着我不要認爲這是一個問題）。問題仍在發生。

我添加了代碼以在發送後重新檢索該項目，以檢查它是否仍在草稿文件夾中。我通過EmailMessage.Bind()通過剛剛從草稿中發送的項目的Id來執行此操作。當我在Office 365上針對Exchange運行時，總是會引發異常，因爲該項不再存在，這是因爲ItemId在項目移動文件夾時發生更改，所以這是預期的。當我對客戶的Exchange服務器運行時，它通過該Id找到該項目。然後我嘗試發送，並得到一個ServiceResponseException有消息Access is denied. Check credentials and try again.如果我嘗試發送針對Office 365的消息我得到一個SendItemResponse有消息The specified object was not found in the store., The process failed to get the correct properties.（SOAP消息是SendItemResponse與ResponseCode ErrorItemNotFound。

我提出支持請求與微軟（很奇怪沒有在48小時以上回應...也許有一些技巧，以提高支持請求）。

EDIT（5月24日）

當重複我有時看到測試保留在草稿中的項目也是收件人收到！通過Outlook檢查其屬性> Internet標題時，它們都具有相同的消息標識。更多的跡象表明，東西的交換方面有些東西被搞砸了？

從EWS手段無差錯響應：

EDIT（5月30日）

我從微軟支持誰解釋了一下有關Exchange是如何工作的發送和他們認爲正在發生的事情聽說過消息是 已成功標記爲提交（PR_MESSAGE_FLAGS> MSGFLAG_SUBMIT）。提交標誌設置後，Exchange上的郵件提交 服務會通知傳輸服務，即有 條郵件正等待在草稿框中發送（如果Outlook爲發件箱）。 如果任何客戶端在標記爲提交 之後但在傳輸服務拾取之前讀取該消息，MSGFLAG_SUBMIT 標誌將被刪除，從而導致郵件被卡在草稿箱 文件夾中。

爲了確定是否是這種情況，你可以註冊使用流媒體通知（和工具的 EWSEditor或EwsStreaming喜歡）的通知，並檢查是否有任何項目修改事件和 檢查任何PR_MESSAGE_FLAGS變化。

正如所討論的，在傳輸服務去撿起它之前，任何客戶端或API都可以訪問該消息，例如OWA，Outlook，EWS Managed API，Outlook加載項或任何移動應用程序。

所以，接下來的任務是雙重的：

1. 確定是否有任何正在讀我的消息，他們已經被標記後，立即發送，重置MSGFLAG_SUBMIT標誌。如果是這樣，請他們停止。

2. 包括重新發送我認爲已發送的項目的過程，以後我會在草稿中找到它們。

我沒有得到爲什麼試圖重新發送時，我會得到一個Access Denied，但也許這是與其他修改項目的東西一致的任何信息。

他們沒有想到在EWS中這是一個問題，當EWS實際上沒有標記發送消息時，EWS不正確地報告成功。這是令人放心的。

EDIT（6月20日）：

介紹一個過程來重新發送滯留在草稿並沒有很好地工作的項目。事實證明，有時當項目被留在草稿中時，他們實際上已經被收件人發送並接收，因此重新發送它們意味着收件人得到電子郵件的副本。或者幾個，如果同樣的問題再次發生。有時物品並未發送，但仍然從草稿中移除並移至已發送物品 - 發件人無法確定是否發送了物品。非常奇怪。我在這裏問了另一個問題，具體是否Exchange message sending is expected to be atomic and reliable。

---

也提出了對Exchange forums

Answer 1

我沒有解決這個問題，除非儘可能確保沒有其他應用程序與MS支持人員同時與郵箱進行交互。我們更改了郵箱的權限，以阻止有權訪問共享郵箱的人員訪問該郵箱並通過Outlook提供該郵箱。這完全解決了遇到問題的主要客戶的問題。但是，對於我來說，EWS /交換可能如此不可靠，我絕不會因爲這類問題而選擇再次使用它。它也沒有解釋郵件已發送但保留在「草稿」文件夾中的情況，這意味着無法確定發送成功還是失敗。

Answer 2

的「MessageFlags」 MAPI擴展屬性設置爲「讀取」，因此該項目不會被標記爲「草稿」。

這裏是擴展屬性定義：

/// <summary> 
/// Definitions of Microsoft's Mail API (MAPI) extended properties that you can get/set on mailbox items via EWS interface 
/// </summary> 
public static class MapiSchema 
{ 
    /// <summary> 
    /// Definition of MAPI property unique identifiers 
    /// </summary> 
    public static class Tags 
    { 
     /// <summary> 
     /// Message flags (like 'read', 'unsent'; see PR_MESSAGE_FLAGS online) 
     /// </summary> 
     public const int MessageFlags = 0x0E07; 
    } 

    /// <summary> 
    /// Message flags (like 'read', 'unsent'; see PR_MESSAGE_FLAGS online) 
    /// </summary> 
    public static readonly ExtendedPropertyDefinition MessageFlags = new ExtendedPropertyDefinition(Tags.MessageFlags, MapiPropertyType.Integer); 
} 

以下是可能的值（標誌）該物業：

/// <summary> 
/// Values for the PR_MESSAGE_FLAGS message property (Microsoft's Message API) 
/// </summary> 
[Flags] 
public enum MessageFlags 
{ 
    /// <summary> 
    /// No flags set 
    /// </summary> 
    None = 0, 

    /// <summary> 
    /// [MSGFLAG_READ] The message is marked as having been read. This can occur as the result of a call at any time to IMessage::SetReadFlag or IMAPIFolder::SetReadFlags. Clients can also set this flag by calling a message's IMAPIProp::SetProps method before the message has been saved for the first time. This flag is ignored if the MSGFLAG_ASSOCIATED flag is set. 
    /// </summary> 
    Read = 1, 

    /// <summary> 
    /// [MSGFLAG_UNMODIFIED] The outgoing message has not been modified since the first time that it was saved; the incoming message has not been modified since it was delivered. 
    /// </summary> 
    Unmodified = 2, 

    /// <summary> 
    /// [MSGFLAG_SUBMIT] The message is marked for sending as a result of a call to IMessage::SubmitMessage. Message store providers set this flag; the client has read-only access. 
    /// </summary> 
    Submit = 4, 

    /// <summary> 
    /// [MSGFLAG_UNSENT] The message is still being composed. It is saved, but has not been sent. The client or provider has read/write access to this flag until the first IMAPIProp::SaveChanges call and read-only thereafter. If a client doesn't set this flag by the time the message is sent, the message store provider sets it when IMessage::SubmitMessage is called. Typically, this flag is cleared after the message is sent. 
    /// </summary> 
    Unsent = 8, 

    /// <summary> 
    /// [MSGFLAG_HASATTACH] The message has at least one attachment. This flag corresponds to the message's PR_HASATTACH (PidTagHasAttachments) property. The client has read-only access to this flag. 
    /// </summary> 
    HasAttachment = 16, 

    /// <summary> 
    /// [MSGFLAG_FROMME] The messaging user sending was the messaging user receiving the message. The client or provider has read/write access to this flag until the first IMAPIProp::SaveChanges call and read-only thereafter. This flag is meant to be set by the transport provider. 
    /// </summary> 
    FromMe = 32, 

    /// <summary> 
    /// [MSGFLAG_ASSOCIATED] The message is an associated message of a folder. The client or provider has read-only access to this flag. The MSGFLAG_READ flag is ignored for associated messages, which do not retain a read/unread state. 
    /// </summary> 
    Associated = 64, 

    /// <summary> 
    /// [MSGFLAG_RESEND] The message includes a request for a resend operation with a nondelivery report. The client or provider has read/write access to this flag until the first IMAPIProp::SaveChanges call and read-only thereafter. 
    /// </summary> 
    Resend = 128, 

    /// <summary> 
    /// [MSGFLAG_RN_PENDING] A read report needs to be sent for the message. The client or provider has read-only access to this flag. 
    /// </summary> 
    ReadReportPending = 256, 

    /// <summary> 
    /// [MSGFLAG_NRN_PENDING] A nonread report needs to be sent for the message. The client or provider has read-only access to this flag. 
    /// </summary> 
    NonReadReportPending = 512, 

    /// <summary> 
    /// [MSGFLAG_ORIGIN_X400] The incoming message arrived over an X.400 link. It originated either outside the organization or from a source the gateway cannot consider trusted. The client should display an appropriate message to the user. Transport providers set this flag; the client has read-only access. 
    /// </summary> 
    OriginX400 = 4096, 

    /// <summary> 
    /// [MSGFLAG_ORIGIN_INTERNET] The incoming message arrived over the Internet. It originated either outside the organization or from a source the gateway cannot consider trusted. The client should display an appropriate message to the user. Transport providers set this flag; the client has read-only access. 
    /// </summary> 
    OriginInternet = 8192, 

    /// <summary> 
    /// [MSGFLAG_ORIGIN_MISC_EXT] The incoming message arrived over an external link other than X.400 or the Internet. It originated either outside the organization or from a source the gateway cannot consider trusted. The client should display an appropriate message to the user. Transport providers set this flag; the client has read-only access. 
    /// </summary> 
    OriginOtherExternal = 32768, 
} 

這裏是你如何創建一個項目之前，將其設置：

var item = new EmailMessage(service); 
var messageFlags = MessageFlags.Read; 
item.SetExtendedProperty(MapiSchema.MessageFlags, (int)messageFlags); 

交換是充滿了錯誤，我希望這可以解決這個問題。

Answer 3

從MSDN documentation on SendItem摘自：

另外一個場景 要考慮的是，當一個委託創建電子郵件並保存 到代理的郵箱的草稿文件夾。如果代理人嘗試 發送項目並將副本保存到委託人的已發送項目 專有文件夾中，則消息被正確發送，草稿消息 保留在委託人的草稿文件夾中，發送的消息不會出現在委託人的代碼中的 中或校長的已發送郵件文件夾，並且 的迴應是成功的。

該文檔似乎說你運氣不佳...最好的解決辦法可能是執行發送和移動到發送項目作爲兩個單獨的功能以及。