一封信為什麼會被退回 —— 郵件信任體系三十年演變
一封信為什麼會被退回 —— 郵件信任體系三十年演變

PCPILOT · 工程師思路系列 一封信為什麼會被退回 ——郵件信任體系三十年演變 規則不是憑空訂的,是被逼出來的。今天的標準,是三十年來人與垃圾郵件博弈的妥協結果。 你有沒有遇過這種情況:信寄出去,對方說沒收到,查了一下,原來進了垃圾桶,或者直接被退信。 收信方的伺服器不是隨機擋信的。它在執行一套規則——一套從 1980 年代到現在,被現實一次次逼著修改的規則。 要理解這套規則為什麼長成今天這個樣子,得從頭說起。 純真年代:信任是預設值 網際網路的前身 ARPANET,是 1960 年代末美國國防部和學術機構搭起來的封閉網路。用的人彼此認識,不是研究員就是工程師,根本沒有「壞人會進來」這個預設。 1982 年定案的 SMTP(簡單郵件傳輸協議)就是在這個背景下設計的。協議的名字裡有個「簡單」,不是謙虛,是真的很簡單——任何人架一台伺服器,就能對任何人寄信,沒有身份驗證,沒有來源確認。 📌 SMTP 是什麼? Simple Mail Transfer Protocol,1982 年制定,至今仍是所有電子郵件傳輸的底層協議。它規定了郵件伺服器之間怎麼對話、怎麼傳遞信件——但原始設計完全沒有驗證寄件人身份的機制。 這個設計在當時沒有問題。網路是封閉的,用戶是可信的,「簡單」就是美德。問題是,網際網路後來沒有維持封閉。 垃圾郵件的反撲:反解成為第一道門 1990 年代,網際網路向公眾開放,商業化浪潮湧入。原本安靜的學術網路,瞬間擠進了各種人。 1994 年,兩位美國律師對幾千個新聞群組大量發送廣告,這通常被認為是史上第一封現代意義的垃圾郵件。之後的十年,垃圾郵件量以指數成長——2003 年前後,全球電子郵件流量裡,垃圾郵件一度佔到 80% 以上。 收信方的伺服器需要一個快速判斷的方法。反解(PTR record)就是在這個時期成為業界慣例的。 📌 什麼是反解(PTR record)? DNS 正解是「把網域名稱查成 IP」,反解是反過來——「把 IP 查成對應的主機名稱」。例如把 203.x.x.x 查出來得到 mail.pcpilot.com.tw。 重點:PTR 記錄不是由網域擁有者設定,而是由持有該 IP 的 ISP 設定。你控制不了它,只能請求... » read more

免費仔的基礎架構學 — EmailJS、Resend、Cloudflare Free Tier 背後,藏著什麼商業邏輯?數據說話。
免費仔的基礎架構學 — EmailJS、Resend、Cloudflare Free Tier 背後,藏著什麼商業邏輯?數據說話。

免費仔的基礎架構學 EmailJS、Resend、Cloudflare Free Tier 背後,藏著什麼商業邏輯?數據說話。 Mr. τ 風雲網通系統有限公司 PCPiLOT 工程師思路系列・事出必有因 「免費」從來不是慈善。它是一種精心設計的獲客武器。 當你在用 Cloudflare 免費 CDN 的時候,你已經在它的飛輪裡了。 而這個飛輪,有數字為證。 先說結論:三個服務,三種不同的免費策略 很多人把 EmailJS、Resend、Cloudflare 放在同一個籃子裡,覺得「反正都是免費工具」。但如果你仔細拆開它們的商業模型,會發現三者根本不在同一條賽道上,免費的目的也完全不同。 這不是哪家比較好的問題,而是:它們各自在釣不同體型的魚,而且都算得很準。 接下來我會用公開財報與融資數據,把每一家的商業計算攤開來看。 EmailJS:最誠實的免費策略 EmailJS 解決的問題很具體:「我只想讓網頁表單能寄信,但我不想架伺服器。」 它的做法是在雲端代管 SMTP 連線,前端直接呼叫 SDK 就能寄信。 EmailJS 沒有公開財報,但它的官方定價頁上有一句話,把整個商業邏輯說得非常直白: “EmailJS Free plan is supported by EmailJS paid customers. If you would like to support our mission, please consider upgrading to a... » read more

