[HN] Email could have been X.400 times better

我等了至少半年才搞懂 X.400 是怎麼死的。1984 年的規格早就內建撤回、排程、自毀、已讀回條、加密、多語系附件與組織級群發檢查——比現在的 SMTP 早 15 年還附帶個人知識鏈。但工程師最終選擇 SMTP，因為「兩週就能跑起來」。

去年我用 n8n 串接客戶報價流程時踩出來的痛點印證了這段歷史：把報價單自動 email 給工地窗口，結果三天後才收到「附件太大退回」通知。我試過把檔案拆成 zip、改走 OneDrive 連結，甚至讓 Claude Code 幫我寫前置壓縮腳本，但最頭痛的還是「SMTP 不會先檢查收件人是否存在」。X.400 當年就能在發送前驗證整條路徑，我們現在卻要靠後天疊 patch。

我一直在觀察這種「功能強卻輸給簡單」的循環。SMTP 像一輛沒有剎車的小車開上路，一路撞牆再修補：PGP、TLS、DKIM、DMARC、BIMI。每次整合都要額外 30% 維護時間。相比之下，X.400 的複雜地址 C=no; ADMD=; PRMD=uninett;… 雖然難記，但至少地址本身就是路由表，寫錯會立即告知。現在我們用 regex 驗 email 格式，卻還是無法避免 typo-squatting。

這個教訓讓我在評估新的通訊協議時特別謹慎：功能再齊全，如果部署門檻太高，工程師還是會投回「夠用就好」的陣營。問題是，40 年過去，email 仍是我跟客戶的最後一哩路。我已經在考慮是不是乾脆用 Ollama 本地跑一個小模型，直接判斷郵件是否成功遞送，再回寫進 n8n 重試——等於自己補上 X.400 早就內建的路由驗證。

不知道大家是否也卡在「功能全但難維護」與「簡單卻要一直補洞」之間？還是你已經找到能替代 email 的 workflow？