web-dev-qa-db-ja.com

sendmail-メールが送信されていることを確認してください

Sendmailを介してメールを送信しようとしていますが、キューに入れられないようにしています。メールを送ってほしいだけなのですが、これまでのところ大きな問題でした。

sendmail.cfとsubmit.cfの両方に、次の設定があります。

O QueueLA=99

メールログには、問題のメールが送信され、キューに入れられたことが記録されています。真剣に、それはただひどく混乱していませんか？

Feb 10 17:04:34 nnn sendmail[27910]: r1AG4Q0V027910: [email protected], 
[email protected] (33/33), delay=00:00:08, xdelay=00:00:04, 
mailer=relay, pri=30391, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, 
stat=Sent (r1AG4U09027911 Message accepted for delivery)

Feb 10 17:04:36 nnn sm-mta[27913]: r1AG4U09027911: to=<[email protected]>, 
delay=00:00:06, xdelay=00:00:02, mailer=esmtp, pri=120589, 
relay=mail1.someone.com. [207.106.200.39], dsn=2.0.0, stat=Sent 
(Queued! 1360512372 qp 15149 <[email protected]>)
  1. このログが書き込まれた時点で、メールは送信されますか？
  2. この最後のキューを防ぐ方法はありますか？
sendmailqueue
3
Robin Manoli

調査の結果、括弧内のメッセージ（Queued！1360512372 qp 15149 <[email protected]>）が受信サーバーからのメッセージであることがわかりました。

つまり：

  1. はい、メールが送信されます。
  2. いいえ、メッセージは受信サーバーのキューに入れられているためです。

これが私の答えを得る方法のいくつかの説明です： freebsd 8メールログステータス、これらはどういう意味ですか？ 私にとって信頼できると思われる答えからのいくつかの引用：

「送信済みのステータスエントリは、リモートサーバーがメッセージを受け入れたことを意味します。」

「ステータスエントリの括弧内のコメントは、電子メールを送信するときにリモートサーバーから返される応答です。メッセージが拒否、延期、または保留された理由を確認するのに役立ちます。」

2
Robin Manoli

なぜこれを変更したいのですか？これはまさにsendmailが機能することになっている方法です。 Sendmailは、元の送信者にメールを受け入れたことを確認する前に、ハードドライブのキューに保存します。次に、それを受け取り、次の受信者が受信を確認するまで物理コピーを保持します。これは、ハードシステムがクラッシュした場合、またはsendmail自体がクラッシュした場合に、sendmailがメールが失われないようにする方法です。 Sendmailもさまざまな理由でメールを遅延させます。遅延メールを制御できない他のMTA（ネットワークの問題、システムの負荷、グレイリスト）。メールを安全にどこかに保存する必要があります。

電子メールは、IMのようなジャストインタイム配信メカニズムではありません。通常の状況では2秒待ちます。

Stat = Sent：relay = mail1.someone.comで他のメールサーバーを見ると、送信されていることがわかります。 [207.106.200.39]、dsn = 2.0.0、stat = Sent

2
chylarides

SMTPは、電子メールが宛先に到達することを保証しません。これは、トラフィックの運命に関するエンドツーエンドの同期フィードバックがない、ベストエフォート型の配信メカニズムです。メールを配信するサーバーは、最終的な配信のためにメールを受け入れるかどうかを直接通知する必要がありますが、同期的に配信する必要はなく（後で保存して通知する必要はありません）、直接配信する必要もありません。 （パスには複数のホップがあります）。実際には、ほぼすべてのSMTPデーモンがメールをキューに入れます。

スパマーによる乱用のために広くサポートされていない配信および開封確認は、この制限を克服するように設計されました。さらに、後のサーバーは、オプションで、将来、メッセージを渡した最初のサーバーがメッセージを受け入れた後にメッセージを拒否した場合に通知を送信する場合がありますが、必須ではありません。

アプリケーションでは、ネクストホップの受け入れを成功事例として扱う必要があります。これは、SMTPが一貫して提供する最も信頼できるフィードバックです。

2
Falcon Momot