postfix隊列介紹

qshape 

    postfix提供了一個叫qshape的工具，用於診斷postfix的隊列問題，好比隊列忽然變大等。工具命令的示例以下：

$ qshape -s hold | head
                         T  5 10 20 40 80 160 320 640 1280 1280+
                 TOTAL 486  0  0  1  0  0   2   4  20   40   419
             yahoo.com  14  0  0  1  0  0   0   0   1    0    12
  extremepricecuts.net  13  0  0  0  0  0   0   0   2    0    11
        ms35.hinet.net  12  0  0  0  0  0   0   0   0    1    11
      winnersdaily.net  12  0  0  0  0  0   0   0   2    0    10
           hotmail.com  11  0  0  0  0  0   0   0   0    1    10
           worldnet.fr   6  0  0  0  0  0   0   0   0    0     6
        ms41.hinet.net   6  0  0  0  0  0   0   0   0    0     6
                osn.de   5  0  0  0  0  0   1   0   0    0     4

上圖顯示的是hold隊列中排名前10位的發送者所屬域名的分佈狀況，時間單位爲分鐘，-s表示按sender的域名進行分組排序，默認展現的是按收件域名分組的分佈狀況，若是不加隊列參數則默認展現incoming和active隊列的信息。

同時查看多個隊列的消息能夠用下面的方式：

$ qshape incoming active deferred

經過這個工具，能夠分析出從哪些域名發出了大量的郵件，或者哪些域名接收了大量郵件，分別集中在哪一個時間段等等信息。知道了哪一個域名發送或接收到的郵件量比較大，接下來就能夠經過郵件收發日誌來查詢更具體的狀況了。

在正常狀況下，incoming和active隊列都會保持比較空的狀態，也就是郵件一進來就會立刻被髮送走。

針對未驗證域名的字典攻擊會致使延遲隊列(deferred)的堵塞：若是沒有正確驗證有不合法域名的收件人會致使郵件投遞不成功，從而被反彈到延遲隊列，使其產生堆積。不過，若是incoming和active隊列能保持比較空的狀態，延遲隊列稍有增加通常來講不會致使很大的危害。

若是有大量收件人所在的服務器很慢或者乾脆掛了，也很容易致使延遲隊列堵塞，嚴重時還會致使active隊列也堵塞，這時最好儘可能讓郵件進入延遲隊列或者乾脆讓發件人稍後再發送郵件。

anvil(8) 是postfix用來防止ddos攻擊的服務，能夠對進信頻率進行限制，但要當心慎用，限制也不要設置得過小！

另外，外發投遞時不要把smtp併發數量設置得過大，容易致使對方拒絕，這樣延遲隊列又堵塞了，若是能重用smtp鏈接就更佳。

下面介紹postfix裏的各類隊列

maildrop隊列：經過sendmail指令發送的郵件，在還未被pickup進程加入到postfi主隊列中時會放在maildrop隊列，即便postfix沒有啓動，郵件也能夠加入這個隊列，postfix一啓動就會開始處理這個隊列。

全部進入postfix主隊列的郵件都會通過cleanup服務，cleanup負責信封和信頭的重寫、信頭和郵件內容的正則檢查、對郵件暗送地址進行處理、由milter對內容進行處理，而後將郵件送入incoming隊列。

hold隊列：管理員能夠經過smtpd進程的一些策略或者cleanup信頭和內容檢查的一些規則讓郵件自動轉移到hold隊列，郵件將一直呆在這個隊列直到管理員再次調度這些郵件。postsuper指令能夠手工將hold隊列中的郵件轉移到deferred隊列。hold隊列中的郵件能夠存活得比$maximal_queue_lifetime. 配置的時間更長，這時若是想釋放這些郵件可使用postsuper -r將其轉移到maildrop隊列讓其從新發送，這樣就會給郵件標記一個新的時間戳，而那些比較年輕的郵件可使用postsuper -H轉移到deferred隊列。

incoming隊列：進入postfix的郵件將會由cleanup服務寫入到incoming隊列，新的隊列文件的擁用者會被設置爲"postfix"，權限被設置爲0600，當一個隊列文件準備好能夠進行下一步處理時cleanup服務會將文件權限設置爲0700並通知隊列管理器有新郵件到達，而隊列管理器也會忽略掉那些0600的文件。隊列管理器會掃描incoming隊列將新郵件轉移到active隊列直到active隊列滿了（deferred也是如此處理）。通常來講，incoming隊列都會比較空，由於郵件一到達就會被轉移到active，若是incoming的進信速度超過active的接收速度就會堵塞。影響隊列管理速度的因素主要是磁盤io和針對trivial-rewrite service的lookup查詢，因此儘可能不要使用那些慢查詢服務如ldap,mysql等。

in_flow_delay 參數用於控制隊列管理器的進信速度，當cleanup服務不能從隊列管理器中取得token時，它將在建立新的隊列文件前暫停in_flow_delay 秒鐘，這樣能夠控制進信速度。

active隊列：有點像操做系統的進程隊列，該隊列中的郵件都是準備要發送的郵件，就像處於runnable中的進程同樣。 active隊列與其餘隊列不一樣，它其實是處於內存中的一組數據結構的集合，而其餘隊列是磁盤上的一個目錄，並不佔用內存。active隊列中郵件的信封信息是在內存中，方便隊列管理器來作全局的調度，分配投遞代理進程。

active隊列的郵件來自於incoming和deferred隊列，在這個隊列中，有多個收件人的郵件會分紅不一樣的組，這些組共享相同的transport/nexthop組合，分組的大小受到傳輸層併發大小的限制。

因爲active隊列的郵件是要投遞到目標服務器，因此目標服務器緩慢會致使active隊列堵塞。若是目標服務器掛掉一段時間，隊列管理器會將其標記爲dead，並當即將要投往這個服務器的全部郵件轉移到延遲隊列（deferred）。

注意：當隊列管理器重啓時，active隊列目錄中可能還存在一些郵件，可是這時進程內存中倒是空的，因此爲了能active的內存狀態，隊列管理器會將郵件轉移到incoming隊列，利用它的隊列掃描器將郵件從新填充到active隊列，這個過程是比較消耗資源的，因此儘可能少重啓隊列管理器，好比postfix reload之類。

active隊列的大小受到$qmgr_message_active_limit限制，同時也受到收件人數量限制：$qmgr_message_recipient_limit，這兩個配置默認都是20000。當隊列達到上限時active將再也不接受新的郵件。

deferred隊列：那些由於暫時的緣由投遞失敗的郵件將會放在該隊列，由隊列管理器定時掃描這個隊列從新投遞，定時間隔由參數queue_run_delay配置。因爲incoming隊列也有個定時掃描器，因此隊列管理器會輪流轉移這兩個列表的郵件到active隊列。

這個隊列裏的郵件有一個冷卻時間：在郵件進入延遲隊列時會被設置一個將來的時間，這樣只有過了這個時間該郵件纔會從新進進行投遞嘗試。冷卻時間界於$minimal_backoff_time 和 $maximal_backoff_time之間，每次重試都會把重試時間翻倍而後調整到界限之間，因此比較新的郵件會比老郵件重試得更頻繁。