為什麼你的聯絡表單是最大的垃圾郵件風險

問題比你想像得更早就存在

自 2000 年代初期以來，聯絡表單就一直是垃圾郵件的攻擊途徑；而隨著電子郵件服務供應商收緊驗證要求，問題變得更嚴重。多數聯絡表單仍以相同方式建置：使用者填寫表單，你的伺服器在 From 標頭中使用使用者的地址寄出電子郵件，然後你等待回覆。

這是典型的電子郵件偽造漏洞。垃圾郵件發送者可以利用你的表單寄送看似來自任何他們想要的地址、但經由你伺服器 IP 路由的郵件。如果有足夠多垃圾郵件以這種方式寄出，你的網域就會被標記，而你的合法交易型郵件也會停止進入收件匣。

修正方式很直接，但多數教學仍然做錯。

聯絡表單為何如此容易被利用

典型的聯絡表單會接受三個欄位：姓名、電子郵件和訊息。伺服器端處理程式會拿取該電子郵件地址，並直接放入外寄 SMTP 訊息的 From 標頭。這對回覆很方便——你只要在收件匣中按下「回覆」即可——但這也等於送給垃圾郵件發送者一份大禮。

當垃圾郵件發送者找到你的表單時，會發生以下情況：

1. 他們在「from」欄位中填入受害者的電子郵件地址並送出表單
2. 你的伺服器照單全收，寄出一封在 From 標頭中使用該受害者地址的電子郵件
3. 受害者的郵件伺服器看到一封聲稱來自其網域、但源自你 IP 的電子郵件
4. 如果你的網域缺乏適當的 SPF/DKIM/DMARC 記錄（即使有也一樣），郵件仍可能通過，因為許多伺服器對聯絡表單流量較為寬鬆
5. 受害者收到看似來自自己地址的垃圾郵件，或你的網域因偽造而被標記

這不是理論上的攻擊。它一直在發生。如果你有運作中的聯絡表單，而且從未檢查過郵件伺服器記錄，你很可能已經被以這種方式利用。

寄送聯絡表單電子郵件的正確方式

修正方式是永遠不要把使用者輸入放進 From 標頭。改為：

• From: [email protected]（或任何你控制的地址）
• Reply-To: 使用者提交的電子郵件地址
• Subject: 如果你想，可以包含使用者姓名，但絕不要包含他們的電子郵件
• Body: 包含所有表單資料，並清楚標示

如此一來，你的伺服器只會從你擁有且已正確驗證的地址寄送電子郵件。當你在收件匣中按下「回覆」時，郵件仍會寄給使用者——這正是 Reply-To 的用途。但垃圾郵件發送者無法利用你的表單冒充任意地址。

多數電子郵件函式庫都原生支援這種做法。在 PHP 的 PHPMailer 中：

$mail->setFrom('[email protected]', 'Contact Form');
$mail->addReplyTo($_POST['email'], $_POST['name']);

在 Python 搭配 smtplib 與 email.mime 時：

msg['From'] = '[email protected]'
msg['Reply-To'] = form_data['email']

在 Node.js 搭配 Nodemailer 時：

const mailOptions = {
  from: '[email protected]',
  replyTo: req.body.email,
  // ...
};

如果你的聯絡表單目前把使用者輸入放進 From 標頭，這是一行就能修正的問題。今天就處理。

速率限制不是可選項

即使標頭處理得當，未受保護的聯絡表單仍然是垃圾郵件途徑。垃圾郵件發送者會用不同的訊息內容送出數百次表單，而你的收件匣會被垃圾填滿。

你需要在多個層級做速率限制：

• 依 IP: 同一 IP 每小時不超過 5 次提交
• 依電子郵件: 同一電子郵件地址每天不超過 3 次提交
• 全域: 所有使用者合計每小時不超過 50 次提交（依你的流量調整）

速率限制應該放在應用程式程式碼中，而不只是放在網頁伺服器設定裡。Nginx 和 Apache 的速率限制可以提供協助，但它們在請求層級運作，並不知道電子郵件地址或表單特定的濫用模式。

如果你使用框架，通常會有可直接加入的速率限制 middleware。如果你從零開始建置，使用帶有過期鍵的簡單 Redis 計數器就足夠：

key = f"contact_form:{ip_address}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, 3600)  # 1 hour
if count > 5:
    return error("Rate limit exceeded")

這並非無懈可擊——垃圾郵件發送者可以輪換 IP——但它會大幅提高濫用成本。

CAPTCHA 是取捨，不是解方

Google 的 reCAPTCHA v3 是隱形的，並會根據行為為使用者評分，聽起來很理想。實務上，它封鎖合法使用者的頻率比你預期更高，特別是使用 VPN、Tor 或共用企業網路的使用者。

reCAPTCHA v2（「我不是機器人」核取方塊）較可靠，但會增加阻力。Honeypot 欄位——人類不會填寫、但機器人會填寫的隱藏表單輸入——能在不影響使用者的情況下抓到低階機器人，但任何認真的垃圾郵件發送者都能輕易繞過。

最佳做法是分層：

1. 正確的電子郵件標頭（不可妥協）
2. 速率限制（不可妥協）
3. Honeypot 欄位（容易取得的成效，沒有缺點）
4. 只有在上述措施後仍收到大量垃圾郵件時，才使用 CAPTCHA

