發出去的郵件，潑出去的水

如果微信只能撤回安卓上收到的消息，不能撤回 iPhone 上的，這個功能還會有用嗎？又或者群消息的話，能撤回未閱讀成員設備上的消息，不能撤回已經閱讀的成員設備上的消息，你覺得這個功能還會有用嗎？

這正是發生在Exchange Server 和 Outlook 客戶端身上的故事。昨天我的公司郵箱里收到了下面的郵件：

從圖中可以看出，是一位同學反覆的修改發出和撤回同一封信件，卻因為我的 Mac 版 Outlook 客戶端不支持郵件伺服器的這個擴展協議，導致並沒有實際的撤回，反而多了很多聲明撤回的信件。而這個功能的使用者，也就是反覆發送和撤回郵件的同學，並不清楚這個功能的限制，無意識的製造了很多多餘的郵件。

「撤回」並不是標準的 Email 協議，是部分郵件服務商提供的擴展功能，通常用於以下場景：

• 忘記加附件
• 內容有誤
• 發給了不該發的人

但這個功能要能完全實現它的設計意圖，需要滿足極其嚴苛的條件，比如：

• 必須確保所有人的郵件客戶端支持該特定擴展
• 必須確保郵件未讀
• 必須確保郵件沒有被客戶端過濾規則轉移到「inbox」之外的文件夾，或被轉發

可以想像到的，也是實際發生的，這些條件幾乎從未被全部滿足；而更糟糕的是，當它只有部分郵件撤回時，將陷發件人於兩難境地。

不確定，因此不信賴

撤回功能的設計理念類似言論控制，能刪多少刪多少，你截屏留底了，也沒辦法，儘可能減少影響；但撤回的場景往往是郵件還是要發，而不是不想發郵件；這種情況下，即使郵件伺服器沒有專門的支持，手動發一封更正郵件也都能取得類似效果。

個人覺得這個功能效果的不確定性，使得它無法被郵件發送者完全信賴，因此不如取消。

替代方案

那有什麼替代方案嗎？由於郵件一旦從伺服器上發出，就不再受伺服器統一控制，因此很難有完美的方案，只能在發出前做些文章。

比如延時發送，用戶點擊「發送」按鈕後，郵件上傳到伺服器，但伺服器過一小段時間比如30秒或1分鐘後再發出。這樣在30秒或1分鐘之內，發件人都可以完美撤回。由於郵件本身就是一種非同步通信方式，對實時性要求沒那麼高，短時延遲還是可以接受的。

這種方案也非標準化的方案，郵件客戶端無從得知用戶的郵件伺服器是否支持該功能，因此沒辦法決定要不要在界面上顯示「撤回」按鈕。

但它帶來的確定性使得它可以被信賴，個人認為還是要優於 Exchange Server 目前的撤回協議。

推薦閱讀：