3.2.4.8 Processing E-mail Objects in the Spooler Queue

When the client finds an E-mail object in the spooler queue folder that the client can handle,<10> it takes control of the message by sending the RopSpoolerLockMessage ROP request ([MS-OXCROPS] section 2.2.7.5) with the LockState field set to lstLock. The client then performs any implementation-dependent processing. If the client determines that the message can be handled by a particular server, it sends the RopGetTransportFolder ROP request ([MS-OXCROPS] section 2.2.7.8) to retrieve the FID ([MS-OXCDATA] section 2.2.1.1) of a folder where temporary transport objects can be stored (clients can cache the returned FID and avoid having to send the request multiple times), creates the message to be sent to the folder, and then sends the RopTransportSend ROP request ([MS-OXCROPS] section 2.2.7.6) to have that server deliver the message. If the client handles delivering the mail itself, it sets the R flag of the RecipientFlags field, as specified in [MS-OXCDATA] section 2.8.3.1, of each recipient (2) in the recipient table that it successfully delivers mail to.

After completing the previous steps, the client sends a RopSpoolerLockMessage ROP request ([MS-OXCROPS] section 2.2.7.5) with the LockState field set to lstFinished if the message has been sent to all recipients (2) or to lstUnlock if some recipients (2) have not yet been sent the message. If some recipients (2) have yet to be processed, the client determines whether another server can deliver the e-mail message. If another server is found, the client attempts to resubmit the message to the remaining recipients (2). If no remaining transports can deliver the mail, the client SHOULD generate a non-delivery report or notify the user of the error.