後綴：使用 milter 時有條件地忽略某些“虛擬郵箱表中的使用者未知”錯誤
注意：我最初在 Unix/Linux StackExchange 上發布了這個問題，但一周後，沒有任何回复。我在這裡看到了更多與後綴相關的討論，所以我投票關閉了我的問題的 StackExchange 版本，我把我的問題移到了這裡。
我正在執行
postfix version 2.93，Debian 8我正在嘗試完成一些不尋常的事情。多年來，我一直在使用自製的磨粉機，效果很好。它在 SMTP 對話框的每個階段執行各種測試：
ehlo、mail from、rcpt to等。我已配置
postfix為對“虛擬郵箱表中的使用者未知”進行標準檢查，這也可以正常工作。然而 …
在某些極少數情況下，我想在
rcpt to階段攔截傳入的消息，然後postfix確定“虛擬郵箱表中的使用者未知”，如果這些消息來自一小群特定的選定發件人，並且發往一小群特定的未知收件人姓名，我想通過該 milter 步驟以不同於正常的方式處理它們。在 milter 步驟中有足夠的可用資訊
rcpt to來執行此特殊處理，但不幸的是，“虛擬郵箱表中的未知使用者”postfix處理在呼叫 milter 步驟之前已經拒絕了發送給未知使用者的消息rcpt to，因此該 milter 步驟永遠不會得到執行。
postfix如果發件人姓名與某些特殊模式不匹配，是否可以配置為僅拒絕“虛擬郵箱表中的使用者未知”的郵件？如果是這樣，
postfix它可以繼續自動拒絕發送給大多數未知使用者的消息，然後它可以只將那些罕見的、特殊的消息傳遞給 milter，以便在該rcpt to步驟期間對其進行處理。我知道我可以完全禁用
postfix未知收件人測試，然後在我rcpt to對所有傳入消息的 milter 步驟中自行管理它。但是，如果可能的話，我想避免這種情況，並以某種方式告訴postfix有條件地拒絕大多數消息給未知使用者，並且只將來自特殊發件人的傳入消息的一小部分傳遞給 milter 處理。即使在
postfix.非常感謝您的任何想法和建議。
check_sender_access列表中查找的右側smtpd_*_restrictions反過來可以包含命名的條件限制（記錄在RESTRICTION_CLASS_README 文件中）。這意味著，如果拒絕未知收件人的郵件的標準完全取決於 rfc5321.MailFrom（“信封發件人”），那麼將reject_unverified_recipient語句從smtpd_*_restrictions列表本身移動到與發件人相關的查找中應該可以解決問題：# OLD (example, you get the idea) smtpd_recipients_restrictions = reject_unauth_destination, reject_unknown_recipient_domain, reject_unverified_recipient # NEW (just a single replacement, adapt to your OLD version) smtpd_recipients_restrictions = reject_unauth_destination, reject_unknown_recipient_domain, check_sender_access pcre:/etc/postfix/maps/no-recipient-lookups.pcre # /etc/postfix/maps/no-recipient-lookups.pcre /.*@example.org/ DUNNO /./ reject_unverified_recipient對於每個列出的發件人（或任何其他單一
check_*_access條件），這會跳過*“此收件人是否存在？”* 檢查，對於所有其他發件人，它將強制執行該檢查。現在，整個練習只有在您以後無條件拒絕任何接受這種特殊處理的消息時才有意義，因為 postfix 對消息的作用是什麼，它應該早些時候已經檢查過它無法傳遞它們。在可能出現 SMTP 階段拒絕的情況下，您絕不應該發出未送達報告。如果您的 milter 只需要消息標頭（正如您調查濫用的案例所暗示的那樣），您可以通過在
smtpd_end_of_data_restrictions列表中添加無條件限制來保證這一點（如果第二次查找與地址驗證競爭，則會對性能產生輕微影響過程）。‡ 如果不是，您可以決定特殊情況是否適用於 a
check_policy_service，這讓您可以做出更複雜的決定，然後是對發送者的簡單（或正則表達式）查找，例如，您可以解析 rfc5322.From（表示發送者的標頭）那裡。no-recipient-lookups.pcre唯一的區別是，您必須編寫/調整併執行返回結果的策略守護程序，而不是編寫兩行文件reject_unverified_recipient，類似於您的 Milter 目前返回 SMTP 狀態程式碼的方式。