POSTFIX的基本配置與管理

POSTFIX安裝的默認目錄：
/etc/postfix/    配置文件與查詢表
/usr/libexec/postfix/    postfix的各個服務器程序
/var/spool/postfix/   隊列文件
/usr/sbin/    postfix的工具程序
此外，還需要創建一個POSTFIX虛擬賬戶與一個postdrop組，而且這組賬戶與組專供postfix系統使用，不做任何其他用途。
第一次啓動postfix
第一次啓動postfix之前，必須先完成兩項準備工作。第一件工作是確定系統本身的標示，也就是你的機器在INTERNET上的完整主機名稱，因爲postfix的myhostname配置參數需要設定成這個名稱。只要postfix知道系統的完整主機名稱，它就可以推算出其他重要參數的默認值，例如mydomain。如果你沒有明確設定myhostname參數，postfix的默認值是使用本機系統回覆的結果。使用unix的hostname命令可查出系統的主機名稱。
完整主機名稱由兩部分構成，在第一個點號之前的部分是主機本身的名稱，其後是“網域名稱”。如果你的系統已設定好完整的主機名稱，就可以不修改myhostname參數。然而，有些系統只設定了簡名，而沒有設定完整名稱。
在這種情況下，postfix無法自己推算出完整的網域名稱，所以你必須先明確設定myhostname參數。postfix提供了一個專門用來設定配置參數的工具程序：postconf，利用此工具，你可以查閱或修改postfix系統的各項參數的設定值。例如，若要設定myhostname參數：postconf -e myhostname=mail.example.com   -e選項是“編輯”之意，即postconf將指定的參數設定成＝之後的值。
啓動postfix之前的第二項準備工作，是確定系統的別名數據庫（aliases database）的格式是否正確。在你的郵件服務器被使用之前，必須事前設定幾個必要的“別名”（如postmaster、info等），好讓別人可找到相關程序的管理員。我們稍候會討論aliases文件的詳細格式，現在，你只要知道它是一個文本文件，可用來產生適合查詢的索引數據庫。你的系統上現有的別名數據庫不見得符合postfix的默認格式，所以必須使用newaliasese命令重建別名數據庫：
# newaliases
這個命令不需要任何自變量，它不會修改你的aliases文本文件，但會依據文本文件的內容重建新的別名數據庫文件。
完成了上述兩項準備工作之後，就可使用下列命令來啓動postfix：
#postfix start
如果postfix在啓動過程中遇到問題，它會回覆錯誤信息－－－可能出現在終端機畫面，也可能被記錄到系統上的郵件日誌（隨實際的unix系統環境而定）。無論如何，只要能夠順利啓動，postfix會立刻“脫離”終端機，將所有信息導入系統郵件日誌（通常是/var/log/maillog），也就是說，在終端機畫面上看不到任何信息。所以每次你啓動或是重新加載postfix時，請務必檢查日誌文件，看看有沒有任何警告或錯誤信息。
絕大部分情況下，postfix都可以順利啓動而不遇到任何問題，所以，你現在應該已經成爲一臺正在運作中的全功能postfix server的名譽管理人。但是，在你真正擔任此一職務之前，還必須爲你的用戶做兩件事。第一件事，讓你的用戶不需要郵件服務器系統的shell賬戶也能收信。第二件事，確定遠程系統確實能通過DNS找到你的postfix server。
配置文件
postfix的配置文件全部都集中在/etc/postfix/目錄下，其中最重要的兩個文件是master.cf與main.cf。爲了安全起見，這兩個文件的擁有者都應該是root，而且只有root擁有write權限，但是其read權限可以開放給任何人。每當你改變這些文件的內容後，都必須重新加載postfix一次，則所作的改變纔會生效。
#postfix reload
但是如果你修改了inet_interfaces參數，則需要重新啓動（restart）postfix，而不可只重新加載（reload）。
整個postfix系統由多個具有不同功能的daemon構成，這些daemon之所以能夠相互配合，是依靠master daemon居中控制管理。master依據master.cf配置文件來決定如果啓動其他postfix daemon。master.cf配置文件裏每一行分別描述一種postfix服務或傳送程序的工作參數，參數行有統一的格式，各字段的意義都有規定，所以各參數必須按照順序排列。一般而言，默認的master.cf足以應付大多數狀況，所以你通常不必修改它。
main.cf配置文件
postfix的主要配置參數都集中在main.cf文件中，幾乎所有的配置參數的改變都是發生在這個文件。默認的main.cf大約包含三百個參數，雖 然大部分的參數都不必修改，但是它們也提供了讓你自主調整的空間，當你需要修改POSTFIX的行爲時，這些預設的參數提供了相當大的靈活性。 POSTFIX的配置參數相當多，爲了方便查找，不同用途的參數被分別放在不同的樣本配置文件。這些樣本文件存放在sample_directory參數 所指定的目錄下（通常與main.cf文件位於相同目錄）。POSTFIX包隨附的main.cf與樣本文件都含有詳細的註釋，這些註釋有助於你瞭解各個 參數的意義、語法以及注意事項。
POSTFIX提供了一個讓你可在命令行中編輯修改main.cf配置文件的工具－－－postconf，事實上，只要你遵守POSTFIX的配置文件的 語法，任何你慣用的文本編輯器程序（例如vi,emacs,jed,pico等）都可以用來直接編輯main.cf或任何配置文件。POSTFIX配置文 件的內容可以包含空白行、註釋行、參數行。空白行的含義非常明白不需贅述。註釋行是開頭字符爲#的文本行。如果有多行註釋，則每一行開頭都要有一個#符 號。對軟件而言，空白行與文字行沒有作用，postfix只會解毒參數行；但對管理人員而言，它們有重要的參考價值。每項參數都至少有一個參數名稱，其後 是一個=符號，然後是一個或多個參數值。簡單來說，參數行的格式如下：
       parameter = value
在＝符號左右兩邊的空格是可有可無的。
最常犯的一種錯誤，是將註釋與參數放在同一行。這類錯誤有時候很難追查，因爲你認爲是註釋的部分，可能被postfix當成參數值。另一種常犯的錯誤，是 在參數值的前後加註引號。不管是單引號還是雙引號，在postfix配置文件裏都沒有任何特殊意義，所以它們也會被當成參數值的一部分，而不是裏想要的結 果。

多行參數值

第一個字符爲空格（tab或space）的文本行，被視爲前一行的延續。當參數值太多而無法放在同一行時，這種格式讓我們將參數值分散在不同行。

配置變量

在參數名稱之前加上一個$符號，表示引用該參數的設定值。這種語法的好處是你只要修改一個地方，其他相關參數即可統一修改，而不會遺漏。被引用的參數並不一定要先定義，即順序顛倒也無所謂。

多參數值

