我的 postfix 不會將 AUTH PLAIN 傳送到傳出中繼伺服器。幾天前它肯定有效，但現在我收到“不允許中繼”的退回郵件。
郵件系統使用 postfix、fetchmail 和 dovecot 在 Alpine Linux VM 中運作。 Postfix 使用 Cyrus SASL 函式庫，而不是 dovecot 函式庫。
main.cf的相關部分：
relayhost = [RELAY_HOST]
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/mailsrv/etc/postfix/sasl_passwd
smtp_sasl_security_options =
sasl_passwd：
[RELAY_HOST] USER:PASSWORD
我使用 tcpdump 捕獲了傳出會話，但未發送任何 AUTH PLAIN。我測試了使用正確的 AUTH PLAIN 線路透過 telnet 手動發送郵件，並且它有效。
所以我的解釋是，postfix 在某些時候不會決定使用 SASL / AUTH PLAIN。
可能是什麼問題呢？
權限應該沒問題，postmap 已被調用，postfix 重新啟動並重新加載，libsasl 已安裝，並且 postfix 報告已使用 cyrus 建置。我知道這是陳詞濫調，但該系統幾天前曾經運行過。某些證書過期是否會成為這裡的問題，而我在日誌中沒有看到？
答案1
postfix 傳送 HELO 不會產生 AUTH PLAIN 行
HELO 是原始握手指令，沒有任何協商擴充的能力。在客戶端可以使用 SASL 之前，它必須傳送 EHLO（擴展的 hello）並檢查伺服器是否做廣告所需的 SASL 機制。
預設情況下，許多 SMTP 用戶端（包括 Postfix）僅在單字「」時才發送 EHLO電子郵件傳輸協定” 出現在伺服器的問候橫幅中（例如220 foo.example.com ESMTP Sendmail）。不支援 ESMTP 的伺服器被假定也不支援 SASL。
如果伺服器的問候語正確，請確保您沒有意外啟用
smtp_never_send_ehlo或選項。smtp_pix_workarounds如果伺服器的問候語是錯誤的，但它仍然接受 EHLO，您可以透過
smtp_always_send_ehlo = yes在 Postfix 配置中啟用來強制使用 EHLO。
如果您正在管理伺服器，請嘗試修復其問候語，因為這可能還會影響來自其他網域的傳入郵件傳遞 - 例如，如果沒有 ESMTP，則也沒有機會主義的 STARTTLS。
例如，如果伺服器也執行 Postfix，則它必須在smtpd_banner選項中包含「ESMTP」：
smtpd_banner = $myhostname ESMTP $mail_name
（也可能是連線經過反垃圾郵件網關，該網關使用此方法試圖禁止 STARTTLS 使用 - 它不是簡單地將其從 EHLO 回應中刪除，而是嘗試禁止 EHLO 本身。）
請注意，通常連接埠 25 僅用於訊息接收（來自其他網域的入站傳遞） - 587 或 465 是用於訊息「提交」（從用戶端出站）的連接埠。
因此，如果您的 Postfix 充當本機用戶端（因為它有中繼主機並想要使用身份驗證），那麼它確實應該連接到連接埠 587 上的中繼主機。
請注意，連接到連接埠 465 需要smtp_tls_wrappermode = yes，因為它從一開始就使用 TLS。 （這實際上是一個優點，因為它可以防止防火牆篡改握手。）
使用連接埠 587 時，TLS 是可選的（只能使用「STARTTLS」命令啟動），但您也可以真的應該如果伺服器支持，則強制使用 TLS。為此，請設定smtp_tls_security_level = verify.