/var/spool/clientmqueue

FreeBSD/amd64を使用して自宅のメール環境を構築しています。fetchmailで取り込み、procmailで振分け、GNUSでメールを読んでいます。メールを送る時はmewを使うか、場合によってはMicrosoft Windows上のThunderbirdを使用しています。数日前、procmailを呼び出すのに、.forwardで指定するのを止めて、.fetchmailrcに変更したところでした。

 

procmailの呼び出し方法を変えただけなので、これまでと同様にメールが振り分けられるはずです。実際その通りなのですが、FreeBSD/amd64自身のrootが送信したメールが見当たらないことに気づきました。root宛のメールは、aliasesでローカルユーザに渡しています。

 

まず最初に確認するのはログファイルです。/var/log/maillogを除くと、エラーが記録されています。同じようなエラーが何度も出力されているようです。目視した限りでは、次のエラーでした。

1. alias database /etc/mail/aliases.db out of date
2. get_error=error:0A000126:SSL routines::unexpected eof while reading
3. info=Bare carriage return (CR) not allowed

 

1番目のエラーは、Webを検索すると「FreeBSD: サーバーOS更新 12.3 → 12.4」という情報が見つかりました。newaliasesすれば良さそうです。

 

2番目と3番目は手強そうなので、Geminiに助けを求めました。Geminiは、「その問題なら、こうすれば解決しますよ」とか気軽に応答するのですが、なかなか解決に至りません。しかも提示された解決策を試みるとエラーが出るので、それを報告すると、「すいません、間違っていました。本当は、この方法です」と別な方法を示してきます。生成AIの回答らしいと言えば、そのとおりです。その分野のエキスパートに尋ねても、やっぱりこうなるかもしれません。生成AIなら、現実の人間と違って、何度訊き返しても嫌がったり怒り出したりする心配がないのは、メリットのような気がします。

 

Geminiとの対話を2時間ほど費やしたあげく、なんとか解決に至りました。いろいろ試したし、試行した内容を取り消したりもしたので、混乱しましたが、次のような対策を講じました。

1. /etc/mail/ホスト名.submit.mcに「FEATURE(`msp', `[127.0.0.1]', `MSA', `E')」を追加した。
2. /etc/mail/ホスト名.mcに「DAEMON_OPTIONS(`Name=IPv4, Family=inet, Modifiers=b')」と変更した。IPv6の方も同様に変更した。

 

このように変更してsendmailサービスを再起動すると、溜まっていたメールが流れる「はず」だったのですが、溜まったままでした。Geminiも半ばお手上げ状態で、スプールにあるメールを「tr -d '\r'」しながら、senmailに渡し、強制的に配送しました。これが成功したので、スプールにあるファイルは物理的に削除しました。

 

そもそも、何故このような事態に陥ってしまったのか、その原因は不明です。前回と今回の問題解決において、Gemini（というか生成AI）の威力を実感しました。それと同時に、間違い（勘違い？）を含む回答もしてくるので、Geminiの回答を鵜呑みにするわけにはいかないだろうと思います。そういう意味で、Geminiの指示に淡々と従うわけにはいかないでしょう。生成AIがあれば、何も勉強しなくても万々歳とはならないと思います。