Receiving a RopAbortSubmit ROP Request

When an e-mail message is submitted and is still queued on the server pending delivery, the submission can be terminated by sending a RopAbortSubmit ROP request ([MS-OXCROPS] section

If the mfSubmitted bit of a submitted message's PidTagMessageFlags property ([MS-OXCMSG] section has not been set yet, sending the RopAbortSubmit ROP request indicates to the server that it SHOULD stop delivering the message by removing the message from the spooler queue. The mfUnsent bit of the message's PidTagMessageFlags property is set and the mfSubmitted bit of the message's PidTagMessageFlags property is cleared. Even if the message's PidTagDeferredSendTime property (section has been set, the client will not be notified that the message has been deferred.

The RopAbortSubmit ROP can fail at the server's discretion. When the RopAbortSubmit ROP fails, the message can still be sent.

When a message is locked using the RopSpoolerLockMessage ROP ([MS-OXCROPS] section, the server MUST deny RopAbortSubmit ROP requests, as well as other requests to lock or access the message.

The following error codes can be returned by this ROP.

Error code name





The operation cannot be aborted.



The message is no longer in the spooler queue of the message store.



The Server object associated with the InputHandleIndex field in the Server object table is not a Logon object, or the current logon session is a public logon.



The parent FID ([MS-OXCDATA] section or MID ([MS-OXCDATA] section is invalid.