從裸奔的 API Key 到全面打通的郵件架構 — 修一個問題,順著脈絡把旁邊的問題也一起收掉。
從裸奔的 API Key 到全面打通的郵件架構 — 修一個問題,順著脈絡把旁邊的問題也一起收掉。

PCPILOT · 工程師思路系列 Pico-UTM 行銷日: 從裸奔的 API Key 到全面打通的郵件架構 修一個問題,順著脈絡把旁邊的問題也一起收掉。 那天的任務很單純:為 Pico-UTM 100 的銷售衝刺準備材料。這批設備有點特別——三年資安服務授權綁定的 700Mbps UTM,價格實在超值到連我自己都先買了一台,是難得一見的尾盤機會。 從早上開始,文件、網頁工具、診斷問卷一份接一份。其中最花工夫的是「企業網路風險自我診斷」工具:業主勾選公司有哪些網路設備,系統依風險模型即時產生報告,同步寄信給業主和業務端。 測試完成,信寄出去,報告顯示正常。完美。然後習慣性地按了 F12。 裸奔的發現 EmailJS 的 Public Key、Service ID、兩組 Template ID,全部白紙黑字在原始碼裡。 📌 什麼是 API Key 裸奔? 網頁的所有程式碼,任何人都可以用瀏覽器「檢視原始碼」或開發者工具看到。如果服務的金鑰(API Key)直接寫在網頁裡,等同於把保險箱密碼貼在門口。拿到 EmailJS 的 Key,任何人都能冒用你的帳號大量寄信,直到額度用完或帳號被封。 做資安診斷工具的人,自己的工具先裸奔——這個畫面說不過去。當天就決定修掉。 路徑分歧:怎麼選解法 解法不只一條,每條都有代價。 方案 可行性 決定 自架後端伺服器 可行,Key 安全 ❌ 多管一台機器,排除 Resend 前端直打+Domain 限制 Key 洩漏仍可發詐騙信 ❌ 法律風險,排除... » read more

插上去它自己就知道要幾伏——Type-C 的電力自動協商機制
插上去它自己就知道要幾伏——Type-C 的電力自動協商機制

工程師思路系列 · 事出必有因 插上去它自己就知道要幾伏——Type-C 的電力自動協商機制 Mr. τ / 風雲網通系統有限公司 這篇文章的起點,其實是一個很實際的問題:商務與學習用途的筆記型電腦,續航力怎麼解決? 筆電最大的耗材,公認是電池模組。不管是可拆式還是內藏式,特定型號的電池往往搭配專屬保護晶片,正廠價格不低,副廠的單價與品質之間又難以取捨。對於經手大量企業設備的我來說,持續投資專屬電池模組並不划算——於是我把目光轉向了另一條路:能自行更換 18650 電池單體、且輸出電壓可調的行動電源。 當時採購的是七電品牌 QD188-BFC:八節 18650、2並4串結構、輸出電壓可調整,再搭配 34 種 DC 轉換頭,對應各廠牌筆電的不同母座型態。手邊也正好有數十顆從客戶汰換筆電回收來的 18650——19V 3.42A 的變壓器數量最多,電池拆出來堪用的不少。這套組合,在那個年代確實相當彈性。 📌 延伸知識|那 34 種頭到底長什麼樣? ▲ 34合1 筆電 DC 萬用轉接頭排卡實物(上中下三排,共 34 種規格) 把所有接頭分為上、中、下三排,標註物理尺寸與術語。幾個常見卻容易混淆的規格: 方口(11.0×4.5mm) ——專用於 Lenovo / ThinkPad 現代筆電,方形接口一眼可辨。 音叉頭 vs. 平口 ——音叉頭內壁嵌有十字彈片,相容性較高(5.5×2.1 音叉頭有機會同時兼容 2.1mm 與 2.5mm 內針);平口內壁光滑,尺寸差 0.1mm 就插不進去。 子彈頭(如 4.8×1.7mm) ——前端帶弧度縮口,常見於早期... » read more