有許多參數可以同時擁有一個以上的值。參數值之間可以用逗號（，）、空格（space與tab）或換行字符隔開。記住，當你將參數值放在不同行時，參數值之前必須要有空格，以表示它們與之前一行是連續的。
有時某些參數的值太多以至不適合直接放在main.cf配置文件裏，則可將參數值寫在另一個文本文件，而把文件名提供給參數。任何以/字符的字符串，都會 被視爲文件名。舉例來說，假設我們的系統要受理來自許多網域的郵件，則可以將這些網域名稱寫在另一個文本文件，然後讓mydestination參數指向 該文件：
       mydestination = /etc/postfix/destinations
原則上，可接受多個參數值而且參數值順序不甚重要的參數，就可以使用外部文件。例如mynetworks,mydestination和relay_domains都可以接受外部文件。如果不正確特定參數是否支持外部文件，請查閱說明文件。
如果參數值多達上千個，或是參數值本身具有“key-value“的形式，這時候使用查詢表（lookup table）會是比較好的選擇，因爲查詢表有較高的查詢效率。
每次修改main.cf之後，都必須重新加載postfix才能使改變生效：
    postfix reload

查詢表

MTA時常需要做各式各樣的轉換與查詢，比方說，改寫郵件地址、判斷客戶端是否來自授權網絡等。對於這類工作，sendmail要使用複雜的改寫規則或樣 式轉換，而postfix採用比較簡單也比較有靈活性的查詢表（lookup table）來實現。有許多重要參數都需要能夠查詢其對應關係，例如，用於改寫郵件地址的canonical_maps參數。舉例來說，有一家公司，他們 內部使用賬戶名稱來做郵件地址，但是他們希望公開給外界的任何地址，都必須是一致的[email protected]格式。因此，若某人的實 際郵件地址是[email protected]，則外界看到的郵件地址應該是[email protected]。很顯然，因main.cf本 身的格式限制，我們無法描述這樣的對應關係。在這種情況下，最好的辦法就是將所有對應關係另外寫在一個文件－－也就是“查詢表”中，而main.cf中的 canonical_maps參數只要指向這個文件即可。
查詢表讓postfix可從一個“索引鍵”（例如[email protected]）查出其“對應值” （[email protected]）。索引值（key）通常來自postfix於運行時得到的信息，如郵件裏的郵件地址、客戶端的IP地址或 主機名稱等；而對應值（value）可能是一段信息（例如郵件地址），也可能是影響郵件處理流程的動作關鍵字（例如REJECT）。有許多postfix 參數都需要查詢表，維護查詢表是管理員的重要職責之一，所以有必要詳加說明查詢表的文件格式。

查詢表的格式

postfix支持多種格式的查詢表，最常見的格式是unix數據庫文件，這是一種含有索引表的二進制文件，特別適合用於快速的“key－value”查 詢。查詢表的原始數據來自簡單的文本文件，文本文件裏的每一行定義一組“key－value”對應關係，key與value之間以空格隔開；
同一個查詢表裏的每一個key，都必須獨一無二，不可重複。“key”通常被稱爲LHS,而“value”被稱爲RHS。查詢表的LHS不區分大小寫。如 同main.cf的格式，查詢表也可以包含空白行與註釋行，而且開頭爲空格的行也被視爲前一行的延伸；引號在查詢表裏也同樣沒有特殊意義。
將所有對應關係都編入文本文件之後，必須使用postmap來創建做實際查詢之用的數據庫文件：
     postmap /etc/postfix/canonlcal
每次修改文本文件之後，都必須運行postmap來重建它的數據庫文件。
postmap不僅可以用來創建數據庫文件，也可以用來查詢。使用“－q”選項指定你要查詢的LHS，它會顯示出對應的RHS：
  postmap -q [email protected] /etc/postfix/canonical

數據庫格式

不同類型的unix數據庫文件，有不同的內部格式。你的系統支持哪些類型的數據庫，要看你的系統上安裝了哪些數據庫的函數庫。通常，postfix至少支持 btree,dbm與hash這三種類型中的一種，不過，你的系統實際支持的類型可能更多。搞清楚你的系統支持哪些類型的數據庫是非常重要的。 postconf的"-m"選項，可幫助你搞清楚你的postfix支持哪些類型的查詢表：
     postconf -m
此命令會顯示出你的postfix支持的所有查詢表類型以及各種形式的信息變量。但無論如何，你應該至少能找到btree,dbm或hash這三種數據庫類型中的一種。
postfix默認的數據庫類型，定義在default_database_type參數
使用postmap時，如果沒特別指定某一數據庫類型，它會將查詢表（文本文件）轉換成default_database_type參數所指定的數據庫類型。然而，當你將查詢表賦值給相關參數時，你必須指出查詢表的數據庫類型。
當你將一個查詢表賦值給某參數時，必須同時註明查詢表的“類型”與“名稱”。指定查詢表的語法如下：
     parameter = type:name
這裏的type是變量的訪問方法，而name是含有“key－value”對應關係的資源的名稱。對於索引式數據庫的查詢表，name等於查詢表的完整路徑名。
你 可以同時指定多個查詢表給同一個參數。POSTFIX會依照你給定的順序來搜索查詢表，並且在找到符合條件的項目時立刻停止。某些參數支持“遞歸式查詢 表”（recursive lookup table),如canonical_maps參數。使用遞歸查詢時，系統一旦找到一個符合條件的對應值，postfix會嘗試將值與所有的索引鍵再比對 一次，直到找出一個相符的索引鍵。
你或許已經注意到了，使用postmap編制索引文件之後，它會創建額外的文件。你可能會發現系統上多了一個. db文件，或是多了一對.dir與.pag文件（隨你所用的數據庫類型而定）。注意，指定查詢表給參數時，只需指出查詢表的類型以及文本查詢表的完整路徑 名稱即可————不需包含擴展名，因爲擴展名是由數據庫系統決定。

對比順序

有許多參數的查詢表，其索引鍵爲郵件地址－－－有可能是完整地址，也可能只有人名部分，或是隻有網域部分。例如canonical_maps參數的查詢 表，其索引鍵只有人名部分有意義；而transport_maps參數的查詢表，其索引鍵只有網域部分有意義。對於不同類型的查詢表，postfix採取 的比對順序也略有不同。如果你想知道特定參數的查詢表的比對順序，請參閱相關查詢表的在線說明。
原則上，對於canonical_maps,relocated_maps與virtual_alias_maps這種只有人名部分有意義的參數而言，其查詢表的比對順序如下：
1、完整的地址，例如 [email protected]
2、只含人名部分的地址，例如kdent
3、以@開頭的網域部分，例如@example.com
另一方面，對於只有“網域部分”纔有意義的參數，例如transport_maps,postfix採用以下對比次序
1、完整的地址，例如[email protected]
2、只有網域本身的地址，例如example.com
3、以“."字符開頭的網域地址，例如.example.com這表示任何子網域都符合條件。
如果你希望網域名稱涵蓋其下的所有子網域（比方說，“example.com“代表example.com與其所有子網域），你可以利用parent_domain_matches_subdomains參數來簡化查詢表的內容。此參數的默認值包含許多查詢表。

查詢表與簡易列表

