6

現在のアプリケーションでは、Simple Java Mailを使用して 1 日に 2 通の電子メールを送信していますが、クライアントに届かない電子メールもあります。

アプリケーション サーバーのログに基づいて、メール サーバーのタイムアウトが 2 回発生しましたが、メールが見つからないすべてのケースを説明しているわけではありません。再試行機能を追加するとタイムアウトの問題を解決できますが、一般的にメールの信頼性を向上させる他の方法はありますか?

4

5 に答える 5

3

トランザクションの整合性を実装しないのは、SMTP の性質です。

約 6 年前、私は当時働いていた会社からのメールがなぜ失敗したのかについて、非常に詳細な分析を行いました。受信側の MTA までしか確認できませんでしたが、これは MTA の種類と失敗率の間に非常に強い相関関係を示していました (当時、リモート エンドの Novell Groupwise と Sendmail が最も信頼性が高く、MSExchange が最も信頼性が低く、真ん中にqmailなど）。これは非常に経験的なものであり、特定の MTA に固有の問題ではなく、製品の選択と利用可能なスキルを反映している可能性があることに注意してください。また、効果的にコントロールできるものでもありません。

ただし、MTA の上に独自のロジックを開発して実装する機会があるため、次の保証はありません。

1) MTA を離れた後にメッセージが失敗した場合、バウンス通知が返されます。

2) リモートシステムが実際に DSN を送り返す DSN 要求 (RFC 1891 を参照) を含むメッセージを送信する場合

配信可能性を向上させるためにできる最も重要なことは、SMTP についてよく理解し、独自の MTA を維持し、それに応じて構成することです。最近の主な問題の 1 つは、誰もがスパムを阻止しようとしていることです。そして、誰もが独自の方法でそれを行っています。そして通常、彼らは秘伝のソースのレシピを教えてくれません。実際、ベイジアン フィルタリングでは、彼らは知らないかもしれません!

次の寄港地は (SPF が制限的で公開されていること、および RBL を使用していないことを確認した後) は、メールが配信されているかどうかを確認する方法を確認することだと思います。 DSN に頼ることはできません。ほとんどの MUA は (やはりスパムを防ぐために) リモート コンテンツをロードしないため、電子メールを盗聴する (たとえば、HTML として送信するなど) に頼ることはできません。これにより、コンテンツのサーバー側を保持し、元のコンテンツへのクリック可能なリンクを送信するオプションが残ります。ただし、これもまた、受信者が常にメッセージを読みたいと思っていることを前提としています。

C.

于 2010-01-25T13:41:08.890 に答える
2

私の意見では、独自のメールサーバーを実行することはすぐに過去のものになりつつあります。

私のアプリが数通以上のメールを送信する場合、私は通常、サービスとしてのメールプロバイダーを設定し、それを忘れます。それらのほとんどは、アプリケーションでSMTPを使用できるようにします。

ボーナスとして、それらのほとんどはあなたの電子メールで誰が何をするかについての統計をあなたに示します。

その分野で最もよく知られている名前のいくつかは、sendgrid、mailjet、postmarkAppですが、ここで興味深い比較を見つけることができます

于 2012-02-03T15:54:34.563 に答える
2

Set up a production quality mail server available to your application, and let it handle all the very dirty details of reliable mail sending. You are probably hitting some of the limitations like graylisting designed to keep spambots away.

A reasonably simple scenario would be Postfix on a Linux machine. Personally I like Ubuntu

于 2010-01-25T13:22:27.663 に答える
2

Thorbjørn と symcbean はどちらも多くの有益な情報を提供してきましたが、その完全性には圧倒されるかもしれません。私はそれをより親しみやすいものにしようとします：

あなたができる最悪のことは、アプリケーションに SMTP クライアントを組み込み、それに依存して世界のどこかにメールを送信することです。はるかに優れた解決策は、"標準" MTA および/または SMTP サーバーを自分のマシンでローカルに実行するか、最悪の場合は自分のネットワーク内で実行することです。

したがって、アプリは、できれば同じマシンのポート 25 にある独自のメール サーバーまでメールを受信するだけで済みます。SSL エンコーディングも、スパム フィルタリングも、うまくいかないこともありません。また、メール サーバーがアプリと同じマシン上にある場合、(通常) 両方が停止しているか、両方が起動しています。

アプリがそのメールをローカルのメール サーバー (高速でほぼ間違いのないサーバー) にプッシュすると、メールを最終的な宛先に送信するのはそのサーバーの問題になります。Linux サーバーでは、Sendmail、qmail、exim、postfix などをインストールします。Windowsでは、わかりません。

これらの「すぐに使用できる」メール サーバーはどれも、メールを送信する能力が非常に優れています。自動繰り返しが既に組み込まれており、(例) 1 時間、2 時間、4、12、24、48 時間後に再試行します。あなたのメール サーバーは、あなたのメールを配信するために最善を尽くします。失敗した試行はメール サーバーのログに表示され、それを分析して結論を​​導き出すことができます。最後の試行後に失敗した場合は、ログ ファイルにも記録され、受信側で問題が発生したと結論付けることができます。この機能はすべて組み込まれているので、それを独自のメール クライアントに組み込むことを考えるべきではありません。

最後の注意: 転送が物理的に成功する可能性があります。つまり、メッセージは配信されましたが、受信者のメール サーバーまたはクライアントによってスパムとして処理されました。または、（人間の）受信者が誤って削除しただけです。この問題を確実に解決できるソフトウェアはありません。

于 2010-01-25T13:55:58.787 に答える
1

限られた数の受信者に 1 日に 2 通のメールを送信するだけの場合は、Gmail アカウントを介して送信してみてください。

于 2010-01-25T10:49:34.283 に答える