寄信功能十分鐘就會動，難的是不讓別人也能用

加一個寄信按鈕，難的不是寄信

最近我在整理本站的自我盤點頁，想加一個「寄一份結果給我」的按鈕：讀者勾完 26 題、填 email，收到一封有 ✓／✗ 和原因的信。功能本身很小，小到十分鐘就寫得完。

但它牽涉三件我們在三起事件裡都付過學費的事：憑證放哪裡、誰能呼叫、被濫用時誰先知道。寫完之後回頭看，真正花時間的全在這三題上——寄信是十分鐘，防止它變成別人的垃圾信發射器才是整個下午。

先講清楚這篇的性質：沒有入侵、沒有外洩，這是一份自家實作紀錄。時間軸上唯一真正的事故發生在三週前，而且跟寄信一點關係都沒有。

1. 2026-08-29
   CLI 改單一變數，清空兩個服務全部環境變數
   事故紀錄；主控台手動補回 23 個變數。
2. 2026-09-17 21:0x
   寫 lib/mail.ts 與兩個路由，本機測試 200／401
   本站 commit 與 curl 輸出。
3. 2026-09-17 21:1x
   單鍵寫入 8 個變數，讀回 16 個無遺失
   腳本比對輸出。
4. 2026-09-17 21:5x
   頁尾圖上傳共用雲端硬碟成功，但設不了公開權限
   代理回應 public:false。

這次沒有任何東西外洩。但把應用端手上的憑證攤開來，才知道「最壞情況」有多壞，以及它為什麼可以不那麼壞。

三列裡最重要的是第三列的「放在哪」：不在任何應用端。這一格決定了上面兩列外洩時是麻煩，還是災難。

沒有告警，三個坑都是做的時候自己撞上的

這篇沒有偵測故事。三個值得寫下來的問題，都是實作過程中撞出來的：整組覆寫會清空環境變數、新的服務帳戶沒有個人雲端硬碟配額、線上回 404 是因為還沒重新部署。

把它們拆成證據，前兩件有紀錄可查，另外兩件一個是推論、一個是缺口。

證據等級最低的那兩條，剛好就是這套設計最脆弱的地方：限流的邊界在哪，我們其實是用猜的。

這個端點還沒被打過，但他要什麼很清楚

下面兩個階段都沒有發生在本站，所以兩格都標問號。它們不是憑空想的：第一步那份路徑清單，跟 Crusader 那支殭屍網路掃的 542 條路徑是同一種東西。

Crusader 掃的那 542 條路徑，前幾名就是 .env、.git、各種設定檔，目標是 AWS 金鑰、SMTP 憑證、Google 金鑰。這篇的整個設計，就是讓那份掃描清單在我們這裡一無所獲：repo 裡沒有密碼、應用端沒有 SMTP、頁尾圖上傳也沒有 Google 金鑰。剩下的兩個明文變數——寄件代號與 API token——外洩時損害有上限、有 log、能單鍵輪替。

五個步驟，每一步都在回答「外洩了會怎樣」

動手前先問三件事：憑證放哪裡、誰能呼叫、被濫用時誰先知道。下面五步就是這三個問題的答案，順序不能顛倒。

第一步：應用端不碰 SMTP

我們內部有一個寄信閘道，是一支獨立的小服務，只有它持有 Google 的應用程式密碼。應用端要寄信，是對閘道發一個 HTTP 請求，帶兩個標頭表明「我是誰」，body 是收件人、主旨、HTML 內容、寄件者顯示名稱、頁尾圖與連結。

這樣做的好處在憑證的存在形式：應用端的 repo 與環境變數裡沒有任何 SMTP 密碼，只有一組寄件代號。代號外洩，最壞的情況是有人冒用我們的名義寄信，而且閘道的 log 會標出是哪個代號寄的；SMTP 密碼外洩，最壞的情況是整個信箱被接管。

寄件代號每個應用一組，不共用。本站用自己的代號，會計系統用它自己的。閘道靠代號分辨來源，共用代號等於把 log 弄瞎。

第二步：兩個路由，兩種閘門

第一個路由沒有 token 一律 401，token 是 32 字元以上的隨機值，只存在部署平台的環境變數與本機的 .env.local（已 gitignore）。第二個路由是公開的，所以它不接受任何自訂內容：主旨、內文、頁尾都由伺服器組，使用者能決定的只有「寄到哪個信箱」，而且一小時最多三次。

// 寄件代號與驗證值都從部署平台的環境變數讀，程式碼與 repo 裡沒有任何值
const sender = readSenderFromEnv();
if (!sender) throw new Error("尚未設定寄送服務");
// 收件人最多 10 個、主旨 200 字、內容 200KB；超過就 400，不進閘道

第三步：環境變數用單鍵寫，先快照再比對