某些參數通常只需要一份簡易列表，但是也容許你指定一個查詢表，例如mydestination。使用簡易列表時，只需要列出索引鍵即可：如果使用查詢 表，則必須爲每一個索引鍵都配對一個（無意義的）對應值。通常，只有在你想寫給自己看的註釋時，或者列表裏有上千個項目的時候，你纔要這樣做。將長串列表 獨立到一個簡單的文字文件，不僅可以簡化配置文件，在效率上也比較理想。舉例來說，如果你的POSTFIX要服務的網絡客戶（定義在mynetworks 參數）不是集中在某個子網絡（不能用簡單的network/mask語法來表示），而必須分別列出個別網絡客戶的ip地址時，查詢表可能會是比較理想的選 擇。

模式表

除了支持與key-value配對關係的查詢表之外，POSTFIX還支持一種更有靈活性的特殊表，讓你可以用正則表達式來描述一組共同特徵。正則表達式 又稱爲“模式”，許多unix工具應用它們來比對“具有描述的共同特徵”的字符串。postfix支持兩種風格的正則表達式，隨你的系統所安裝的函數庫而 定。
默認情況下，postfix使用“posix擴展正則表達式”，我們簡稱爲“regexp”。posix的全名是portable operating system interface,這是爲了促進操作系統兼容的標準，regexp是其中關於正則表達式語法的標準規範。postfix也支持perl兼容正則表達式。 如果你習慣使用perl風格的正則表達式，你也會發現它與regexp的語法有點小差異如果你希望POSTFIX支持pcre，在編譯postfix時， 必須鏈接pcer函數庫才行。pcre不僅在語法功能上不同於regexp，在效率上也略勝regexp一籌。如果你不確定自己系統上的postfix是 否支持pcer，請使用postconf的“-m"選項來檢查。
倘若pcre出現在postconf"-m"顯現出支持類型中，則你的模式表可以使用perl風格的正則表達式。但如果你的系統不支持pcrc，那也不必 急着重新編譯POSTFIX，因爲默認的regexp已經足以應付管理員在正則表達式方面的需求，除非裏確實需要perl正則表達式特有的功能。
對POSTFIX與perl兩種風格的正則表達式，都可以找到很詳盡的說明。任何關於PERL的書籍，都應該會提到它的正則表達式，如果裏的系統上已經安 裝了PERL，請參閱perlre在線說明書。關於regexp的說明，通常出現在re_format現在說明書，如果你的系統上沒有這份文件，請去 INTERNET上搜索。
要使用模式表，除了要指定文件名之外，還必須註明其表示法爲regexp或pcre；
    body_checks = regexp:/etc/postfix/re_body_checks
模式表（此例中的re_body_checks）裏的每一行，都分成“模式”與“值”兩部分。模式是放在一對“/"符號之間的regexp或pcre正則表達式，“值”是該正則表達式所對應的字符串。“模式”與“值”之間以若干空格隔開：
     /pattern/       value
模式表在postfix系統上最主要的應用，是用來過濾掉煩人的垃圾郵件：將垃圾郵件的標題與正文的特徵寫入兩個樣式表。

其他格式

POSTFIX也可以將其他後臺系統當成查詢表使用，例如mysql,ldap,nis等。當裏使用這類外界資源時,應當先從最簡單的數據庫入手，例如dbm或hash，等確定該設定方法確實有效之後，再改用外界資源，並比較前後效果是否相同。
postmap提供了一個重要的選項：“-q"，讓你測試任何種類的查詢表。例如，當你使用mysql數據庫時，下面兩個命令應該返回相同的值：
postmap -q hash:/etc/postfix/transport
postmap -q mysql:/etc/postfix/transport.cf

別名文件

別名文件（alias file）是postfix查詢表中的特例，因爲它使用一種兼容於sendmail的格式。傳統上，別名文件的文件名爲aliases，而且其實際存放位置隨系統平臺類型而定，但通常是在/etc/或/etc/mail/這兩個目錄中的一個。postfix默認使用系統原有的aliases文件，以便原本使用sendmial的系統，可以繼續沿用原有的別名文件。

別名文件的位置
基於沿革因素，郵件系統只使用一個別名文件數據庫。但是postfix沒有這樣的限制，你可以使用多個別名文件來組織你的配置信息。一般而言，當你要設定多組郵件列表（mailing list）時，你會想要將它們分別設定在各自的別名文件。aliase_maps參數顯現出你有哪些別名文件。
如果你的系統支持NIS，postfix的默認行爲會搜索NIS所提供的別名信息。因此，默認的alias_maps參數如下：
aliase_maps = hash:/etc/aliases, nis:mail.aliases
倘若你的系統提供NIS服務，但是你不想使用它，你可以修改aliae_maps參數，讓它只包含別名文件：
alias_maps = hash:/etc/aliases
別名文件的位置既然都該了，別名數據庫的位置也要修改：
alias_database = hash:/etc/postfix/aliasese

重建別名數據庫文件
由於別名文件的格式不用於其他POSTFIX查詢表，所以不能使用postmap來重建別名數據庫文件。你應該使用postfix提供的另一個工具：postalias。此工具命令行的語法與postmap相同，你可用它將使用文字符號的別名文件轉換成實際查詢用的別名數據庫：
postalias /etc/aliasese
另一個爲了與sendmail兼容而設計的命令行工具是newaliases，這個工具的作用其實與postalias完全相同，但是其用法被刻意設計成兼容與sendmial包裏的同名工具。所以你可以直接下達newaliases命令而不提供任何選項，也不必指定文本別名文件的位置，它就會自動產生別名數據庫。
當你運行newaliase時，它是依據alias_database參數來決定源別名文件的位置。alias_maps與alias_database這兩個參數的主要差異，在於前者可包含其他類型的別名信息，而後者只能包含“unix數據庫”這一種來源。注意，newaliases是依據default_database_type參數來決定unix數據庫的格式。

別名文件的格式
用於產生別名數據庫的別名文件，其內容格式類似postfix的查詢表，唯一差別在於別名的定義。別名文件同樣也可以有空白行與註釋行，註釋行同樣是以#符號開頭，也同樣不能與別名定義擺在同一行。一個別名的定義可以跨越多行，以空格開頭的行，被視爲前一行的延續。
別名的定義格式，最左側是別名本身，其後一個冒號與若干空格，然後是一個或多個“目標”，目標之間以逗號隔開。別名與目標如果包含空格或任何特殊字符（#:、@），則必須以一對雙引號界定其範圍。簡單來說，別名的定義格式如下：
alias:   target1,  target2,  ....
冒號左側的alias一定是一個本地地址，所以不能包含網域部分。冒號右側的target通常是一個或多個郵件地址，有下列四種可能性：
郵件地址
        任何符合RFC 2822規範的地址都可以。這表示target可以是本地地址或是需要轉遞到另一臺主機的外地地址。
文件名
       本機文件的完整路徑。新郵件會被添加到指定文件的末端，也就是將該文理積案當成本地郵箱使用。
命令
      一個豎線字符（|）與一個外部命令的完整路徑。例如：
