第 15 章 使用寄件者策略架構處理偽造的電子郵件

垃圾郵件製造者與電子郵件詐騙者通常會使用假的網域名稱與電子郵件位址，或使用合法的網域名稱與電子郵件位址，讓使用者誤認為郵件來自他們所認識的某人或某家公司，以遂行其偽造電子郵件之目的。例如，垃圾郵件傳送者可能會從 president@whitehouse.gov 之類的位址寄出電子郵件，以誘騙使用者誤認為該郵件真的是從此位址寄出。偽造的電子郵件可誘使使用者開啟不當郵件，甚至提供資訊給假造的機構。此外，垃圾郵件傳送者也經常從不在 RBL 清單中的合法網域傳送其電子郵件。

寄件者策略架構 (SPF) 是一項可在 SMTP 對話期間偵測及拒絕偽造電子郵件的技術。明確而言，SPF 是一項可讓網域明確授權給能夠使用其網域名稱之主機的協定。此外，您也可以配置接收端主機，使其檢查此授權。SPF 因此得以大幅降低偽造電子郵件的肆虐。

• 15.1 作業原理

• 15.2 限制

• 15.3 預先部署注意事項

• 15.4 設定技術

• 15.5 參照資訊

• 15.6 使用 spfquery 測試 SPF

• 15.7 使用寄件者重寫機制 (SRS) 處理 SPF 中的轉寄郵件

15.1 作業原理

當郵件進入 Messaging Server 時，MTA 會執行 SPF 查詢，以判斷位址是否確實來自該位址上的網域。SPF 查詢會查看 DNS 中有無屬於該郵件網域 (domain) 的 TXT 記錄Domain 可能是指定為 HELO 或 EHLO 之引數的網域名稱 (若使用 spfhelo 通道關鍵字)，或是以 MAIL FROM: 指令指定之創建者位址中的網域名稱 (通常為 @ 字元後的部分)。若未指定或沒有可用的網域名稱，則會以在 HELO/EHLO 期間指定的網域名稱做為 domain。請注意，大部分的 ISP 會提供符合其網域的 IP 位址授權清單。若 IP 位址不符合網域名稱，郵件將被假定為是偽造郵件。

查詢 DNS 之前，我們會先查看 SPF_LOCAL 對映表中有無相符的網域。若其中有相符網域，則會先使用此網域。

若在對映表中找到的記錄含有 redirect=domain 陳述式，則會透過 DNS 查詢重新導向至該網域，而略過遞迴與備援對映檔案檢查。

以下是所產生之 TXT 記錄的範例：

v=spf1 +mx a:colo.siroe.com/28 -all

此 RFC 所支援的 SRF 記錄必須使用 v=spf1 記號。

+mx 會引導我們查看 MX 記錄中的 domain，並確認此 SMTP 連線的來源 IP 位址，符合針對 domain 指定為 MX 查詢結果之 IP 位址之一。若有相符項目，+ 表示其結果為 Pass。

a:colo.siroe.com/28 會引導我們查看 A 記錄中的 colo.siroe.com，然後確認此 SMTP 連線的來源 IP 位址與 A 記錄位於相同的指定 CIDR 子網路中，而僅比較 28 個位元 (根據 255.255.255.240 進行遮罩)。其中未指定限定符號，因此會預設為 +，表示相符項目會產生 Pass。

最後，-all 會比對其他所有項目，而產生 Fail。如需 SPF 記錄更完整的說明，請參閱 RFC 4408，網址是 http://www.ietf.org/rfc/rfc4408.txt

SPF 處理可能會有數種結果。下表列出這些結果及其說明。

SPF 處理完成後，會在郵件中寫入 Received-SPF: 標頭，以記載 SPF 處理的結果。此標頭可在後續的篩選處理期間接受查詢，以提供相關注意事項。若已在 option.dat 檔案中啟用 MTA 選項 MM_DEBUG (>0)，則可進行廣泛的除錯。

15.2 限制

SPF 只是用以對抗垃圾郵件的工具之一，並無法解決所有問題。垃圾郵件傳送者可輕易地建立網域，並增加 SPF TXT 記錄而使該網域看似合法。另一方面，雖然有許多 TXT 記錄並不會使 SPF 產生失敗狀態，但 SPF 仍可有效從已建立的 ISP 中偵測出偽造的電子郵件。

15.3 預先部署注意事項

您的系統上務必要有速度夠快的 DNS 伺服器，因為每則郵件都必須執行 DNS 查詢。

15.4 設定技術

設定 SPF 技術時需執行兩個步驟：

• 提供內送 TCP 通道 (通常為 tcp_local 通道，雖然在允許 tcp_local 切換至其他通道的情況下，可能會有其他通道) 的通道關鍵字。請參閱表 15–2

• 設定 option.dat 檔案中的選項。請參閱表 15–3

15.5 參照資訊

