Microsoft Graph API中邮件createdDateTime晚于lastModifiedDateTime的原因

我们有一个同时在Outlook网页版和原生客户端使用的共享邮箱，已为其邮件配置了created变更通知。我使用Microsoft Graph API v1.0通过以下端点读取邮件：

GET /users/{id | userPrincipalName}/messages/{id}

该端点返回4个dateTime字段，我的理解如下：

"sentDateTime" -         发送服务器发送邮件的时间。
"receivedDateTime" -     接收服务器收到邮件的时间。
"createdDateTime" -      邮件在邮箱文件夹中创建的时间。
"lastModifiedDateTime" - 邮件最后修改的时间（在文件夹间移动时会变更）。

近期遇到一个打破认知的场景：收到Graph API的通知后，通过ID查询上述端点得到以下信息：

"sentDateTime":         "2023-02-15T17:45:29Z"
"receivedDateTime":     "2023-02-15T17:45:32Z"
"createdDateTime":      "2023-03-20T12:29:13Z"
"lastModifiedDateTime": "2023-02-15T17:45:32Z"

注意到createdDateTime晚于lastModifiedDateTime，这不符合逻辑，因为任何邮件变更都应更新lastModifiedDateTime。

是什么原因导致Microsoft Graph API出现createdDateTime远晚于lastModifiedDateTime的行为？

原因分析 #

• 邮件从归档/冷存储恢复至活跃文件夹：如果这封邮件此前被归档到Exchange的冷存储或归档邮箱，3月20日被恢复/迁移回共享邮箱的活跃文件夹时，createdDateTime会被更新为邮件在当前活跃文件夹的创建时间，但lastModifiedDateTime保留的是邮件最初接收或最后一次修改的时间（2月15日）。由于迁移操作未修改邮件内容或属性，因此不会触发lastModifiedDateTime更新。

• 跨邮箱移动/复制操作：若邮件是在3月20日从其他邮箱（如个人邮箱）移动或复制到该共享邮箱的，createdDateTime会被设置为移动/复制完成的时间，而lastModifiedDateTime会继承原邮件的最后修改时间。这种场景下，移动/复制仅改变邮件的存储位置，未修改邮件本身，所以lastModifiedDateTime不会更新。

• 邮件导入/还原操作：如果这封邮件是通过导入工具在3月20日还原到共享邮箱的，导入过程会将createdDateTime设为导入完成时间，但lastModifiedDateTime会沿用原邮件的最后修改时间。导入操作属于创建新的邮箱条目，而非修改原有邮件，因此不会更新lastModifiedDateTime。

• 多客户端同步延迟：当Outlook网页版和原生客户端同时访问共享邮箱时，可能出现同步延迟。比如原生客户端缓存了旧的lastModifiedDateTime值，而Graph API返回的createdDateTime是服务器端最新的创建时间（如邮件被重新导入的时间），导致两者时间顺序异常。

内容的提问来源于stack exchange，提问作者Piyush Chugh