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 解碼期間出現的任何錯誤。