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

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

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

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

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

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

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

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

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

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

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