サーバーで、メールクライアントから接続できないという予想される問題が発生しました。
サーバーログを確認しましたが、問題を特定できるのは次のようなイベントだけです。
Nov 23 18:32:43 hig3 dovecot:imap-login:Login:user =、method = PLAIN、rip = xxxxxxxx、lip = xxxxxxx、TLS Nov 23 18:32:55 hig3 postfix/smtpd [11653]:xxxxxxxから接続.co.uk [xxxxxxx] 11月23日18:32:55 hig3 postfix/smtpd [11653]:警告:SASL認証失敗:saslauthdサーバーに接続できません:そのようなファイルまたはディレクトリはありませんNov 23 18:32:55 hig3 postfix/smtpd [11653]:警告:xxxxxxx.co.uk [xxxxxxxx]:SASL LOGIN認証が失敗しました:一般的な失敗Nov 23 18:32:56 hig3 postfix/smtpd [11653]:xxxxxxx.co.uk [xxxxxxx]からのAUTH後に接続が失われました11月23日18:32:56 hig3 postfix/smtpd [11653]:xxxxxxx.co.uk [xxxxxxx]から切断
以前は私のオフィスで30分前だったため、メールクライアントで正しいユーザー名とパスワードの入力を求められなかったため、問題は異常です。サーバーに変更を加えていないため、このエラーが発生する原因がわかりません。
エラーメッセージを検索すると、さまざまな結果が得られますが、「修正」は不確かです(明らかに、悪化させたり、壊れていないものを修正したりしたくない)。
私が走るとき
testsaslauthd -u xxxxx -p xxxxxx
また、次の結果が得られます。
connect():そのようなファイルまたはディレクトリはありません
でも走ると
testsaslauthd -u xxxxx -p xxxxxx -f/var/spool/postfix/var/run/saslauthd/mux -s smtp
私は得ます:
0:OK「成功」
私は別のフォーラムでそれらのコマンドを見つけましたが、それらの意味が完全にはわかりませんが、問題がどこにあるのかを示してくれることを期待しています。
私が走るとき
ps -ef | grep saslauthd
これは出力です:
ルート1245 1 0 Nov24? 00:00:00/usr/sbin/saslauthd -a pam -c -m/var/spool/postfix/var/run/saslauthd -r -n 5 root 1250 1245 0 Nov24? 00:00:00/usr/sbin/saslauthd -a pam -c -m/var/spool/postfix/var/run/saslauthd -r -n 5 root 1252 1245 0 Nov24? 00:00:00/usr/sbin/saslauthd -a pam -c -m/var/spool/postfix/var/run/saslauthd -r -n 5 root 1254 1245 0 Nov24? 00:00:00/usr/sbin/saslauthd -a pam -c -m/var/spool/postfix/var/run/saslauthd -r -n 5 root 1255 1245 0 Nov24? 00:00:00/usr/sbin/saslauthd -a pam -c -m/var/spool/postfix/var/run/saslauthd -r -n 5 root 5902 5885 0 08:51 pts/0 00:00:00 grep --color = auto saslauthd
違いがある場合は、Ubuntu 10.04.1、Postfix 2.7.0、およびWebmin/Virtualminを実行しています。
Postfixはchroot(デフォルトでは/var/spool/postfix
で)で実行できますか、実行できません。ある場合は、ssl認証用に/var/spool/postfix/var/run/saslauthd/mux
を開こうとします。そうでない場合は、/var/run/saslauthd/mux
を開こうとします
何らかの理由で、あなたのpostfixインスタンスはchrootで実行されていたようですが、もうそうではありません。奇妙ですが、それはあなたの質問の詳細から私が推測していることです。それが起こっている場合は、sslauthd構成を変更して/var/run/saslauthd
を使用するか、chrootで再度postfixを実行します。
Postfixがchrootを実行しているかどうかを確認するには、/etc/postfix/master.cf
を確認します。
smtp inet n - y - - smtpd
またはsmtp inet n - - - - smtpd
という行がある場合、Postfixはchrootで実行されています;smtp inet n - n - - smtpd
という行がある場合、Postfixはchrootで実行されていませんです。このチェックは/etc/default/saslauthd
(Ubuntu sasl構成ファイル)から行われます。
postfix
は、chrootを使用するように[〜#〜] [〜#〜]に設定されていない場合でも、常にchrootされた場所でsaslauthd
を探します。そのサービスのための環境。
このブログ投稿は、2005年からのものですが、最も参考になりました。
http://www.jimmy.co.at/weblog/?p=52
postfixはchrootを実行するため、saslauthdと通信できません。これはトリッキーな部分です:
rm -r /var/run/saslauthd/ mkdir -p /var/spool/postfix/var/run/saslauthd ln -s /var/spool/postfix/var/run/saslauthd /var/run chgrp sasl /var/spool/postfix/var/run/saslauthd adduser postfix sasl
以下を使用して、saslauthd
をデバッグモードで実行できます。
saslauthd -c -d -a pam -m /var/run/saslauthd
クライアントから、次のようにします。
openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect mail.mydomain.com:587
プロンプトが表示されたら、次のように入力します。
HELO mynotebook.com
LOGIN PLAIN <base64code>
どこ base64code
ビットはこれに由来します:
Perl -MMIME::Base64 -e 'print encode_base64("\000username\000password");'
Saslauthdで同様の問題に遭遇するたびに(そして他のすべてのものがダブルチェックされたとき)、それはディレクトリ/ファイルのアクセス権に関するものでした。この/var/spool/postfix/var/run/saslauthd
パスのすべてのステップをチェックして、saslauthdが実際にそこに到達できることを確認します。
接続しようとしたときにそのようなファイルやディレクトリが存在しない場合、SASLAuthdを検索しているUNIXソケットが存在しないことを示しています。
ps -ef | grep saslauthd
を実行すると、まだ実行されているのがわかりますか?
その場合は、独自のログの場所があるかどうかを確認してください。
そうでない場合は、再起動する必要があります。