Pico-UTM 行銷日：
從裸奔的 API Key 到全面打通的郵件架構
修一個問題，順著脈絡把旁邊的問題也一起收掉。
那天的任務很單純：為 Pico-UTM 100 的銷售衝刺準備材料。這批設備有點特別——三年資安服務授權綁定的 700Mbps UTM，價格實在超值到連我自己都先買了一台，是難得一見的尾盤機會。
從早上開始，文件、網頁工具、診斷問卷一份接一份。其中最花工夫的是「企業網路風險自我診斷」工具：業主勾選公司有哪些網路設備，系統依風險模型即時產生報告，同步寄信給業主和業務端。
測試完成，信寄出去，報告顯示正常。完美。然後習慣性地按了 F12。
裸奔的發現
EmailJS 的 Public Key、Service ID、兩組 Template ID，全部白紙黑字在原始碼裡。
網頁的所有程式碼，任何人都可以用瀏覽器「檢視原始碼」或開發者工具看到。如果服務的金鑰（API Key）直接寫在網頁裡，等同於把保險箱密碼貼在門口。拿到 EmailJS 的 Key，任何人都能冒用你的帳號大量寄信，直到額度用完或帳號被封。
做資安診斷工具的人，自己的工具先裸奔——這個畫面說不過去。當天就決定修掉。
路徑分歧：怎麼選解法
解法不只一條，每條都有代價。
| 方案 | 可行性 | 決定 |
|---|---|---|
| 自架後端伺服器 | 可行，Key 安全 | ❌ 多管一台機器，排除 |
| Resend 前端直打＋Domain 限制 | Key 洩漏仍可發詐騙信 | ❌ 法律風險，排除 |
| Cloudflare Workers | 免費、Key 不外露、全球節點 | ✅ 採用 |
可以把它想成「放在全球機房裡的保鑣」。你寫一小段 JavaScript，部署到 Cloudflare 遍布全球的節點。有請求進來，最近的節點瞬間啟動執行，執行完消失，不用付費養一台永遠開著的伺服器。免費版每天有 10 萬次請求額度，對一個診斷問卷來說完全用不完。
架構確定之後，最終流程是這樣的：
實作過程的幾個插曲
決定方向後開始動手，過程不是一路順暢。每個錯誤訊息都說得很清楚，順著修就好。
www.pcpilot.com.tw，Worker 只允許 pcpilot.com.tw。瀏覽器直接擋掉，錯誤訊息說得很清楚。把兩個都加進白名單，解決。mail-relay-key，程式碼讀的是 RESEND_API_KEY，兩邊對不上，Worker 回傳 500。改成一致，解決。text 欄位）讓 Gmail 正確識別信件格式，解決。意外的連鎖收穫
問題修完，忽然想到另一個擱置已久的問題。公司的 Synology MailPlus 對外寄信一直不穩定，根本原因有兩層：
當你寄出一封信，對方的郵件伺服器會把你的 IP 反查，確認有沒有對應的反解記錄（PTR record）。沒有反解，對方的第一反應是「這個 IP 不像正經的郵件伺服器」，直接退信或塞進垃圾桶。反解要由 ISP 設定，不是網域擁有者能自己處理的事。
Resend 提供標準 SMTP 介面。把 MailPlus 的寄件改成透過 smtp.resend.com 中繼，Resend 的出站 IP 有完整的 PTR、SPF、DKIM、DMARC——測試結果：
✓ Yahoo Mail
✓ Hotmail
✓ Seed.net.tw
最終架構
那天的主線任務是備好銷售材料。這個目標完成了。但在收尾的地方發現一個不漂亮的問題，修它的過程連帶把另一個舊問題也一起解掉——這種感覺比計畫中的工作更讓人滿意。
工程師思路大概就是這樣：修一個問題，順著脈絡把旁邊的問題也一起收掉。
#Resend
#資安
#MailPlus
#工程師思路
#Pico-UTM
Comments