info:    "| /usr/local/bin/autoreply"
:include: file
引入一個含有額外目標的文件。原則上，該文件裏的目標可以是前述的任何有效目標，但是在默認情況下，“文件名”與“命令”這兩種目標是禁止的。例如：
info:    :include: /usr/local/mail/info_list
正常來說，當postfix投遞本地郵件時，它會先使用收件人的身份，以獲得將郵件寫入收件人郵箱的權限；但如果收件人地址是一個別名，則postfix會使用別名文件擁有者的身份。不過，如果別名文件擁有者是特權用戶，則postfix使用default_privs參數所指定的非特權身份。

別名目標限制
利用別名文件的“目標”可以做甚多事。你可以用allow_mail_to_commands與allow_mail_to_files來容許哪幾種“目標”出現在別名文件裏。有效的別名機制包括：alias（別名文件）、include與forward。
基於安全考慮，這兩個參數的默認值都是“alias，forward”，也就是說，只有別名文件與.forward文件的目標可以設定爲“文件”與“命令”，而引入文件的目標不可以是“文件”與“命令”。如果你想完全禁止郵件內容被遞送到外部命令與文件，那就將這兩個參數都設定爲空白：
           allow_mail_to_commands =
           allow-mail_to_files =
相反，如果你希望所有別名機制都可以將郵件遞送到外部文件與命令，則可以這樣設定：
                  allow_mail_to_commands = alias, forward, include
                  allow_mail_to_files = alias, forward, include
這樣的設定效果與sendmail的默認行爲相同。這樣做可能使得郵件列表管理系統（mailing-list manager, MLM）成爲窺視目標，因爲***提供的“文件名”或“命令”可能會被MLM當成一般目標地址而被寫入別名文件，進而使得系統安全出現隱患。如果你不需要額外的include選項，那就接受postfix的默認值。

重要的別名

postfix包隨附的別名文件模板，已經預先設定了一組系統別名。習慣上，這些系統報名最後都是指向root賬戶。如果你想要定期閱讀root的郵件，最好的辦法不是直接以root身份登錄系統，而是另外設置一個root別名，將其郵件轉到另一個你平常用來收信的郵箱。
RFC 2142定義了一組所有網域都應該具備的別名，你可以按實際提供的Internet的網絡服務類型來決定要設置哪些別名。但無論如何，最起碼要設置一個postmaster別名，好讓其他網域的郵件管理員知道怎麼聯絡你。請詳細閱讀RFC 2142，決定你需要創建哪些別名

設定MTA的標示

不管你的postfix要做何種用途，你都必須決定MTA的標識，也就是其主機名稱與網域名稱。這方面的參數共計有四個，分別是myhostname,mydomain/myorigin以及mydestination。

myhostname與mydomain

本章一開始就曾經討論過myhostname參數的用途與重要性。如果你沒指定myhostname， postfix使用gethostname（）函數來查詢系統的主機名稱。如果你的系統已經事先設定好正確的主機名稱，則gethostname（）能正確返回完整的主機名稱，倘若改名稱確實就是你想要的，則你不一定要設定myhostname參數的值。但如果gethostname（）函數返回的名稱不完整或是不是你想要的名稱，則你應該明確賦予myhostname參數一個完整主機名稱，或是將mydomain參數設定成系統所屬的網域的完整名稱。當mydomain參數的值爲手動設定時，postfix會依據gethostname（）回覆的本地主機名稱以及管理員指定的mydomain參數值，自動推算出myhostname參數的值。
如果你將myhostname設定成系統的完整主機名稱，但是省略了mydomain，則postfix扣掉myhostname的值的第一個點之前的部分，藉此推算出mydomain的值。即若myhostname被設定成mail.example.com，則postfix會自動推算出mydomain的值爲example.com－－－除非你自己刻意將mydomain設定成其他網域名稱。類似的，如果你的系統不能正確回覆它自己的完整網域名稱，而你也沒有設定mydomain和myhostname參數值，則當你啓動postfix時，它會將問題記錄在你的日誌文件裏。

myorigin

當用戶通過postfix系統發出郵件，但是其信封與標頭裏的郵件地址都沒註明網域名稱時，postfix會自動使用myorigin參數定義的網域名稱來補齊缺少的信息。mydomain的默認值等於myhostname的值。舉例來說，若運行postfix的主機的名稱爲mail.example.com，當用戶通過這臺主機寄出一封“From：kdent”郵件時，postfix在實際寄出郵件之前，會將它改寫成“from：[email protected]“。由於大多數用戶只希望出現網域名稱（例如[email protected]）而不要出現主機名稱，所以myorigin參數通常設定成$mydomain：
           myorigin = $mydomain

mydestination

mydestination參數列出了postfix應該將其視爲“本地網域”的所有網域名稱。在默認情況下，postfix只會收下送給$myhostname與localhost.$mydomain的郵件，也就是說，postfix的默認行爲只接受送給系統能夠主機的郵件。如果你的postfix要代整個網域上的所有主機收信，則應該將$mydomain加入mydestination的參數行：
              mydestination = $myhostname,  localhost, $mydomain, $mydomain
現在，你的郵件服務器刻意成爲整個網域的網關器，代該網域的所有主機收下郵件。

轉發控制

除了爲本地用戶服務之外，postfix也刻意轉發其他系統的郵件。規定哪些對象刻意使用你的系統的轉發服務是非常重要的事。一般而言，局域網上的主機或用戶需要你有能轉寄信到任何地方的能力，但是你會願意將同樣的服務提供給局域網之外的網絡。在郵件管理上，轉發控制是非常重要的功能，因爲這是防止垃圾郵件的首要控制手段。spammer最常用的一種手段，就是找出有固定連接而且能爲他們轉發垃圾郵件的服務器，通過這些無辜的服務器來濫發垃圾郵件，藉此隱藏自己真正的行蹤。你應該禁止非授權對象使用你的郵件系統來轉發郵件。如果你將系統設定成open relay，這不僅只是助長垃圾郵件濫發問題而已，而是終有一天，你會發現自己的系統被列入黑名單，被其他郵件系統當成垃圾郵件的來源地，而成爲他們的拒絕往來者，到最後，你甚至無法寄出自己的正常郵件。

限制轉發訪問

psotfix的默認配置不是open relay，mynetworks_style與mynetworks這兩個參數決定客戶端必須具備怎樣的資格，纔可以通過postfix來寄出郵件。默認配置僅容許相同IP子網絡上的其他主機使用轉發服務。你可以使用mynetworks_style參數來緊縮或放寬服務的地址範圍：如果你只願意讓服務器自己能使用轉發服務，則可將mynetworks_style設定成host；你也可以將mynetworks_style設定成class，讓任何與服務器位於同一級ip網絡的主機都可以使用轉發服務。不過，對於大部分網絡而言，使用class配置等於將服務器開放給許多不相干客戶端。如果你不熟悉ip地址的分級方式，建議你使用默認的subnet，或是更嚴格的host。
或者，你也可以使用mynetworks參數明確指出哪些主機可以享受轉發服務。mynetworks參數的效力高於mynetworks_style，如果你設定了前者，後者自動失效。你可以逐一列出個別的ip地址，或是使用network/mask表示法來指定一段子網絡。mynetworks的方便之處，在於你可以提供轉發服務給一組特定的ip地址羣，而不管它們是否與服務器位於同一個子網絡。例如，假設你是總公司的網管，你想提供轉發服務給分公司辦公室裏的同事，而分公司位於另一個子網絡，有固定的ip地址。在這種情況下，你可將分公司網絡的ip地址納入mynetworks，讓他們可使用你的postfix server來寄信。不過，要是你想服務的對象沒有固定ip地址，則你必須採取某種smtp身份驗證機制。