換了高強度密碼還是失守 ——一個 SMB 郵件帳密持續洩漏案例的完整拆解
換了高強度密碼還是失守 ——一個 SMB 郵件帳密持續洩漏案例的完整拆解

部落格:換了高強度密碼還是失守——一個 SMB 郵件帳密持續洩漏案例的工程師視角 資安案例 · 工程師視角 換了高強度密碼還是失守 ——一個 SMB 郵件帳密持續洩漏案例的完整拆解 作者:Mr. τ|風雲網通系統有限公司(PCPiLOT)|2026 年 9 月 事件背景 某中小企業客戶的郵件帳號密碼遭到未授權方取得。事發後,來自境外(南非方向)IP 的主機,持續利用代管郵件主機大量對外寄信。 客戶第一次發現問題後更換了密碼。異常行為再度出現。第二次改用高強度密碼——問題仍然持續。 這一刻是整個案件的關鍵轉折點。 「換了高強度密碼還是失守」這件事,不應該被解讀為「密碼被暴力破解」。以現代密碼強度而言,暴力破解的可能性極低。更值得警戒的推斷是:存在某個環節,能在每次密碼更換後持續取得新版本帳密。 這個判斷改變了整個處置策略的方向。 已確認事實 vs. 推論 工程師思路的第一步,是把「確認知道的」和「還不知道的」分開。 已確認事實 郵件帳號遭未授權方取得並實際使用 境外 IP 利用代管主機大量對外寄信 更換密碼後異常行為再度出現,高強度密碼亦未能阻止 公司收發信工作站使用 Windows 7,已超出微軟支援期限 尚待確認(推論,非結論) 密碼洩漏的確切來源,目前有多種可能性,不能單憑現有現象判定: Windows 7 工作站本體漏洞遭利用,帳密被擷取 端點電腦遭 keylogger 或木馬感染 瀏覽器儲存的帳密遭取得 曾在其他地方保存的舊密碼被重複使用 郵件代管服務端或第三方服務發生問題 本次事件確認的是「郵件帳號遭未授權使用」,並非已確認公司內部電腦遭入侵。在釐清洩漏來源之前,任何過度的結論都會誤導處置方向。 處置架構:三層推進 1 立即止血 停用問題帳號,截斷現有入侵管道。重新建立新帳號與密碼,新帳密絕不在原可疑工作站上輸入——若舊電腦本身是洩漏來源,在同一台機器上輸入新密碼,等同於再次把新鑰匙送出去。改以 Windows 11 乾淨電腦作為郵件收發工作站。 2... » read more

SMB 防火牆採購決策系列・第三篇 – 那個接電話的人,才是你防火牆最重要的零件
SMB 防火牆採購決策系列・第三篇 – 那個接電話的人,才是你防火牆最重要的零件