如果你確實加入 CAPTCHA，請使用 reCAPTCHA v3 搭配較低門檻（0.5 或更低），並為評分較差的使用者提供 v2 備援。這能讓多數使用者的阻力維持在低水準，同時仍能阻擋機器人。

何時使用第三方表單服務

如果你經營的是小型網站，且不想維護表單基礎設施，Formspree、Tally 或 Netlify Forms 等第三方服務會替你處理這一切。它們會進行速率限制、驗證，並從自己的網域寄送電子郵件，因此你的聲譽能保持乾淨。

取捨在於你會把使用者資料送給第三方，這可能與你的隱私權政策或 GDPR 義務衝突。在用戶端處理資料是重視隱私團隊日益採用的趨勢，但聯絡表單本質上需要伺服器端處理——你無法在不暴露憑證的情況下從瀏覽器寄送電子郵件。

如果你處理敏感詢問（法律、醫療、財務），你可能需要自行運作表單基礎設施。除此之外，第三方服務是合理選擇。

DMARC 問題

即使你修正了聯絡表單標頭，如果你的網域缺乏 DMARC 政策，仍然不安全。DMARC 會告訴收件郵件伺服器，當電子郵件未通過 SPF 或 DKIM 檢查時該怎麼做。沒有它，垃圾郵件發送者仍能寄送看似來自你網域的電子郵件，即使他們沒有使用你的伺服器。

設定 DMARC 超出本文範圍，但如果你重視電子郵件聲譽，這是不可妥協的。先從僅監控政策（p=none）開始，並在確認你的合法電子郵件都已正確驗證後，逐步移至 p=quarantine 或 p=reject。

那麼Cookie 同意與表單追蹤呢？

如果你的聯絡表單使用分析或行銷像素來追蹤提交，你很可能受到 GDPR 和 ePrivacy 規則約束。多數聯絡表單不需要追蹤——你收到電子郵件時就已經知道有人提交了表單——但如果你使用 Facebook Pixel 或 Google Analytics 事件之類的工具，就需要在這些指令碼載入前取得明確同意。

最簡單的做法是完全不要追蹤聯絡表單提交。如果你必須追蹤，只在使用者同意後才載入追蹤指令碼，並確保你的同意橫幅符合法規。

重點摘要

• 絕不要把使用者提交的電子郵件地址放進 From 標頭。改用 Reply-To。
• 速率限制是必要的。請在應用程式層級實作，而不只是網頁伺服器。
• Honeypot 欄位是零成本的好處。CAPTCHA 應該是最後手段。
• 對小型網站而言，第三方表單服務是合理選擇，但會帶來隱私取捨。
• 如果你從自己的網域寄送任何電子郵件，就需要 DMARC 政策。

FAQ

Q: 我可以直接停用聯絡表單，改用 mailto 連結嗎？

A: 可以，但 mailto 連結會把你的電子郵件地址暴露給爬蟲，而且你會失去收集結構化資料的能力。如果垃圾郵件已經多到難以承受，mailto 連結比壞掉的聯絡表單好；但修好表單比兩者都更好。

Q: 如果我基於合法原因需要從使用者的地址寄送電子郵件呢？

A: 你幾乎肯定不需要。如果你認為需要，你可能是在解決一個 Reply-To 已經能解決的工作流程問題（例如回覆路由）。如果你真的需要從任意地址寄送電子郵件，你需要的是具備適當驗證的專用電子郵件服務，而不是聯絡表單。

Q: 我要如何知道我的聯絡表單是否已經被濫用？

A: 檢查你的郵件伺服器記錄中的外寄 SMTP 連線。如果你看到大量外寄電子郵件寄往你不認識的地址，或你的網域已被 Spamhaus 等垃圾郵件資料庫標記，你很可能正被用作中繼。MXToolbox 等工具可以檢查你的網域聲譽。

Q: 使用免費 CAPTCHA 服務安全嗎？

A: Google 的 reCAPTCHA 免費且廣泛使用，但它會把使用者資料送到 Google，這可能與你的隱私權政策衝突。hCaptcha 是重視隱私的替代方案，不會用你的使用者來訓練 AI 模型。Cloudflare Turnstile 是另一個選項，比傳統 CAPTCHA 更不具侵入性。

Q: SPF、DKIM 和 DMARC 有什麼不同？

A: SPF 列出哪些郵件伺服器被允許從你的網域寄送電子郵件。DKIM 會以密碼學方式簽署外寄電子郵件，讓收件者能驗證郵件未被竄改。DMARC 則將兩者串接起來，並告訴收件者當電子郵件未通過 SPF 或 DKIM 檢查時該怎麼做。你需要三者才能具備適當的電子郵件驗證。

Sources

• OWASP: Email Header Injection — 詳細說明聯絡表單如何被利用於電子郵件偽造。
• RFC 5322: Internet Message Format — 定義電子郵件標頭（包括 From 和 Reply-To）的技術標準。
• DMARC.org: Overview — 了解與實作 DMARC 政策的官方資源。
• Spamhaus: Domain Blocklists — 檢查你的網域是否因垃圾郵件被標記，並了解封鎖清單如何運作。