iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 16
0
Security

企業訊息溝通安全系列 第 16

郵件外寄透過雲端服務轉送 (SMTP relay) 代發架構

  • 分享至 

  • xImage
  •  

企業郵件外寄一般會遇到的退信問題,除了收信方主機帳號不存在或信箱空間滿載外,多半就是被主機的過濾機制阻擋,而阻擋原因存在各種可能性,包含 SMTP 連線階段被阻擋,或者通過 SMTP 連線檢查之後,被其他過濾機制包含病毒、特徵分析、貝氏過濾、防詐騙釣魚、沙箱防護等內容過濾機制阻擋。

不論哪一種過濾機制,要避免被退信首先就要通過 SMTP 連線檢查,SMTP 連檢查標準首先是進行 DNS 反查,包含 HELLO 資訊是否符合 RFC 規定、來源 IP 反查是否正確查詢到主機名稱、MX 紀錄資訊是否一致等。但這些連線檢查的前提要件是網路連通必需在一個正常的回應下才能完成。由於企業多半是自行建置機房,如果網路連通不穩定,很有可能就會影響 SMTP 連線的判斷,造成企業外寄信件被收信方主機阻擋或者被誤檢舉到網路上即時阻擋清單(Real time Block List,RBL)名單上。

企業一旦發生網路連通不穩定的情況,查修其實是相當耗費人力資源成本的事情,包含跟對外連線有關的主機、網路設備甚至網路線都必須逐一檢查連通狀況,找出根因 (root cause) 的方法,多半是靠實驗組跟對照組,但因為基礎建設環境有異常,有可能一條網路線品質老舊,或者某一個網路通訊埠 (Port) 回應延遲,就會造成 SMTP 服務不穩定,更提高的查修的複雜度。

因此企業多半會準備第二組機房線路,當主線路不穩時可切換備援線路來維持服務,但就會面臨到第二組機房軟硬體建設的投資成本、維運的問題。因此除了第二組機房線路的選擇外,因應雲端服務趨勢,企業也可以選用雲端服務來協助轉送。
https://ithelp.ithome.com.tw/upload/images/20200918/2000018164Py02U2ZC.jpg

透過雲端服務轉送前,由於標準雲端服務是不允許來路不明的連線進行轉送 (SMTP relay) 請求,會需要先跟雲端服務提供商完成服務的申請,取得雲端服務提供驗證機制或允許轉送的授權後,就可以將郵件主機外寄導向雲端 SMTP Gateway 進行對外發信。上述應用情境談到的方案是以解決發信不穩定,但實務上企業內部會因為整合其他系統需求,例如事務機、印表機、人事差勤系統、監控系統,也會需要將相關信件透過雲端服務進行 SMTP relay 的設定,收信對象就會視收件人網域資訊,轉送至內部或部網域。

觀察企業市場上,不論國內或國外雲端品牌的 SMTP 外寄代管或轉送服務,因應企業進階需求,提供防誤寄外洩 (Email DLP) 或郵件稽核 (Email Audit) 的相關解決方案。透過雲端服務做外寄轉送代管 (SMTP relay hosting) 的效益,可以解決本地機房線路不穩定的問題,同時雲端服務使用標準 IDC 電信機房,具備多線路的備援,遵循標準 RFC 規範或寄件驗證機制 (SPF/Domainkey/DMARC),有效降低連線階段被阻擋的風險。

參考資料:
G Suite 為您的網域或機構設定轉送功能
OSecure 外寄代管轉送服務
Microsoft365 SMTP 轉送設定

上一篇
解決內部協作溝通從即時通整合應用開始
下一篇
佈署混合雲下的電子郵件收發架構
系列文
企業訊息溝通安全30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言