smtp身份驗證

所有能配合smtp協議進行身份驗證的技術都比較複雜。在你挑選任何一種驗證技術之前，最好再想想看，還有沒有比較簡單的選擇。比方說，有沒有可能讓遠程用戶得到固定的ip地址？遠程用戶是否可改用另一臺smtp server？或許遠程用戶的isp正好就提供smtp代轉服務。
有人可能會想到，爲何不利用控制垃圾郵件的技術，設置一條“寄件人地址是否爲本地網域”的檢查規則，藉此決定是否可代爲轉發郵件？答案是絕不要這樣做！因爲寄件人地址太容易造假了，而垃圾郵件發送者絕對懂得如何僞裝寄件人地址————這簡直是他們的專長。如果你真的使用了這種管制技術，你將會很快發現，你的郵件服務器已經成爲open relay，你不僅會收到“看起來很像自己人寄出的垃圾郵件”，別人也會收到“看起來像是從你家寄出的垃圾郵件”。

因應動態ip地址的解決方案

sasl是規範server與client之間如何交換身份證書的一種通用協議。你的smtp server必須鏈接額外的函數庫才能使用sasl。除了sasl之外，還有三種類似的解決方案，分別是pop－befre－smtp、DRAC以及WHOSON。這些方案都是針對沒有固定ip地址的客戶端而機設的。這些技術要求用戶必須先登錄pop/imap server，借它提供客戶端當前的ip地址給你的系統。smtp server得到客戶端的ip地址之後，便批准客戶端可以使用轉發服務一段時間。這項技術的優點在於用戶幾乎感覺不到有何不同，唯一差別是他們必須先檢查新郵件，然後才能寄出新郵件。
DRAC和pop－before－smtp兩者與postfix的合作方式，都是藉由動態修改postfix查詢表；當用戶成功登錄pop/imap server之後，將客戶端當時的地址填入查詢表，在超過預定期限之後，刪除先前填寫的地址。postfix不需要增加任何額外的函數庫，唯一需要設定的是依據pop/imap server修改的那個查詢表來決定是否提供轉發服務，但pop/imap server 本身則需要修改、重新編譯。DRAC不同於pop－before－smtp之處，在於它可以通過網絡來訪問smtp server，而pop－before－smtp則要求pop/imap server必須與smtp server安裝在同一臺系統上。
WHOSON實際上是一種讓pop/imap與smtp兩種服務器可以交互的接口協議。你可以在網絡上架設一臺whoson server，然後取得一個修補文件讓postfix支持一種新型的查詢表。在修補源程序並重新編譯好postfix之後，它就可以與whoson server通信，藉此判斷特定客戶端ip地址是否有權使用轉發服務。

身份證書

另一種可以考慮的方案，是採用“客戶端身份證書”，我們通常將證書當成保密通信的一種手段，其實證書也是最理想的身份驗證法。然而，證書的審覈與管理需要不少功夫，而且你的postfix必須支持TLS協議才行。

這些額外的支持機制都不是理想方案，因爲你可能要重新編譯、鏈接現有的服務器程序，並開放某些系統文件的寫入權限給這些服務器程序。此外，它們也加重了系統管理員的工作負擔。如果你不能使用先前所說的非驗證式技術，或是你的smtp server必須滿足“每一位”用戶的轉發要求－－不管他們到底是在Internet上的哪個角落，那麼，sasl或許是最可靠、也最靈活的身份驗證方案。

管理

維護郵件服務器是一件長期的工作。你不能只是啓動postfix，之後就不再管理。有一些例行性的管理工作必須靠你完成，而你也應該經常檢查自己的系統是否有任何問題。
postfix的postfix工具提供了一個check命令，可幫助你檢查當前的postfix配置是否有問題、文件與目錄的擁有權是否正確，甚至幫你創建任何遺失的目錄。運行方式如下：
   postfit check
這個檢查程序秉持“沒有消息就是好消息”的Unix優良傳統。如果你的系統一切無誤，它不會出現任何信息；否則，它會將查出來的問題顯示在屏幕上，並同時記錄在日誌文件裏。

日誌記錄

postfix是一個長期運行的程序，你應該定期檢查日誌文件，看看有沒有什麼警告或異常的信息。有可能改變系統的事件，都可能會連帶影響postfix，因此，幾乎所有postfix的活動－－不管成功與否，都會被記錄在日誌文件。每次你啓動或重新加載postfix時，最好檢查一下日誌文件，確定postfix已經完成你要求的活動。
postfix的日誌記錄是通過系統的syslog daemon來代爲完成。不管是哪一種版本的unix，系統日誌都是管理工作上非常重要的一環。
一般而言，syslog daemon從各種系統進程中接收信息，並將信息寫到它們的最終目的地。syslogd對於日誌信息的分類方式，主要是依據信息本身的重要性以及產生信息的應用程序或機制。/etc/syslog.conf配置文件決定syslogd應該將各種類型的信息寫到何處。postfix所使用的記錄機制是“mail”。如果你不知道postfix產生的信息到底是記錄在哪個日誌文件，/etc/syslog.conf能提供正確的線索。某些操作系統是所有信息都記錄在同一個日誌文件中，像/var/log/syslog；而有些操作系統採取比較細膩的分類方式，它們可依據應用程序或服務類型，將信息分別記錄在專屬的日誌文件中，對於這個系統，postfix日誌信息可能會出現在/var/log/maillog文件－－如果改系統的/etc/syslog.conf是像下面這樣設定的話：
         mail.*                  -/var/log/maillog
順利找出郵件日誌文件的位置之後，請務必定期檢查它。你應該依據服務器的郵件量以及先行的日誌輪替模式，決定至少每隔多久要檢查一次，當然，決定權在你，多檢查幾次總是好事，重要的是要持之以恆，養成習慣。
要如何檢查日誌文件？這是一項需要練習的技巧。舉例來說，如果想查出postfix曾經發生哪些值得注意的事，你可以這樣做
     egrep '{reject|warning|error|fatal|panic}:'  /var/log/maillog
這個命令假設日誌文件位於/var/log/maillog，如果不是，請換成實際使用的日誌文件路徑。

postfix的啓動、關閉與重新加載

我們已經介紹過如何使用postfix命令來啓動postfix
         postfix start
在postfix持續運行的過程中，如果你修改了main.cf或master.cf,則postfix必須重新加載配置參數：
        postfix reload
