postfixが使うcyrus-saslがgdbmの1.18以降のバージョンでの動作が怪しいのでSASL認証が出来ないことの回避策
発端
数カ月前にシステムをアップデートすると、
warning: SASL authentication failure: Couldn't fetch entry from /etc/sasl2/sasldb2
warning: foo[bar]: SASL CRAM-MD5 authentication failed: generic failure
と表示されました。
なんかその時調べた時にgdbmのアップデートが原因っぽいのでgdbmのアップデートをmaskして先送り解決してたみたいです。もうフォーラムには報告されてるようだしそのうち解決するだろうと思ったようですね。
saslがgdbmの最新バージョンだとバグるから仕方なくgdbmのバージョン下げてる
— エヌユル (@ncaq) August 17, 2020
再発
年明けにメール送ろうとするとまたエラーが発生しました。
仕方がないのでバージョンを下げようとしましたが、もう下のバージョンはありませんでした。
根本的な解決をしなければいけません。
を見たところ、
db_gdbm: fix gdbm_errno overlay from gdbm_close by TheJJ · Pull Request #554 · cyrusimap/cyrus-sasl
で解決策が計られているように見えますが、このバージョンはリリースされてないですね。と言うかcyrus-saslが2018年からリリースされていません。
正攻法での解決策は難しいようです。
dovecotの認証を使うように変更しました
更に調べるとこのような設計がありました。
Gentoo Forums :: View topic - Postfix not picking up SASL / Postgres authentication
なるほどdovecotの認証を利用するのですね。
package.useに
mail-mta/postfix dovecot-sasl
書いて、(この設定が本当に必要かは疑問)
2.2.7.5. Postfix が SASL を使用するよう設定 Red Hat Enterprise Linux 6 | Red Hat Customer Portal
を見てDovecotの設定ファイルを編集して、
postfixの設定ファイルを編集しました。
そしてサービスを再起動して正常にメールが送られることを確認しました。
暗号化されていないパスワードでログインできないこと、間違ったパスワードでログインできないことも確認しました。
一つ引っかかったのはK-9 Mailが一度送信に失敗したメールの送信をうまいことをやってくれないことですね。これでサーバに問題があるのかと思ってそこそこ引っかかってしまいました。
これからのPostfixにはCyrusは必要ないのかもしれません。
hatena-bookmark