タグ付けされた質問 「queue」

ここにはかなり厄介な問題があります。私はアプリケーションをテストしており、偽の電子メールアドレスへのテスト電子メールをいくつか作成しました（とにかくサーバーが実際に電子メールを送信するように設定されていないことは言うまでもありません）。もちろん、sendmailこれらのメッセージを送信することはできず、sendmailキューに残っています。sendmail通常、再試行を停止するのにかかる5日間を待つのではなく、キューに蓄積されているメッセージを手動で削除します。 私はUbuntu 10.04を使用しており/var/spool/mqueue/、これまでに読んだすべてのハウツーで、キューに入れられた電子メールが保存されるディレクトリです。このディレクトリ内のファイルを削除sendmailすると、cronスクリプトのように見えるものが実行され、送信したくないメッセージがこのディレクトリに再入力されるまで、電子メールの処理を停止します。私からのいくつかの行がありますsyslog： Jun 2 17:35:19 sajo-laptop sm-mta[9367]: o530SlbK009365: to=, ctladdr= (33/33), delay=00:06:27, xdelay=00:06:22, mailer=esmtp, pri=120418, relay=e.mx.mail.yahoo.com. [67.195.168.230], dsn=4.0.0, stat=Deferred: Connection timed out with e.mx.mail.yahoo.com. Jun 2 17:35:48 sajo-laptop sm-mta[9149]: o4VHn3cw003597: to=, ctladdr= (33/33), delay=2+06:46:45, xdelay=00:34:12, mailer=esmtp, pri=3540649, relay=mx2.hotmail.com. [65.54.188.94], dsn=4.0.0, stat=Deferred: Connection timed out with mx2.hotmail.com. Jun 2 17:39:02 …

18 sendmail  queue 

Linuxメールキューの現在のメッセージ数を確認する簡単なコマンドはありますか？mailq詳細なリストをダンプしますが、簡単な概要には不便です。 Ubuntuとpostfixを使用しています。

12 linux  email  queue 

完全な再インストール後、設定に問題が発生しました：送信者アドレスが間違っていて、一部の受信者（メールサーバー）が拒否しました。 そのため、Postfixキューで大量のメールがスタックしています。 理想的には、キューに入れられたメールで送信者アドレスを直接変更してから、キューをフラッシュするのが最適です。 私はこの非常に問題に対処するこの答えを試しました。しかし、私が持っているバージョン（2.11.0）ではメッセージを簡単に変更できないようです。 たとえば、/var/spool/mqueuedir はありませんが、代わりに、/var/spool/postfix/... active bounce corrupt defer deferred dev etc flush hold incoming lib maildrop pid private public saved trace usr 関心のあるディレクトリはですdeferred。いくつかのファイルを修正して、間違ったドメインを正しいドメインに変更しようとしました（変更されたファイルのみが変更されるように注意しました）。 しかし、その後、それらのメールはに移動されましたcorrupt。つまり、単純なテキスト変更は機能しないようです（で行われますvi）。 キューに入れられたメールの送信者を変更する他のよりきれいな方法はありますか？

8 postfix  queue 

ローカルのPostfixサーバーに個別のメールを送信するときに、（多分？）奇妙な遅延が発生しています。 問題の診断に役立つように、5つのメールを送信する小さなテストプログラムを作成しました。 get smtp 1ms ( 1 ms) email 0 677ms (676 ms) email 1 802ms (125 ms) email 2 890ms ( 88 ms) email 3 973ms ( 83 ms) email 4 1088ms (115 ms) 最初のメールのハンドシェイクを割り引くと、1メールあたり約90ミリ秒になります。これらのタイミングは、別のコードパスを使用して他の誰かが作成した別のテストアプリでも確認されているため、サーバーに関連しているようです。 詳細なロギングをオンにしたところ、メッセージの終わりと受信の間に遅延があることがわかり\r\n\r\nます。 [16:31:29.95] [SEND] \r\n.\r\n [16:31:30.05] [RECV] 250 2.0.0 Ok: queued as B128E1E063\r\n [16:31:30.08] [SEND] …

8 postfix  queue