為何郵件規則執行似乎有所疏漏?答案是郵件拆解造成

在郵件系統服務,早期運行方式,會嘗試節省效能。
當建立主機交握後,會在郵件佇列中,將相同主機的往前排隊,以利傳輸
舉例而言:
當郵件主機寄送信件給 gmail / hinet / yahoo 時,發現後面佇列中還有幾封是要給 gmail 等主機
這本來是為了節省時間,建立連線後,盡量將相同的信件,趁此次交握連線,一次搞定
但這也造成了:這些ISP  認為一次性大量塞信,也觸發了瞬間傳輸量限制等

POSTFIX 開始思考新的架構傳輸,也改善傳輸方式

會將信件分批發送,標注同一 senderID 讓收件者仍可以看到信件仍是原來數量的收件者
但是在伺服器端,卻是分開來的傳輸交握
舉例來說:
當使用者寄送一封附件是 1M 檔案信件,但CC給 相同或不同公司,以及內部帳號 計 20 個收件者
於是~postfix 試著建立傳輸連結交握,發現對應給A客戶網路傳輸送度快,將其中收件者資料一次或 分兩次就送信給 A公司伺服器
相對的,送信給B 公司時,發現速度慢,或是其他因素。
所以即使 B公司收件者一樣是 5 位,卻可能拆成 5次傳輸與送信。
拆解方式,由底層 POSTFIX 負責處理與決定

所以也可能造成,同一封信,同一家公司三位收件者,可能收到時間不同

除了傳輸過程影響外,其實還有其他幾個可能
MXmail 不僅僅是電子郵件系統主機,更提供郵件備份,稽核,審閱,過濾條件執行。
還需要檢測紀錄與設定:
可能設定 A/ B / C 三位收件者,設定了郵件規則,只要是 A收件者,或是 B收件者,信件在特定條件下執行
延遲送信/過濾/刪除等動作,這樣可能 A因為觸發條件過濾,所以收不到信,B因為觸發延遲,稍晚收到信件,C卻是正常收到信件

但是:
郵件記錄器卻紀錄著該封信件,要給  A/ B / C 三位收件者,信件實體也有確實資料
要說明的是:郵件主機記錄器,還記著的是這封郵件的交握標頭資訊,自然是有這三個收件者資料
但其實,A/B 收到信件了,C其實未必已經交握送信,而被拆為另一次傳送
而這時,可能會是相同或是不同的交握 send ID
 

需要在 webmail 啟用合併信件功能,避免重複信件

使用者就需要在 webmail 啟用合併信件功能,避免重複信件
如果是 V3.22 版本之前客戶,可能是不會遇到這樣問題因為底層未進行更新 但:不能保證的是這個多往來客戶,
如果對方更新了
那即使是v3.22 以前版本,也是會遇到這樣的問題 所以仍建議客戶,應該避免這類問題,進行立即更新

這個問題主要是對方發信拆解,而非收信把它信件分開

郵件稽核規則的組合,會不能正確之道信件究竟多少當初的交握資訊 
因為系統備份稽核,設計了避免異常無限迴圈抑制
當相同 sender ID 信件,在“2分鐘“內,重複 sender ID 會放棄執行規則的保護措施 
並發信給原寄件者通知,信件產生無限迴圈
這就是抑制:客戶設定規則 A 寄給 B,但是又設定了 B 轉寄給 A 的無限迴圈問題