信箱為什麼會出現自己寄給自己的勒索信或亂碼信?

CASE-STUDIES / 郵件伺服器資安

公司信箱出現看似由自己寄出的勒索信或奇怪亂碼信,不一定代表密碼被盜。本案例記錄舊版雷電郵件伺服器收到自動化探測郵件後,59IT如何檢查郵件標頭、SMTP驗證與信任IP,並收緊本地域名寄件規則。

發布:2026-09-03 更新:2026-09-04

30 秒看重點

寄件人欄位可以被冒用,所以畫面看起來像「自己寄給自己」,不代表帳號真的登入寄信。這次確認舊設定只檢查本地帳號是否存在,沒有要求外部來源先通過SMTP AUTH或信任IP;收緊規則後,未驗證的外部冒用寄件會被拒絕或攔截。

客戶類型

使用舊版雷電郵件伺服器的企業客戶(網域與信箱均已遮蔽)

遇到的問題

郵件主機在短時間內收到六封由同一個本地信箱名稱寄出的異常郵件,主旨與內文帶有XSS、標頭注入、附件上傳及一次性寄送測試標記。

原因判斷

舊規則只要求本地寄件人信箱是存在的帳號,沒有要求外部連線宣告本地域名寄件人時必須先通過SMTP AUTH或信任IP檢查,因此外部來源可能冒用既有信箱名稱。現有紀錄不足以認定密碼外洩或漏洞利用成功。

解決方案

公開版匿名處理:客戶信箱、網域、來源IP、郵件識別碼與精確時間均已遮蔽。以下保留的是判斷問題所需的技術特徵。

為什麼寄件人會顯示成自己的信箱?

電子郵件畫面上的寄件人欄位可以被外部寄件者宣告成別人的地址,就像信封上可以寫上別人的名字。因此,收到一封看似由自己寄出的勒索信、詐騙信或亂碼測試信,並不等於對方已登入你的帳號。

這類郵件仍然不能忽略。正確作法是保留原始郵件標頭與伺服器日誌,再檢查是否有成功的SMTP AUTH、異常登入、寄件佇列、來源IP或開放轉送紀錄。

本次案例發生什麼事?

某企業自架的舊版雷電郵件伺服器,在短時間內收到六封異常郵件。畫面顯示的寄件人都是同一個公司信箱,但主旨與內文帶有規律的測試標記,不是正常商務往來。

  • XSS探測:測試Webmail或郵件內容顯示時,是否會錯誤執行標記。
  • 標頭注入探測:嘗試加入額外郵件標頭,觀察解析與過濾結果。
  • 附件處理探測:短時間連續出現attach、upload及one-shot等自動化主旨。
  • 本地域名冒用:外部來源把寄件人宣告成s***@[客戶網域已遮蔽]。

先分清楚四件事

  • 寄件人欄位被冒用:From可以被宣告成別人的信箱,不代表該帳號真的登入。
  • 帳密外洩:要查SMTP AUTH、登入、佇列與帳號活動紀錄才能判斷。
  • 開放轉送:需要從外部網路做受控測試,不能只看一封郵件下結論。
  • 弱點探測:出現測試字串代表有人嘗試,不等於XSS、標頭注入或附件漏洞已成功。

本案較合理的初步判斷,是外部自動化工具冒用既有本地信箱名稱,探測內容過濾、附件解析與郵件轉送限制;現有紀錄不足以認定使用者密碼遭竊。

舊設定的問題在哪裡?

原規則:本地寄件人信箱必須是存在的帳號。這只能確認信箱名稱存在,不能確認寄件者就是本人。

改善規則:內送郵件若宣告使用本地域名寄件人,必須先通過SMTP身分驗證或核准的來源IP檢查。外部來源未通過SMTP AUTH、也不在信任IP範圍時,就在伺服器端拒絕或攔截。

這是舊環境的信任規則沒有收緊,不應直接解讀為雷電郵件伺服器產品存在已證實漏洞。相同設定風險也可能出現在其他品牌或自行架設的SMTP服務。

59IT實際處理步驟

  1. 保留原始郵件標頭、SMTP日誌與異常郵件時間序列。
  2. 檢查Received鏈、來源IP、SMTP AUTH、寄件佇列與轉送紀錄。
  3. 啟用本地域名寄件人的SMTP驗證或信任IP檢查。
  4. 縮小信任IP,只保留必要的內部主機、印表機與通知設備。
  5. 逐一測試Outlook、內部系統及既有合法寄件設備。
  6. 持續觀察外部來源冒用本地域名的寄送嘗試。

處理後驗證結果

  • 防偽選項已啟用,設定成功寫入。
  • SMTP服務、原有內容過濾及SMTP AUTH維持正常。
  • 合法Outlook帳號與核准的內部來源仍可寄信。
  • 未驗證的外部來源無法再只靠宣告既有信箱名稱送入使用者信箱。

常見問題

收到自己寄給自己的勒索信或亂碼信,代表密碼被盜嗎?

不一定。必須再查SMTP AUTH紀錄、Received標頭、來源IP、登入紀錄與寄件佇列。本案例沒有足夠證據認定使用者密碼外洩。

這些測試郵件代表郵件伺服器已被入侵嗎?

不能只憑主旨或測試字串下結論。它們較像自動化探測;是否成功利用仍要以伺服器日誌、檔案變更與服務狀態判斷。

啟用本地寄件人驗證後,Outlook還能寄信嗎?

正常使用SMTP AUTH的Outlook可以繼續寄信。無法驗證的內部設備應限定核准來源IP,設定後逐一測試。

SPF、DKIM與DMARC可以取代SMTP AUTH嗎?

不行。SPF、DKIM與DMARC協助收件端判斷網域郵件真偽;SMTP AUTH與信任IP控制誰能透過自己的主機寄信,兩者應搭配使用。

怎麼判斷郵件主機是不是開放轉送?

需要從外部網路以未驗證身分做受控測試,並查看SMTP回應與日誌。不要只看一封可疑郵件就認定是Open Relay。

結論

本次重點不是只更改使用者密碼,而是修正郵件主機對本地寄件人的信任邏輯。外部連線若宣告使用企業本地域名,必須先通過SMTP身分驗證或核准IP檢查,才能降低網域冒用與未授權寄送風險。

公司信箱出現奇怪郵件時,請先保留原始標頭與日誌。可將匿名化資料傳給59IT協助判斷,再依實際環境安排處理。LINE:@844dsvix,電話:0917559559。

處理成果

防偽規則已啟用並成功寫入;SMTP服務、既有內容過濾及SMTP AUTH維持正常,合法Outlook帳號與核准的內部來源仍可寄信。後續持續觀察未驗證外部來源是否再次冒用本地域名。

重點整理

  • 寄件人欄位可被冒用,不等於帳號真的登入寄信
  • XSS、標頭與附件測試字串代表探測,不等於漏洞利用成功
  • 原設定只確認本地信箱存在,未確認寄件者身分
  • 本地域名寄件人需通過SMTP AUTH或核准的來源IP
  • 設定後仍須測試Outlook及內部設備並持續觀察日誌

結論

本案處理重點不是只更改使用者密碼,而是修正郵件主機對本地寄件人的信任邏輯。外部連線若宣告使用企業本地域名,必須先通過SMTP身分驗證或核准的IP檢查,才能降低網域冒用與未授權寄送風險。

#雷電郵件伺服器#RaidenMail#自己寄給自己的信#勒索信#亂碼信#寄件人偽造#SMTP AUTH#郵件主機資安#標頭注入探測#XSS郵件#信任IP#Open Relay#企業郵件維護

← 返回Case Study 維修案例