那個接電話的人,才是你防火牆最重要的零件|工程師思路系列 工程師思路系列・事出必有因 PCPiLOT.com.tw SMB 防火牆採購決策系列・第三篇 那個接電話的人, 才是你防火牆最重要的零件 省下的 NT$6,000,你用什麼換來的? AI 助理查不到、搜尋引擎找不到的那一層知識, 決定了你出事時等多久、花多少、能不能解決。 閱讀時間約 12 分鐘 前兩篇我們談的是設備能力與持有成本。 這一篇要談一個被大多數採購決策完全忽略的因素: 建置這台設備的那個人,他知道多少你不知道自己不知道的事情。 一、業主自採:那個 NT$6,000 的省法 這個場景每隔一段時間就會發生一次: 同一台 Zyxel USG FLEX 100H,台灣通路報 NT$28,437。 Amazon 美國賣家折合台幣約 NT$22,000。 差了 NT$6,000。 對一個習慣比價的老闆來說,這筆差距很難視而不見。 邏輯上完全合理。設備是同一台,規格是同一份,為什麼不買便宜的? 因為那 NT$6,000 的差價,買走的不只是設備,還有以下這些東西——而這些東西在設備正常運作的時候完全感覺不到,等到出事那天才會知道它們的價格。 1 在地 RMA 管道斷掉 設備出問題,台灣換台灣,最快隔天。水貨走國際退換,三週起跳。你的公司能停擺三週等一台防火牆嗎? 2 原廠技術支援管道斷掉 台灣代理商有直通原廠 TAC(Technical Assistance Center)的管道,問題可以升級到原廠工程師。水貨序號在這條管道裡沒有身份,你的問題到代理商那裡就停了。 3 授權綁定可能出問題 部分品牌的授權與序號綁定,水貨序號在台灣可能無法啟用本地授權,或者後續續約時出現問題。這個坑通常在第二年才踩到。 二、AI 助理能幫你設定,但不能幫你負責 2026... » read more

SMB 防火牆採購決策系列・第二篇 – 你買的是設備,還是每年都要養的資安員?
SMB 防火牆採購決策系列・第二篇 – 你買的是設備,還是每年都要養的資安員?

你買的是設備,還是每年都要養的資安員?|工程師思路系列 工程師思路系列・事出必有因 PCPiLOT.com.tw SMB 防火牆採購決策系列・第二篇 你買的是設備, 還是每年都要養的資安員? NT$2–4 萬買了防火牆,第三年你還在付多少? 四個企業主真正在意的指標,重新算清楚這筆帳。 閱讀時間約 12 分鐘 上一篇我們談的是「你的防火牆,到底有沒有在看 HTTPS」。 這一篇要談一個更實際的問題: 防火牆買回來之後,第二年、第三年,你到底還在付什麼? 以及那些你沒算進去的隱性成本,其實可能比硬體本身貴得多。 一、SMB 老闆真正買的不是防火牆功能 市面上的防火牆評比通常長這樣:SPI 吞吐量、IPS 吞吐量、VPN 吞吐量、同時連線數……這些數字對 20–50 人的 SMB 來說,很多時候根本不是瓶頸。 企業主真正在意的,其實是四件事: 🛡️ 威脅阻攔 出事時它到底 擋不擋得住? 🔔 人工介入率 平常要不要 一直有人處理告警? ⚙️ 管理成本 IT 外包商要花 多少時間維護? 💰 年度續約費 第 2、3、4 年 到底還要花多少? 換句話說:SMB 老闆買的不是「防火牆功能」,而是「少出事、少叫人、少花錢」。 二、威脅阻攔率:那個百分比藏了什麼? 廠商宣傳常出現「Threat Protection 幾 Gbps」或「Security... » read more

2026 年 SMB 資安設備完整評析
2026 年 SMB 資安設備完整評析

SMB 資安閘道選購指南 2026|工程師思路系列 工程師思路系列・事出必有因 PCPiLOT.com.tw 2026 年 SMB 資安設備完整評析 你的防火牆,到底有沒有在看 HTTPS? 從 NT$3,699 到 NT$54,300,六款設備的真實能力差異, 以及為什麼「買了設備」不等於「有了防護」。 閱讀時間約 10 分鐘 這篇文章的起點,是一個很普通的詢價:「我需要一台防火牆,預算大概幾千塊。」 然後問題就來了——幾千塊能買到什麼?買到的東西,真的能防護什麼? 我們花了一整天把市面上的選項拆開來看,結果發現,這個問題比想像中複雜得多。 一、問題的根源:現代流量幾乎都是密文 現在的上網流量,絕大多數都走 HTTPS——網路上傳輸的封包是加密的。這件事對資安設備來說是個根本性的挑戰: 傳統防火牆能看到什麼? ✔ 你連到了哪個 IP、哪個網域(SNI) ✔ 流量大小與行為模式 ✗ 你下載了什麼檔案、網頁裡有什麼惡意腳本、傳輸的內容是否有病毒 這就是為什麼「有買防火牆」和「有防護 HTTPS 流量」是兩件完全不同的事。要真正掃描加密流量的內容,設備必須先把 HTTPS 解密、掃描、再重新加密——這個功能叫做 SSL/TLS Inspection,而它需要的計算資源遠比一般防火牆大得多。 概念解析・工程師白話版 HTTPS 是什麼?為什麼它讓資安掃描這麼難? ▌ HTTPS 是日常連線的標準,不是例外 HTTPS(HyperText Transfer Protocol Secure)是 HTTP 加上 TLS/SSL 加密層的組合。你現在打開任何一個網站、登入任何帳號、使用任何雲端服務,幾乎都走 HTTPS。它的設計目的是保護使用者隱私——確保資料在傳輸途中不被第三方竊聽或竄改。這是好事,但也帶來了資安防護的根本矛盾。... » read more

