如果微信只能撤回安卓上收到的消息，不能撤回 iPhone 上的，这个功能还会有用吗？又或者群消息的话，只能撤回未阅读成员设备上的消息，不能撤回已经阅读的成员设备上的消息，你觉得这个功能还会有用吗？
这正是发生在Exchange Server 和 Outlook 客户端身上的故事。昨天我的公司邮箱里收到了下面的邮件：
从图中可以看出，是一位同学反复的修改发出和撤回同一封信件，却因为我的 Mac 版 Outlook 客户端不支持邮件服务器的这个扩展协议，导致并没有实际的撤回，反而多了很多声明撤回的信件。而这个功能的使用者，也就是反复发送和撤回邮件的同学，并不清楚这个功能的限制，无意识的制造了很多多余的邮件。
“撤回”并不是标准的 Email 协议，是部分邮件服务商提供的扩展功能，通常用于以下场景：
- 忘记加附件
- 内容有误
- 发给了不该发的人
但这个功能要能完全实现它的设计意图，需要满足极其严苛的条件，比如：
- 必须确保所有人的邮件客户端支持该特定扩展
- 必须确保邮件未读
- 必须确保邮件没有被客户端过滤规则转移到“inbox”之外的文件夹，或被转发
可以想象到的，也是实际发生的，这些条件几乎从未被全部满足；而更糟糕的是，当它只有部分邮件撤回时，将陷发件人于两难境地。
不确定，因此不信赖
撤回功能的设计理念类似言论控制，能删多少删多少，你截屏留底了，也没办法，尽可能减少影响；但撤回的场景往往是邮件还是要发，而不是不想发邮件；这种情况下，即使邮件服务器没有专门的支持，手动发一封更正邮件也都能取得类似效果。
个人觉得这个功能效果的不确定性，使得它无法被邮件发送者完全信赖，因此不如取消。
替代方案
那有什么替代方案吗？由于邮件一旦从服务器上发出，就不再受服务器统一控制，因此很难有完美的方案，只能在发出前做些文章。
比如延时发送，用户点击“发送”按钮后，邮件上传到服务器，但服务器过一小段时间比如30秒或1分钟后再发出。这样在30秒或1分钟之内，发件人都可以完美撤回。由于邮件本身就是一种异步通信方式，对实时性要求没那么高，短时延迟还是可以接受的。
这种方案也非标准化的方案，邮件客户端无从得知用户的邮件服务器是否支持该功能，因此没办法决定要不要在界面上显示“撤回”按钮。
但它带来的确定性使得它可以被信赖，个人认为还是要优于 Exchange Server 目前的撤回协议。
网友评论