Windows Azure＋.NET Frameworkのメール送信

山岡 (2010年11月25日 15:54)
産業システム部 / .NET

.NET Frameworkで構築したWebアプリケーションをWindows Azureにのせてみました。
今回はその中でもとくに、メール送信処理に焦点をあてていきたいと思います。

Windows Azure上のWebアプリケーションで汎用的に使えるようなメール送信処理を実装するには、いくつかのハードルをクリアする必要があります。
結論からいえば、もし手軽に導入したいと考えるのであれば、2010年11月現時点での最適解はサードパーティのライブラリをソースに組み込むことが無難といえそうです。
※ただし、汎用性を求めなければその限りではありません。

■Windows Azureについて
まずWindows Azureについてですが、現時点では下記のような動作・仕様となっています。

・Azureコンピュートサービスから直接メールを送信しても、メールサーバによってはAzure環境から送信されたメールを拒否する
→ Azureの逆引きDNSがうまくいかなかったり、IPアドレスがブラックリスト登録されている可能性があるためです。

・Azureでは外部コンポーネントをインストールできない
→ よく使われるBASPなどの便利なコンポーネントが使えないことを意味します。

したがって、Windows Azure上のWebアプリケーションからメール送信を行う一つの方法としては、外部SMTPサーバを利用することになります。

■SMTPサーバのポートについて
メール送信処理の実装の前に、前提知識としてSMTPの接続先ポートについて押さえておく必要があります。
25 ... 既定ポート
465 ... SMTP over SSL(Implicitモード)
587 ... STARTTLS(Explicitモード)

多くのメールサーバは、スパムメール対策やセキュリティ強化のため、25以外が使われていると思います。

■.NET Frameworkについて
Windows Azure上ではBASPなどのコンポーネントを使うことができないため、.NET Frameworkの標準クラスを利用してメール送信処理を実装することになります。
メール送信処理の実装方法として大きく４パターンあります。

　(1) Socketプログラミングによる実装
　(2) System.Web.Mail名前空間を利用した実装（旧形式のため非推奨）
　(3) System.Net.Mail名前空間を利用した実装
　(4) サードパーティのライブラリを利用した実装

以下に各々の概要と、必要に応じてAzure上での検証結果について説明していきます。

(1) Socketプログラミングによる実装
Socketプログラミングは、SMTPコマンドを1つずつ送信していかなくてはならないなど実装に手間がかかるものであり、異常系なども考えると、周辺知識が豊富にある人でないと独自実装はオススメできません。

(2) System.Web.Mail名前空間を利用した実装（旧形式のため非推奨）
.NET Framework 2.0以降は旧形式で非推奨となっております。
現在推奨されているのは(3)のSystem.Net.Mail名前空間を利用した方法となりますが、実際のところ(3)の方法はいくつか問題があります（後述）。
汎用性を求めるのであれば、旧形式で非推奨となっているものの.NET Framework 4でも使うことは可能なので、選択肢としては(2)のほうが確実です。

ただ、Windows Azureでの動作に関しては、下記のようにメールサーバとモードにより、失敗するパターンもあるようです。

　GoogleApps ポート465(Implicitモード)　...　成功
　Gmail ポート465(Implicitモード)　...　成功
　Gmail ポート587(Explicitモード)　...　失敗（サーバ接続拒否）
　MS-BPOS ポート587(Explicitモード)　...　失敗（サーバ接続拒否）
※このパターンに関しては十分な精査はできていませんので深くは触れません。
　もしWindows Azure上でも正常に動作するという例がありましたら、お知らせいただけると助かります。

(3) System.Net.Mail名前空間を利用した実装
Microsoftの推奨ではありますが、実際のところはいくつか問題を含んでおり、汎用的な実装を求めるのであれば選択肢からは外れることになります。

１つ目の理由は、465(Implicitモード)のSMTP認証には対応していないことです。
下記のMSDNライブラリでも「サポートされていません」と明記されています。
http://msdn.microsoft.com/ja-jp/library/system.net.mail.smtpclient.enablessl.aspx

さらに突っ込んだ内容としては、下記MSDNフォーラムの記事が参考になります。
http://social.msdn.microsoft.com/Forums/ja-JP/vwdexpressja/thread/2da55a2c-7476-4145-bfe5-7800ae3a8ae6

２つ目の理由は、587(Explicitモード)においてもSMTP認証が通らないことがあります。
http://techbank.jp/Community/blogs/mymio/archive/2009/08/13/11183.aspx

上記の点から、この方法で実装することは避けたほうがいいと思います。

(4) サードパーティのライブラリを利用した実装
サードパーティのライブラリでは、Explicitモード、Implicitモードの両方に対応しています。
手組みよりも信頼はおけると思いますし、とくに理由がないのであれば選択肢に入れても問題ないでしょう。

上記結果により、汎用性を求めるのであれば(4)が一番無難であるといえます。
(2)はもっと踏み込んだ検証が必要ですが、それ次第では選択肢に入るでしょう。
(1)は、Socketプログラミングによる独自実装に自信があり、それらのリスクを踏まえたうえで各種動作に対する責任を負えるのであれば、考えてみてもいいと思います。
(3)は現在の推奨クラスであるものの動作に信頼性がおけないので、(2)が利用出来る限りは避けておいたほうがよさそうです。
今後、Microsoftが正しく実装してくれることを祈りましょう。

といったところで今回は終わりたいと思います。

システムのトラブル解決を承ります。すぐにシステムリフォームを体験できますシステム診断・システムリフォームのお申し込みはこちらから。

Windows Azure＋.NET Frameworkのメール送信

システム開発のアイロベックスは、創業23年を迎える
プロフェッショナル集団です。