此命令會等待運行中的進程完成工作後才結束它們，然後重新讀取配置參數，繼續運行。當你下達此命令時，如果postfix正好在收信，發信方不會感受到任何異樣或停頓。
在start或reload之後，最重要的事是檢查日誌文件，看看postfix是否回覆任何錯誤或警告信息。
如果要關閉postfix，請使用postfix的stop命令：
    postfix stop
同樣，postfix會等待進程完成未完成的工作，然後才結束它們。對於reload就足夠應付的事，就不應該先stop然後立刻start。此外，儘量避免頻繁的start，stop，reload，因爲這些動作都會嚴重影響服務器的運行效率。

master.cf

postfix的所有服務器程序，都是由master daemon在必要時才予以啓動的。這些服務器程序的運行參數，全部都定義在master.cf配置文件。
master.cf的基本格式與postfix得其他配置文件一樣：#符號代表註釋，空白行與註釋行沒有作用，開頭爲空格的文字行被視爲前一列的延續。
服務名稱（service name）
服務器組件的名稱。實際的命名規則，隨該服務的傳送類型而定。
傳送方式（transport type）
傳送服務所用的通信方法。有效的傳送方式包括inet、unix與fifo。
inet方法表示服務可通過“網絡套件字”（network socket）來訪問，這類服務的對象可以是同系統上的其他進程，或是網絡上其他主機的客戶端進程。網絡套接字服務的名稱，是用服務方的“ip地址”（主機名稱也可以）與“通信端口”（數值或/etc/service定義的端口符號名稱）的組合來表示，例如：192.168.1.2：25、localhost：smtp。如果服務方恰好位於本地主機上，則“ip地址”與冒號都可以省略。
unix代表“unix domain socket”， 而fifo代表“命名管道”（named pipe）。兩者都是同機器不同進程之間的通信機制，而且同樣使用特殊文件爲通信中介。unix與fifo服務的名稱與unix標準文件名的命名規則相同，但是不包含目錄路徑的部分。postfix使用服務名稱來創建通信中介用的特殊文件。 unix domain socket與命名通道兩者都是unix的標準“進程間通信機制”（interprocess communications,通常簡稱爲ipc）。
私有的（private）
某些服務組件僅供postfix系統自己使用，不開放給postfix之外的其他軟件使用。如果本欄標示爲y，表示私有訪問（默認值）；n代表開放公共訪問。inet類型的組件必須標示爲n，否則外界就無法訪問該組件，畢竟網絡套接字本身的用意，就是要開放給其他進程訪問。
非特權的（unpriv）
是否使用非特權賬戶。默認爲y，標示服務組件運行時，只需使用mail_owner參數指定的非特權賬戶（默認值爲postfix），即以完成任務所需的最低限度來提供服務。大部分postfix組件都可以使用非特權賬戶。對於需要root特權的服務組件，此欄必須設定爲n。
改變根目錄（chroot）
是不是改變組件的工作根目錄，藉此提升額外的安全性。工作根目錄的位置由main.cf的queue_directory參數決定。此欄的默認值爲y（標示要改變工作根目錄），大部分的postfix組件也都可以在chroot環境下運作。不過，標準的安裝方式是讓所有組件都在正常環境下運行。講服務組件放在chroot環境下，添加了許多額外的複雜事情，你應該先通盤瞭解chroot所帶來的保障，然後再決定這樣的額外安全性是不是值得你多費一番設定與維護的功夫。
喚醒間隔（wakeup）
某些組件必須每隔一段時間被喚醒一次，定期執行它們的任務。pickup daemon就是這樣的一個例子。其默認休眠間隔是60秒，master daemon每隔一分鐘就喚醒pickup一次，要求它檢查maildrop隊列是否收到新郵件。qmgr和flush daemon也是需要被定期喚醒的服務組件。在時間值之後尾隨一個問號（？），標示只有在需要該組件時才予以喚醒；0表示不必喚醒。此欄的默認值爲0，因爲目前只有三個組件需要被定期喚醒。postfix包預先爲這三個組件設定的喚醒間隔時間，應該足以應付大部分情況，其他服務組件都不需要master的定期喚醒。
進程數上線（maxproc）
可以同時運行的進程個數的上線。如果沒指定，則以main.cf的default_process_limit參數爲準（其默認值爲100）。如果設定爲0，表示沒有任何限制。如果服務器系統的資源有限，或是想讓系統在某方面的表現特別好，你可以調整maxproc的值。
命令（command）
最後一欄是運行服務的實際命令。命令中的“程序文件名”部分不必包含路徑信息，因爲master daemon假設所有程序文件都放在daemon_directory參數所指定的目錄下（默認目錄爲/usr/libexec/postfix/）。postfix的所有程序皆提供“－v”選項，可用來提高日誌信息的詳細程度，當我們需要解決問題時，經常利用這種方法來獲得更多、更有用的調試信息，此外，你可以使用－d選項，讓postfix程序產生調試信息給調試程序。
每一個postfix daemon都有自己的命令行選項。關於各個服務組件的選項。請參閱它們的在線說明書。請注意，只有postfix提供的服務器程序纔可以放在命令欄，如果你想要運行自己的命令，請使用postfix提供的pipe daemon。

時間單位

postfix有一些與時間相關的參數，爲了方便描述其值，postfix提供了一組簡寫代號來表示時間單位：s（秒）、m（分）、h（時）、d（天）、w（周）。如果沒明確註明時間單位，各時間參數以自己的默認時間單位來解讀你給的值。雖然從在線說明書可以查到所有時間參數的默認單位，但是謹慎的管理員不應貿然留下模糊的解釋空間，而應該明確標示給定時間的單位。
某些服務器組件會參考main.cf提供的參數值，但同時也提供了“－o”命令行選項，讓你可以在master.cf中強制設定你要的參數值。舉例來說，若要創建一個特殊的smtp服務，你可將下面內容加入master.cf配置文件：
smtp-quick unix - - n - - smtp
           -o smtp_connect_timeout=5s
參數名稱、等號與設定值可以緊接在一起，不必留空格。在加入本例這樣的設定之後，你的系統就多了一個特殊的smtp－quick服務，當它寄信時，如果對方服務器5秒內沒有響應，就會自動斷線。但是，遵照main.cf設定值的那個smtp服務，則使用不同的smtp_connect_timeout參數值。

收信限制

