IIS SMTPサーバーは本番サーバーには十分ですか？
IIS7に付属のSMTPサーバー（Webサイト用）を使用することを計画していましたが、 このリンク に遭遇し、心配し始めました（受け入れられたソリューションを読んでください）。限られた予算で、MS Exchangeや他の高価なサーバーを購入する余裕がありません。さらに、IIS SMTPサーバー（私は行っていました）で非常にうまく機能するASP.NETをアプリに使用していますピックアップフォルダ配信オプションを使用するには、これは特にWebアプリに適しているため、ユーザーはメッセージが送信されるまで待つ必要がありません）。
Hmailserverについて聞いたのですが、ピックアップフォルダオプションがないようです（完全にはわかりませんが、間違っている場合は訂正してください）。また、パフォーマンスがIIS SMTPサーバーよりも優れているかどうかもわかりません。これで十分であれば、おそらくIIS SMTPサーバーからhmailserverを使用して、引き続きピックアップフォルダオプションを使用できるようにします。申し訳ありませんが、ここで自分自身と話しているように聞こえますが、最適なオプションを見つけようとしていますが、現時点では明確ではありません。
どんな提案も本当にありがたいです...
IIS SMTPは、高負荷にも十分対応できます。
私は間違いなくhMailServerオプションを使用します。過去にIIS SMTPを使用しましたが、問題が発生した場合、トラブルシューティングを行うのは非常に困難です。 hMailServerは、さまざまなSMTP設定に対してはるかに優れたロギングとより細かい制御を備えています。
ピックアップフォルダを使用せずに応答が何であるかを確認する必要があります...アプリに直接hMailServerを使用しており、問題なく動作しているようです。あなたが言ったように、あなたはスマートホストリレーも行うことができます、しかし私の経験ではトラブルシューティングするためのより少ないステップを持っている方が良いです。
ええと-私たちは本番環境でそれを使用しました-しかし私は解決策に注意しなければなりません：
1）キューイングがダウンしないようにローカルで使用し、スマートホストに配信しました（Postfixを使用しました）。ローカルキューは、メッセージを受け入れて送信するためだけにありました。複数のドメインに配信するIIS SMTP）のパフォーマンスは、ボリュームが大きいとひどいものでした。
2）DROPフォルダーに直接ドロップすると、アプリはそのソリューションに関連付けられます。 CDO（DROPだけでなくSMTPを使用するように構成する必要があります）を使用して配信する場合は、電子メールアドレスの高ビット文字に問題があります。これにより、マシンローカルキューを使用しないという欠点にもかかわらず、最終的にはPostfixボックスに直接配信することになりました。
3）受信メッセージはサードパーティのスパムフィルターを通過しました。 DataEnterのXWallは、価格とパフォーマンスに最適であることがわかりました。正確には直感的ではありませんが、優れたパフォーマンスと構成のための多くのオプションがあります。これを使用する場合は、CeratecからESETアドオンを入手して、コア製品に欠けているいくつかの追加機能を提供することをお勧めします。
ところで：XWallを使用してアウトバウンドを配信できます。これはいくつかのアプリで行いましたが、かなりうまく機能しました。 Postfixは大きな負荷を無料で処理しますが、別のアプリとOS（Linux）を管理することを意味します...
音量が小さい場合から中程度の場合でも問題ありません。着信メールに使用される場合、スパムの問題と機能の欠如により、最終的には別のタイプのサーバーに移動します。
これは、IIS SMTPのコアがかなり堅固であるという事実にもかかわらず、実際にはExchangeがSMTPレイヤーを処理するために使用しているものです。Microsoftは、 Exchangeの料金を支払う必要があるため、管理ツールまたは機能を利用できるようにします。
大量のメール（1日2000以上）を送信するいくつかの大規模なWebサイトにIIS SMTPオプションを使用しました。すべての場合に問題はありませんでした（ノックオンウッド）。 for IIS SMTPは、トラブルシューティングのヘルプについてこの投稿をチェックしてください。IIS SMTPで発生したほとんどの問題は、DNSのトラブルシューティングを少し行うことですぐに解決されました。
http://msmvps.com/blogs/bernard/archive/2004/09/28/14480.aspx