這一步是整篇最重要的坑。8 月底我們在另一個專案用 CLI 的 variable update -k KEY=VALUE 改一個密碼，結果兩個服務的所有環境變數被清空，連指定的那個 key 都沒留下。原因是那個指令底層是「用這組資料取代整組變數」，而主控台又沒有變數歷史可以回復。

所以現在改變數一律走平台的單鍵 API（建立、更新、刪除各一個 mutation），流程固定三拍：先把該服務全部變數讀出來存成快照檔，再逐鍵寫入（已存在就單鍵更新、不存在就單鍵建立），最後再讀一次，比對 key 數量沒少、新值讀回一致。

我們把這段寫成腳本，這次替本站寫入 8 個變數（閘道位址、寄件代號與驗證值、頁尾圖、頁尾連結、寄件者名稱、API token、站台網址），讀回 16 個，原本的 8 個一個沒少。

snapshot: …/blog-20260917-212524.json (16 variables)
verified: 16 -> 16 variables, none lost
NOTE: redeploy the service for new variables to take effect

第四步：頁尾圖放共用雲端硬碟，走無金鑰代理上傳

信件頁尾要一張圖，圖要有一個「任何人有連結可讀」的網址。我們不想為了一張圖在 repo 放 Google 金鑰，所以走另一支無金鑰的 Drive 代理上傳到共用雲端硬碟。

這裡踩到兩個坑：新的服務帳戶沒有個人雲端硬碟的儲存配額，只能傳到共用雲端硬碟；而共用雲端硬碟預設不允許非成員存取，代理的服務帳戶設不了「任何人可讀」，最後要用自己的帳號補一筆權限。過渡期先沿用另一個專案的頁尾圖，功能不受影響。

第五步：curl 測試，四種回應各代表什麼

curl -sS -X POST "https://<你的網域>/api/mail/send" \
-H "Content-Type: application/json" -H "X-Mail-Token: ***" \
-d '{"to":"[email protected]","subject":"測試","content":"<p>hello</p>"}'
# 200 {"success":true}  → 閘道憑證、token、路由都正常
# 401                    → token 不一致（本機 .env.local 與平台不同）
# 404                    → 服務還沒重新部署帶新路由
# 502                    → 閘道拒絕：寄件代號或驗證值錯

本機用 .env.local 起站測，第一封信 200；沒帶 token 401；正式網域 404，因為線上還是舊 build。這個 404 是預期中的——環境變數要重新部署才生效，程式碼也要。知道每一種回應代表什麼，比測到 200 更重要。

哪裡做對，哪裡做錯

做對的四件事有一個共同點：都是在「假設它會外洩」的前提下決定的。應用端從第一版就不持有 SMTP 密碼，repo 裡只有 .env.example；公開路由不接受任何自訂內容，使用者能決定的只有寄到哪個信箱；寄件代號每個應用一組，閘道 log 分得出是誰在寄；改環境變數先快照、後比對，這次寫入 8 個、讀回 16 個，原本的一個沒少。

做錯與待補的四件，共同點也很一致：我們知道邊界在哪裡，但沒有量過它。每 IP 限流放在單一實例的記憶體裡，多實例部署時會失效；閘道本身每天能寄多少、被封鎖的門檻在哪，到現在沒有量測過；頁尾圖的公開權限設不了，最後要用自己的帳號補一筆，代理的邊界沒有事先確認。最後一件最值得記：單鍵寫入這條規矩，是 8 月底清空兩個服務的變數之後才有的——它不是設計出來的，是撞出來的。

如何避免

今天就能做完的有三件，全部唯讀或無害：grep repo 歷史有沒有 SMTP 密碼或 API key，命中就當已外洩處理；對自己的寄信端點不帶 token 打一次，看它回 200 還是 401；把部署平台上寄信相關變數的數量記下來，當作下次改動的對照基準。

這幾週要把做法固定成規矩：任何對外寄信端點都要 token，公開的那一個只能寄固定內容給填寫者本人；改環境變數一律走單鍵 API，先快照、逐鍵寫入、讀回比對數量；寄件代號每個應用一組、不共用，閘道 log 才分得出來源。

這一季之後要補的是上面那些「沒量過」的邊界：限流改成集中式，因為多實例部署時記憶體版的每 IP 限流一定會失效；量出閘道端的每日總量上限與被封鎖門檻，不要等第一次退信才知道；並把「應用端永遠不持有 SMTP 密碼」寫成預設值，新服務一律接閘道，不各自拿一把應用程式密碼。

這篇提到的項目要花多少錢

前兩列是零、第三列是兩小時，最後一列沒有數字——而沒有數字的那一列，才是這整篇要防的東西。

你可以學到什麼

如果你的網站也有一個寄信端點，下面五步唯讀檢查花不了十五分鐘。