smtpd daemon可以對外來郵件強加一些限制，包括郵件的大小、同一封郵件的收件人數、郵件內容每一行的長度上線，甚至是同一個客戶端可以容許在發生多少次錯誤後予以斷線。這些限制決定於main.cf配置文件的幾個參數。
smtpd_recipient_limit參數決定一封郵件最多可以有幾位收件人，默認值是1000，就一般的郵件系統而言，這是很寬鬆的限制。
message_size_limit參數限制單封郵件的容量上線。默認值爲10MB。如果想節約磁盤空間或內存，建議你降低此值。但如果你的用戶經常夾帶大的圖像文件，則應該考慮適度擴大此值。
如果同一個客戶端頻繁出錯，那通常是有問題或被***的徵兆。postfix能累計客戶端曾經發生錯誤的次數，對於可疑的客戶端，postfix會主動延遲響應的時間，而且錯誤次數越多，延遲時間就越長。這樣的延遲效果可保護你的系統，以免被錯亂的客戶端搞垮（不管對方是無心還是惡意）。初次的延遲時間由smtpd_error_sleep_time參數決定（默認爲1秒鐘），當客戶端累積了smtpd_soft_error_limit次錯誤之後，往後每發生一次錯誤，postfix就多延遲1秒鐘，當錯誤次數超過smtpd_hard_error_limit時，postfix就放棄該客戶端，並主動斷線。
舉例來說，若網絡遠程有一個惡意程序連接到你的郵件服務器，試圖發出垃圾命令來搞垮你的服務器。則這種垃圾命令會被postfix視爲一種錯誤，並會開始懷疑客戶端是否心懷不軌。假設你設定了下列延遲參數：
smtpd_error_sleep_time = 1s
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 20
則一開始，每次客戶端出錯之後，postfix都只會延遲1秒鐘（smtpd_error_sleep_time），在歷經10次試探之後，postfix開始延長每次延遲的時間。在第11次錯誤時，postfix等待11秒；第12次則等待12秒，依此類推。當總錯誤次數到達20次，postfix便有充分理由認定對方另有所圖，所以會立刻切斷連接。如果對方再次連接，而且試圖製造同樣的麻煩，則他勢必再經歷一回漫長的等待。

改寫地址格式

postfix會嘗試修正郵件標頭裏的郵件地址，使其符合RFC 2822標準的格式。有兩種顯而易見的錯誤格式，postfix會自動予以修正。
第一種情況是隻有人名而沒有網域部分，另一種情況是網域部分只有主機簡明而沒有域名。對於前者，postfix會將myorigin的值附加到人名之後；對於後者，則是將mydomain的值附加到主機簡明之後。

規範地址

除了自動補齊不完整的郵件地址之外，postfix還提供另一種改寫地址的功能，讓你可將毫無共同點的地址，替換成整齊統一的格式。canonical_maps參數指向

關閉地址自動補齊
postfix自動補齊不完整郵件地址的行爲，有時候會造成用戶的混淆。假設你的postfix系統代理example.com網域的電子郵件，有一天，系統從外界收到一封郵件，但是其FROM：字段所含的地址不完整，如下：
from：marketing
to：[email protected]
postfix運行它的例行修正工作，所以上述字段現在變成這樣：
from:[email protected]
to:[email protected]
類似本例這種不完整的地址，其實是發送垃圾郵件者慣用的伎倆之一。天真的用戶看到調整後的地址，往往誤以爲垃圾郵件源自發送服務器。你當然可以設定postfix，要求它不要主動附加網域名稱到不完整的地址，然而，除非你的服務器純粹爲“郵件網關”，沒有任何郵件是從機器本身的MUA產生，纔可以放心的關掉postfix的自動補齊功能。有許多應用程序都要求郵件地址必須符合RFC 2822標準格式，如果郵件中所含的地址格式不合規定，可能會遭到不少麻煩。
要避免postfix擅自將myorigin或mydomain附加到不完整的郵件地址，你可以修改append_at_myorigin和append_dot_mydomain這兩個參數。
大部分情況下，你不會想要這樣做。因爲postfix自己假設郵件地址總是以正確格式出現，而許多處理郵件信息的應用程序也是如此認爲。比較妥當的解決方法，是決絕接收郵件地址不完整的郵件。
定義地址對應關係的查詢表，稱爲規範表（canonical map）。如果你的網絡上有多個不同的郵件系統，分別產生了不同樣式的地址，你可以將所有郵件都導到一個postfix網關，由它將各式各樣的地址轉換成標準格式。規範表通常用於將郵件地址從內部格式轉換成公共格式，像這樣：
/etc/postfix/canonical
  [email protected]        [email protected]
  [email protected]            [email protected]
甚至也可以連同網域部分一起轉換；
在main.cf將canonical_maps參數指向規範表：
canonical_maps = hash:/etc/postfix/canonical
讓你的規範表運行一次postmap，並在修改main.cf之後重新加載postfix；
canonical_maps參數會影響所有地址，包括信封與標頭裏的地址。每當postfix發現郵件地址符合規範表的某索引鍵，便會將它改寫成對應值。如果你只想修改收件人或發信者的地址，postfix提供了額外的參數：sender_canonical_maps與recipient_canonical_maps。這兩個參數的工作方式與canonical_maps相同，但是隻會影響相關地址。如果你同時設定了這三個參數，postfix會依照下列順序來改寫地址；先是sender_canonical_maps，然後是recipient_canonical_maps，最後纔是canonical_maps。

僞裝主機名稱

地址僞裝的用意，在於隱藏內部主機的名稱，讓郵件看起來就像是從網關係統發出去的一樣。假設你的postfix server需要轉發內部網絡主機寄出的郵件，當內部主機送出郵件時，發信者地址含有完整的主機名稱，但是你希望只出現網域名稱。masquerade_domains參數用來將主機名稱轉換成較簡單的網域名稱，你只要將一個網域名稱賦值給它：
 masquerade_domains = example.com
masquerade_domains參數可以接收多個網域名稱，甚至是子網域名稱。postfix會按照你給定的順序來比對郵件中的地址。想像一個含有兩個子網域只出現它們各自的子網域名稱，而來自任何其他網域或網絡主機的郵件，都只出現上層網域名稱，則你可以這樣設定：
  masquerade_domains = acct.example.com hr.example.com example.com
如果你想保留某個原本會被換掉的網域名稱，你可以在該網域名稱之前註明一個感嘆號：
 masquerade_domains = !it.example.com  example.com
這表示來自it.example.com網域的郵件地址不會被改寫。
postfix甚至容許我們排除特定的賬戶。舉例來說，假設我們希望[email protected]與[email protected]這樣的地址保留原樣，則我們可將這些賬戶名稱列入masquerade_exceptions參數
  masquerade_exceptions = admin, root
使用地址僞裝功能時，標頭與信封上的所有地址都會受到影響，唯一例外是信封上的收件人地址。這使得寫給特定主機的郵件，仍可通過郵件網關器送到該主機，而同時又能僞裝成由該主機寄出的郵件。如果你希望所有類型的地址都被僞裝，那就將postfix能認出的所有地址類型全部都列在masquerade_classes參數中，請注意，如果你像上面這樣設定masquerade_classes,則郵件網關係統將不知道如何投遞原本應該送到[email protected]的郵件，因爲該地址已經被改成[email protected]

改變投遞地址

當用戶更改郵件地址，而你不願意服務器繼續幫他們代收郵件時，你可以用一個查詢表定義這些用戶的新舊地址對應關係，並讓relocated_maps參數指向此查詢表。
relocated_maps = hash:/etc/postfix/relocated
查詢表的每一行各記錄一個“舊地址－－新地址”的對應關係。每當收到要送給舊地址的郵件或是舊網域的任何人發的郵件，postfix會拒收，並將對應的新地址發送給寄信方。
那麼，每當有smtp client要求postfix將郵件送到[email protected]或[email protected]時，postfix皆會予以拒收，而smtp client可從響應的錯誤信息中知道新地址。
除了個人地址變遷之外，postfix也能應付整個網域搬遷的情況。如果將下列對應關係加入/etc/postfix/relocated查詢表：
   @example.com            oreilly.com