當 AI 開始以機器速度發現漏洞,SMB 的 IT 策略要怎麼布局?
當 AI 開始以機器速度發現漏洞,SMB 的 IT 策略要怎麼布局?

#SMB資安策略 #地端LLM #開源資安 #NAS韌性 #工程師思路系列 當 AI 開始以機器速度發現漏洞, SMB 的 IT 策略要怎麼布局? 2026 年 9 月  ·  Mr. τ  /  風雲網通系統 這篇文章來自一次完整的推論對話。從 AI 加速漏洞發現的現況,到開源資安引擎的崛起,到 NAS 廠商的鴨子划水,最終收斂到一個結論:底層邏輯從未改變,改變的是執行這些底層工作的智能程度。 一、漏洞正在以機器速度被發現 2026 年上半年,美國國家漏洞資料庫已記錄超過 45,000 個安全漏洞——接近 2025 年全年的總數。每月 CVE 揭露量在兩年內成長了 145%。Oracle 單月修補創下 1,449 個漏洞的歷史紀錄;Microsoft 的 Patch Tuesday 在六月和七月分別達到 571 和 622 個。 驅動這個數字的,是 AI。Anthropic 的 Mythos、Google 的 Big Sleep、OpenAI 的自主代理,都已展現在極短時間內發現並驗證漏洞的能力。攻擊者將漏洞轉化為可用程式碼的平均時間,從去年的... » read more

從防火牆到 AI:資安設備真正累積的,從來不只是防護功能
從防火牆到 AI:資安設備真正累積的,從來不只是防護功能

從防火牆到 AI:資安設備真正累積的,從來不只是防護功能 工程師思路系列 · Mr. τ / 風雲網通系統  |  PCPiLOT 最近在研究 LionFilter 200。原本只是很單純的問題:一台標榜 10GbE、AI、防毒、IPS、惡意網站防護的中小企業 UTM,到底值不值得放進工廠環境?但一路研究下來,我反而想到一件更有意思的事情——我們今天看到的「AI 智能資安」,背後有一條走了二、三十年的路。而真正累積價值的,也許從來不是某一個防毒引擎,而是「資料」。 第一代:防火牆只需要知道「這個封包能不能過」 早期的防火牆,思考方式很單純:來源 IP、目的 IP、Port、Protocol——符合規則就放行,不符合就丟掉。這是一種「規則式」安全模型,工程師先定義什麼可以通過,設備負責執行。 後來攻擊越來越複雜,光看 IP、Port 已經不夠。於是開始加入 Anti-Virus、IDS、IPS、Web Filter、Application Control、Anti-Spam……慢慢形成今天所謂的 UTM。看起來像是把很多安全產品塞進同一台盒子裡,但真正的變化是:設備開始「看懂」網路流量。 第二代:從「封包」走向「行為」 再往後,資安設備開始不滿足於「這個封包有沒有病毒?」,而是開始問: ✔這個使用者在做什麼? ✔這台電腦平常跟誰通訊? ✔這個帳號最近是不是突然出現不一樣的行為? 這就是網路行為分析、UEBA 等思維逐漸成熟的地方。舉例來說:某使用者平常上班時間使用 ERP、Office、Teams,但突然凌晨兩點從一台過去沒見過的裝置登入,開始大量讀取 NAS 資料,並把資料傳到從未連過的國外 IP——單看任何一件,不一定代表攻擊;把它們串起來,就開始有「故事」了。 真正有價值的資安系統,開始從「這個事件有沒有違反規則?」走向「這個行為,跟這個人平常的樣子有多不一樣?」 Palo Alto 這類產品,更早把問題往「行為情報」推 幾年前接觸 Palo Alto 的產品時,就已經看到這種思路。它不是單純把 Firewall、IPS、Application Control 一層一層疊上去,而是把使用者、裝置、App、URL、IP、流量與事件放進同一個上下文裡理解。於是設備看到的不再只是「某個 IP 連到某個 Port」,而是: 某個使用者,從某台裝置,在某個時間,以什麼方式,使用什麼應用程式,產生了什麼網路行為。 這個差別很大。因為「威脅」很多時候不是一個封包,而是一連串行為。 但行為模式從哪裡來?三層基準線... » read more

