每封信底部都要有「退訂」。最直覺的寫法是 /unsubscribe?email=someone@x.com&token=…——網址帶著 email 和一個簽章。但這個設計有兩個藏在細節裡的問題。

兩個問題

一、email 攤在網址上。網址會被記進伺服器日誌、瀏覽器歷史、referrer，甚至被轉寄——等於把訂閱者的信箱到處留痕。

二、退得掉別人。如果 token 是用 email 算出來的固定簽章，它永不失效；任何拿到那條連結的人（轉寄、側錄、日誌）都能隨時退訂那個人。

安全版設計

不可猜的隨機 token。每個訂閱者發一組跟 email 無關的隨機 token，存在資料庫。退訂網址只帶 token、完全不帶 email——退不了別人，也不外洩信箱。

兩段式：GET 只確認、POST 才退訂。很多信箱與防毒會自動「點開」信裡的連結去掃描；如果 GET 就退訂，會被這些掃描器誤觸。所以 GET 只回一個「確定要退訂嗎」的頁面，按下按鈕送出的 POST 才真的改狀態。

// 退訂只認隨機 token；GET 安全、POST 才有副作用
GET  /unsubscribe?t=<random>   → 顯示「確認退訂」頁（不改狀態）
POST /unsubscribe  { t }       → 查到訂閱者 → 設為已退訂 + 通知站長

// token 產生：與 email 沒有任何可推導關係
unsubToken = crypto.randomBytes(32).toString("hex"); // 唯一、索引

眉角

• 「GET 要安全、冪等」不是教條。這裡就是它保護你不被信箱掃描器誤退訂的實例。
• 不透露、不重複。無效 token 一律回同一個「連結無效」頁，不告訴對方 token 是否存在；已退訂者再點也不重複通知站長。
• 順手加值：退訂成功也通知站長「是誰退的」，掌握名單變化。