則每當postfix遇到要寄給example.com的郵件，不管收件人是誰，都一律予以拒收，並告知對方，郵件應該送到oreilly.com纔對。

不明用戶

對應該收下的本地郵件，如果收件人地址的人名部分在任何查詢表、別名表、系統賬戶都查不出來，這個人即被視爲“不明用戶”。正常情況下，postfix會 拒收寫給不明用戶的信；如果你想收這類郵件，你可以將local_recipient_maps參數設成空，避免postfix拒收不明用戶的郵件，然後 使用luser_relay參數將這類郵件集中到特定郵箱：
   local_recipient_maps =
   luser_relay = catchall
這裏假設catchall是系統上的一個有效地址（別名或實際賬戶），可用與接收寄給不明用戶的郵件。請注意，使用luser_relay有潛在的風險。 首先，你會因此而收到大量垃圾郵件。因爲發送垃圾郵件者經常採用“字典***”，也就是將常見的人名與你的網域名稱結合一起，企圖矇混過關。當你設定了 luser_relay之後，原本會被postfix擋掉的郵件，會全部都集中在你指定的郵箱中。另一個問題，如果不明郵件是因爲寄件人打錯字所造成的， 對方會誤以爲郵件已經順利寄出，而沒有發現錯誤的機會。這樣你必須天天檢查這些被攔截下來的郵件（包括大量煩人的垃圾郵件），並承擔潛在的道德風險（私看 別人的郵件不是合法行爲，除非得到授權）。

改變根目錄（chroot）

postfix提供多層次的安全防護措施，其中一個層次是讓你可將大部分的postfix服務侷限在chroot環境下運作。chroot是unix操作 系統特有的一種安全措施，其作用是將進程環境的根目錄，從平常的“/“改成文件系統上的另一個子目錄，將進程的文件系統限制在該子目錄下；也就是說，被 chroot的進程，無法訪問該子目錄之外的文件系統。
對於必須與外界通信的服務器進程而言，chroot特別有用，因爲今日的Internet到處充斥着心懷不軌的人。這樣，即使萬一有人***了smtpd daemon，他頂多只能訪問一小部分的文件系統，能夠造成的損害非常有限，甚至無法從中獲得任何好處。
不過，爲postfix規劃一個chroot環境是一件頗爲複雜得工程，複雜到系統管理員通常不願意面對。一般而言，chroot不是必要得，除非使用postfix得主機位於需要高度安全得環境中，或是位於必須暴露在外的服務器上，例如專用的防火牆與堡壘主機。
所有支持chroot的postfix進程，都可將它們的根目錄改成queue_directory參數指定的子目錄，這通常是/var/spool/postfix/pid目錄，而且不能訪問新根目錄之外的文件系統。
除了pipe、virtual、local和proxymap之外的其他postfix服務器組件基本上都可以被chroot，只要將該組件在master.cf配置文件裏的第五欄改成y即可。
既然chroot改變了服務器進程的文件系統的可視範圍，我們就必須將進程所需的全部資源都放在新的根目錄之下，這樣被chroot的服務器進程才能順利 運行。但是postfix daemons所需的資源因平臺而異，這樣很難逐一列出來說明。大體上，postfix需要能夠訪問賬戶信息（/etc/paswd）、DNS解析配置 （nsswitch.conf或resolv.conf）、時區信息或提供時間信息的函數庫。某些平臺還需要特定的設備文件。postfix包裏隨附了專 爲不同平臺而設計的腳步，在解壓包的examples/chroot-setup/子目錄下可以找到它們。
運行正確的腳步，應該足以爲裏的系統設置好chroot環境。如果沒有適合裏的平臺的腳步，裏可能要做一些小實驗，才能備齊所有必要的資源。考慮先前提到 的那些資源，或是參考其他平臺的腳步，應該對你有所幫助。實驗時請留心觀察日誌文件，看看被你禁錮的進程發出了怎樣的錯誤信息。比方說，如果你看到類似這 樣的記錄：
   postfix/smtp(1575):   fatal:  unknown service: smtp/tcp
這個表示postfix無法判斷smtp服務應該使用哪個通信端口，而問題可能是其無法在chroot環境下訪問/etc/services文件所致，所 以，只要將該文件複製一份放在/var/spool/postfix/etc/services，問題或許就解決了。從錯誤嘗試中學習看出症狀背後所隱藏 的病因，也有助於累積實際管理經驗。
如果平常的postfix日誌提供了線索還不足以找出毛病，不妨提高服務器進程的“詳細程度”（將－V加到服務器進程在master.cf裏的命令行選 項），或者利用程序員常用的各種調試工具（例如truss、strace或tusc等）檢查受測程序到底哪裏停了下來。如果你發現失敗原因是因爲漏掉了某 個組件，那就將該組件複製到chroot環境下。關於如何利用調試工具來追蹤postfix的運行情況，請參閱DEBUG_READMEW文件。
在chroot環境下運行的postfix系統，需要你多花一點心思維護，以保持平常環境的系統文件與chroot環境下的版本一致。舉例來說，如果你的 chroot服務器進程需要/etc/passwd文件，那麼，每當系統的/etc/passwd被改變，你就必須同步更新 /var/spool/posfix/etc/目錄下的副本。創建文件鏈接的辦法是行不通的，因爲符號鏈接（symlink）無法進入chroot系統 （如果可以，那也不必chroot了），而硬鏈接無法進入文件系統。

在線說明書

原版postfix包隨附了許多說明文件。如果你使用別人預先編譯好的安裝包（.rpm/.deb/.pkg等），這些文件不一定齊全，但是最基本的 manpage和配置文件樣本應該都有。樣本文件放在sample_directory參數指定的目錄下（通常與main.cf位於同一個目錄）， postfix的所有參數都可以在這些樣本文件裏找到詳細說明。
安裝好postfix之後，在線說明書應該會安裝在man能夠自動找到的地方。要檢查說明書的安裝位置是否正確，只要直接下達man命令看看是否有效就可以了，例如
    man postfix
如果你的系統沒有顯示說明書，而是出現類似這樣的錯誤信息：
   man postfix
no manual entry found for postfix
那表示你的說明書不是放錯目錄，就是當初根本沒有安裝它們。各個unix系統放置在線說明書的位置都不太一樣，但是manpath環境變量應該可以給你一些線索。
postfix的各種命令行工具、查詢表、daemon都有對應的在線說明，而且所有文件都有HTML版本。如果你的系統沒有安裝HTML文件，在 postfix的網站可以找到它們。在線說明文件永遠能反映當前postfix版本的實況，如果你發現本書提供的信息不符合實際現況，記住，man就在你 身邊。