本節提供 SPF 通道關鍵字與 SPF MTA 選項的參照資訊。SPF 支援可透過四個適用於內送 tcp_* 通道 (通常為 tcp_local) 的通道關鍵字進行實作。下表列出這些關鍵字及其說明。

spfmailfrom 與 spfrcptto 為彼此衝突的關鍵字，在通道上應指定其中一個關鍵字即可。但您可以將 spfhelo 與 spfmailfrom 或 spfrcptto 搭配使用，同時執行兩種 SPF 檢查。

此外還有其他支援，可讓您建立 SPF 處理的限制，以及控制是否要接受 SMTP 指令、是否以 4xx 回應拒絕 (暫時性失敗)、或是以 5xx 回應拒絕 (永久性失敗)，以產生不同的 SPF 結果，包括：Fail、SoftFail、 PermError 與 TempError。

下列 MTA 選項位於 option.dat 中，可用以設定 SPF 處理的限制。

此外，您也可以配置 option.dat 中的下列 MTA 選項，以控制在回應 Fail、SoftFail、PermError 與 TempError 的 SPF 結果時，SMTP 伺服器所將採取的運作方式。對於上述各結果，SMTP 伺服器可傳回 2xx (成功) 回應、4xx (暫時性失敗) 或 5xx (永久性失敗)。此外，對於 Fail 與 SoftFail，MTA 可區分做為「所有」機制產生之結果的 SPF 結果，以及其他明確參照之相符項目的 SPF 結果。接著您即可區分特定結果與 SPF 記錄的預設結果。其中任一選項的有效值為 2、4 或 5。2、4 或 5 等值，分別對應於 SMTP 伺服器取得特定 SPF 狀態的 2xx、4xx 或 5xx 回應。因此，舉例來說，若 SPF_SMTP_STATUS_FAIL=2 且 SPF 記錄明確地對我們封鎖 "-a:192.168.1.44" (我們的 IP 位址)，則我們將以 "250 OK" 接受該位址，而不是以 5xx 進行回應。

15.6 使用 spfquery 測試 SPF

此測試公用程式可用以測試 SPF 處理。

spfquery 不會測試您的 SPF 配置。它會測試 SPF 處理啟用時的傳回項目。

需求：必須以具有相關存取權能夠執行 Messaging Server 二進位檔及存取其程式庫 (如 root 或 mailsrv) 的使用者身份執行。

位置：msg-svr-base/sbin/

15.6.1 語法

spfquery [-i ip-address] [-s sender-email] [-h helo-domain]
  [-e none | neutral | pass | fail | temperror | permerror] [-v] [-V] [?] domain

下表列出 spfquery 選項及其說明。

-?

15.6.2 啟用除錯時的範例

# /opt/SUNWmsgsr/sbin/spfquery -v -i 192.168.1.3 11.spf1-test.siroe.com
    Running SPF query with:
      IP address: 192.168.1.3
          Domain: 11.spf1-test.siroe.com
          Sender: postmaster@11.spf1-test.siroe.com (local-part: postmaster)
     HELO Domain: 11.spf1-test.siroe.com

    15:30:04.33: ----------------------------------------------------------------
    15:30:04.33: SPFcheck_host called:
    15:30:04.33:       source ip = 192.168.1.3
    15:30:04.33:          domain = 11.spf1-test.siroe.com
    15:30:04.33:          sender = postmaster@11.spf1-test.siroe.com
    15:30:04.33:      local_part = postmaster
    15:30:04.33:     helo_domain = 11.spf1-test.siroe.com
    15:30:04.33:
    15:30:04.33:   Looking up "v=spf1" records for 11.spf1-test.siroe.com
    15:30:04.35:     DNS query status: Pass
    15:30:04.35:       "v=spf1 mx:spf1-test.siroe.com                  -all"
    15:30:04.35:
    15:30:04.35:   Parsing mechanism: " mx : spf1-test.siroe.com"
    15:30:04.35:     Assuming a Pass prefix
    15:30:04.35:     Processing macros in spf1-test.siroe.com
    15:30:04.35:     Comparing against 192.168.1.3
    15:30:04.35:     Looking for MX records for spf1-test.siroe.com
    15:30:04.41:       mx02.spf1-test.siroe.com:
    15:30:04.41:         192.0.2.22 - No match
    15:30:04.41:         192.0.2.21 - No match
    15:30:04.41:         192.0.2.20 - No match
    15:30:04.41:         192.0.2.23 - No match
    15:30:04.41:       mx01.spf1-test.siroe.com:
    15:30:04.42:         192.0.2.13 - No match
    15:30:04.42:         192.0.2.11 - No match
    15:30:04.42:         192.0.2.12 - No match
    15:30:04.42:         192.0.2.10 - No match
    15:30:04.42:       mx03.spf1-test.siroe.com:
    15:30:04.42:         192.0.2.32 - No match
    15:30:04.42:         192.0.2.30 - No match
    15:30:04.42:         192.0.2.31 - No match
    15:30:04.42:         192.168.1.3 - Matched
    15:30:04.42:   Mechanism matched; returning Pass
    15:30:04.42:
    15:30:04.42:   Parsing mechanism: "- all : " (not evaluated)
    15:30:04.42:
    15:30:04.42: SPFcheck_host is returning Pass
    15:30:04.42: ----------------------------------------------------------------