工程師事故檢討:AI 雖然很厲害, 遇到系統都故障時, 還得有人介入
工程師事故檢討:AI 雖然很厲害, 遇到系統都故障時, 還得有人介入

工程師思路系列・事出必有因 今天我才發現,自己也有一個單點故障 Mr. τ / 風雲網通系統有限公司(PCPiLOT) 今天奮鬥了一個上午,遇到一個本來不應該很難的事情,卻一直找不到入口。走完了我知道的每一條路,最後請同業先把客戶這邊撐住。 訂單完成了,客戶沒有感覺到什麼。但我知道今天付出的代價不只是分潤——是一個讓我靜下來想了很久的問題:做了這麼多年 IT,原來自己也有一個單點故障。 事情本身不複雜。但它牽涉的面向,值得認真整理一次。 本文討論面向 隱性危機 系統設計 UI/UX 流程設計 風險控管 權益維護 備援措施 商業模型 市場結構 知識工程 給 SMB 業主 補記・感謝 一、事情的輪廓 某個合作資格的審批流程卡住了。不是技術問題,不是帳號密碼錯誤,而是一個「資格狀態異常」,卻找不到一條清楚的路可以快速修復它。 我走了正常路:代理商說這屬於我跟上游之間的審核事務;上游支援走 Ticket 制;AI 助理給了十幾份看起來相關的文件,但沒有一份正好對上我現在的畫面。一個上午,就這樣過去了。 救援路徑示意 原本路徑 ✗ 你 → 代理商 → 上游 ↑ 資格狀態異常 ↓ 無法完成訂單 ↓ 客戶服務中斷風險 實際救援路徑 ✓ 你 → 同業(同一代理商) ↑ 資格狀態正常 ↓ 完成訂單 ↓... » read more

⚠️ 真實案例分享:社員的 Synology NAS 遭遇 DiskStation Security 勒索
⚠️ 真實案例分享:社員的 Synology NAS 遭遇 DiskStation Security 勒索

工程師思路系列・事出必有因 ⚠️ 真實案例分享:社員的 Synology NAS 遭遇 DiskStation Security 勒索 NAS 安全 · 勒索軟體 · 事件分析 · 防護建議 最近,社團裡一位朋友遇到了 NAS 使用者最不希望看到的情況。他的 Synology NAS 裡出現了一封勒索訊息。苦主分享了跟他看到一樣勒索信件內容的網頁。把這件事寫出來,是希望還沒中招的人,今天就花幾分鐘檢查自己的設定。 勒索訊息原文 以下是社員實際收到的訊息,一字不差: Hello. This is DiskStation Security. — 勒索訊息原文,社員 NAS 上實際出現 What happened? • Your network was not secure. • Your Network-Attached Storage was compromised. What does this mean? Where are my... » read more