POP3ポーリングとメールでの再生機能について理解を深めています。
しかし、Discourseが接続した際にPOP3サーバーがログに記録している内容を説明するのに苦労しています。Discourseが接続するたびにPOP3サーバーのログに記録される RETR/access のペアになっている行を説明するのを手伝っていただけますか?これは、pop3 polling period mins の値どおり、予想通り5分ごとに発生します。
添付ファイル (21.2 KB)には、両方の機能が有効になってから最初のポーリングアクションまでの間に記録された行が含まれています。
ご協力ありがとうございます!
RGJ
(Richard - Communiteq)
2024 年 8 月 13 日午前 8:45
2
(これはなぜDovecotの質問ではなくDiscourseの質問なのですか?)
これは単に、Discourseがメールボックス内のメールを1通ずつ取得していることを意味します。
Dovecotフォーラムでヘルプを探すのとここで質問するのと迷いましたが、Discourseがサーバーからメールをポーリングしているため、ここで質問しました。あなたの回答は、「ペアになった行数」とサーバーで利用可能なメッセージ数を一致させるのに役立ちました。なぜペアになった行数が受信トレイのメッセージ数とまったく同じになる場合と、単に36になる場合があるのか、まだ理解できません。
DiscourseのPOP3機能を使用できるように、ログに関する完全な説明を得るために、Dovecotコミュニティで現在調べています。
ご協力いただき、誠にありがとうございました 。
「いいね!」 1
RGJ
(Richard - Communiteq)
2024 年 8 月 13 日午前 9:10
4
36という数字は、メールをページごとに取得しているRoundcubeやその他のメールクライアントではなく、Discourseによって引き起こされていると確信していますか?
新米がスキルアップのために夏を利用しているのと同じくらい確信しています!問題を検討していただきありがとうございます。
RoundCubeはここでIMAPを使用していると思います。新しい添付ファイル (9.8 KB)にはn=36のシリーズが含まれています。これは5分ごとに再現されます。これが主にDiscourse関連だと推測する理由です。premiseのアカウントの受信トレイ内のメッセージ数とnが等しくなるのがいつなのか、まだ理解できません。
ありがとうございます!
私は今、その起源についてより確信が持てました。そして、RFC 1939 を読み、rails cにアクセスしてライブラリnet/popを少なくともいくつかの基本的な操作で操作できるようになりました。
[10] pry(main)> Net::POP3.enable_ssl(OpenSSL::SSL::VERIFY_NONE)
=> {:verify_mode=>0}
[11] pry(main)> pop = Net::POP3.new('x.y.z')
=> #<Net::POP3 x.y.esz open=false>
[12] pry(main)> pop.start('premises', 'xxxxxxxxx')
=> #<Net::POP3 x.y.z: open=true>
[13] pry(main)> pop.n_mails()
=> 103
説明できないのは、一部のポーリングサイクルで36通のメッセージしか読み取れない理由です。最後のアクセスは常にUID=36です。
Aug 19 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Opened mail UID=36 because: access
Aug 19 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Opened mail UID=36 because: RETR
アカウントにメッセージがさらに追加されたにもかかわらず、この数は変更されていません。
この動作の説明を見つけるのを手伝っていただけませんか?私たちのセンターのセキュリティ担当者は、説明できないログを生成する実行中のソフトウェアを好まないのです!ありがとうございます!
RGJ
(Richard - Communiteq)
2024 年 8 月 19 日午後 3:02
7
しかし、これは非常に魅力的なのですが、理解できないものは好きではないので、実際の問題がないため、これは無駄な作業だと思います。
以前にソースコードを簡単に確認しましたが、そこには何も見つかりませんでした。
ログレベルを下げることをお勧めします…
Richard - Communiteq:
ログレベルを下げる
ログ記録は、私が学ぶべきことがたくさんあるもう一つのトピックです!
私たちのメールサーバーの現在の /var/log/maillog ファイルでは、36467行中30644行がDovecot関連です。Discourseは、私たちの組織でDovecotを使用している唯一のサービスです。多くの人が休暇中ですが、レコードの84%はDiscourseのメールアクティビティを示しています。
メールサーバーが記録することについては、全く制御できません。読むことしかできません。したがって、Discourse/Dovecotが送信している情報のみを変更できます。ほとんどの行には Debug が含まれています。そのため、私たちのDiscourseインスタンスのログイン設定が、メールサーバーにデバッグ情報を送信していると推測されます。
この動作をどのように変更できますか?
ログ記録の仕組みについて明確な誤解がある場合は、事前に謝罪いたします!ありがとうございます!
RGJ
(Richard - Communiteq)
2024 年 8 月 20 日午前 9:01
9
いいえ、メールサーバーは「debug」レベルでログを記録するように設定されています。
実際には以下のことが起こっています。
あなたの組織のdovecotインスタンスは、デバッグレベルでログを記録するように設定されています。デバッグレベルは高度なトラブルシューティングを目的としており、dovecotソフトウェアの内部動作に関する深い洞察が必要です。問題がないため、トラブルシューティングの必要はなく、ログレベルはより低い(詳細度の低い)レベルに設定できます。
あなたのセンターのセキュリティ担当者は、ログが理解できないと不平を言っています。これは、これらのログを理解するにはdovecotソフトウェアの内部動作に関する深い洞察が必要ですが、彼らにはそれが欠けているためです。
したがって、解決策は次のとおりです。dovecotソフトウェアを実行している担当者がログレベルを変更する必要があります。
これは、dovecotソフトウェアを使用している 人々(つまりあなた)に不平を言うべきことではありません。これは、彼らまたは彼らの同僚が行ったことです。
やりました!ログがずっとクリーンで情報量が多くなりました。
説明していただきありがとうございます。状況の良い説明と分析があれば、対話がずっと簡単になります。過去数年間、いくつかの困難な状況に直面したため、すべてのセキュリティ上の懸念を理解できます。説明のために苦労するという行為は受け入れますが、あなたや他のボランティアの方々の助けなしでは、私のようなITスキルがほとんどない人々がDiscourseのような素晴らしいツールを使用し、その使用を促進することはできません。
さらに、メール設定に関連する他の疑問に移ります。どうもありがとうございました!
「いいね!」 1