15.7 使用寄件者重寫機制 (SRS) 處理 SPF 中的轉寄郵件

如前所述，SPF 是嘗試防範電子郵件偽造的機制，方法是查找與電子郵件 FROM: (訊息封寄件者) 位址網域相關聯的特殊 TXT 記錄。這項作業實際涉及多個 DNS 查找程序，最後會產生一份清單，其中包含經授權可從網域傳送郵件的 IP 位址。SMTP 用戶端的 IP 位址會根據這份清單進行檢查，如果在清單中找不到位址，郵件會被視為偽造。Messaging Server 6.3 版支援 SPF。

SPF 會針對提供郵件轉寄服務的站點，例如大學 (針對其校友) 或專業組織 (針對其成員)，舉發重大問題。轉寄者不會發送來自任意寄件者的郵件，其中包括已實作 SPF 策略的寄件者。當然，這些寄件者並不會列出轉寄系統，或允許使用該網域位址的系統的 IP 位址。

寄件者重寫機制 (SRS) 提供此問題的解決方案。SRS 使用寄件者的網域，將原始寄件者的位址封裝至新位址中。只有轉寄者自己的網域會顯露供 SPF 檢查。使用位址時，它會將郵件 (通常是通知) 路由至轉寄者，這會移除位址封裝，並且繼續將郵件傳送至實際的目標。

當然，位址封裝不一定是最新的。來源路由是在 RFC 822 中進行定義的，可提供與百分比入侵路由和 Bang 路徑相同的功能。然而，這些機制在現今的網際網路上都會造成問題，原因是使用這些機制會使得系統成為公開的中繼。

SRS 會將輸入的雜湊和時間戳記新增至封裝格式，以處理此問題。位址只在一段時間內有效，此後便無法再使用。雜湊可避免時間戳記或封裝的位址遭到修改。

SRS 也提供處理多重躍點轉寄機制，而不會使位址長度過度增長。為求有效運作，必須在實作 SRS 的全部系統上統一某些部分的 SRS 位址格式。

SRS 支援現在可在 6.3P1 發行版本上實作。新增下列 MTA 選項：

• SRS_DOMAIN。這必須設定為網域，才能在 SRS 位址中使用。傳送至此網域的電子郵件必須固定路由至一個能對網域進行 SRS 作業的系統。SRS 處理的程序是在一般位址上重疊，因此站點不會無法使用主網域作為 SRS 網域。

• SRS_SECRETS。這是以逗號分隔的 SRS 位址編碼解碼秘密金鑰清單。清單的第一個金鑰一律用於編碼。對於解碼，每個金鑰都會經過嘗試，以產生不同的雜湊值。如果有任何相符的雜湊值，解碼作業就會進行。

  使用多個金鑰的功能可在變更秘密金鑰時繼續服務：新增第二個金鑰，並等候先前發出的全部位址逾時，然後移除第一個金鑰。

• SRS_MAXAGE。可選擇在訊息逾時之前的天數。如果未指定選項，預設值是 14 天。

  每個選取的 SRS 網域電子郵件處理系統都必須對 SRS 處理進行配置，並且必須使 3 個 SRS 選項的設定全都相同。

設定這些選項即可啟用 SRS 位址解碼。編碼是另一項不同的程序，這必須在您知道與轉寄作業相關聯的訊息封 From: 位址上進行。SRS 編碼是由 6 個新的通道關鍵字進行控制：addresssrs、noaddresssrs、destinationsrs、nodestinationsrs、sourcesrs 及 nosourcesrs。

有 3 項條件必須都符合，SRS 編碼才會進行：

(1) 目前來源通道必須標記為 sourcesrs。 (預設值是 nosourcesrs)。

(2) 目前目標通道必須標記為 destinationsrs (預設值是 nodestinationsrs)。

(3) 進行重寫時，目前位址必須符合標記 addresssrs 的通道 (預設值是 noaddress)。

只有在這些條件全都符合時，才會進行編碼。最簡單的設定僅轉寄進出 tcp_local 通道的全部訊息，且所有非本機的位址都需要 SRS 處理。在這類設定中，tcp_local 會以 sourcesrs、destinationsrs 和 addresssrs 這 3 個關鍵字標記。

最後，imsimta test -rewrite 已經過增強，可針對任何輸入的位址顯示 SRS 編碼和解碼的結果。例如，位址 foo@example.com 可能會產生如下的輸出：

SRS encoding = SRS0=dnG=IS=example.com=foo@example.org

如果這個編碼位址經過重寫，會產生下列輸出：

SRS decoding = foo@example.com

imsimta test -rewrite 也會顯示 SRS 解碼期間出現的任何錯誤。