RFC違反のメールアドレス宛に送信する
日本の携帯電話には必ずと言っていいほどメール機能があります。携帯電話のメールアドレスでは、RFCで規定されている次の事項に反したような形式のメールアドレスが取得できた時期がありました。
@の直前に.（ピリオド）は不可@の左側で.（ピリオド）の連続使用は不可
具体的には、docomoでは2009年4月まで、auでは2009年9月まで「test.....@docomo.ne.jp」や「test.....@ezweb.ne.jp」といったメールアドレスが取得可能でした。現在では、docomoもauも該当するようなメールアドレスの新規取得や変更は禁止されていますが、禁止される以前に該当するような形式のメールアドレスを登録していた場合はそのまま利用できるため、現時点でも該当するメールアドレスがまったくのゼロというわけではありません。
このようなメールアドレスが納品先の会社で使われおり、そのメールアドレス宛に納入したシステムからメール送信できなかった場合、我々開発者はどのような対応を取るのがより良いのでしょうか。そして、求められるのでしょうか。
- RFC違反なので、アドレスの登録時に形式エラーである旨を表示して登録できないようにし、送信エラーが発生しないように対応する
- RFC違反なので、自システムのアドレスとしては登録できないが、お客様情報としての登録およびメール送信は可能にする
インターネットの世界では、自分には厳しく（RFC違反はしない）、相手には優しく（RFC違反であったとしても相手側が処理できるのであれば取り扱う）あるべきだと思っています。
それでは、このようなRFCに違反したメールアドレス宛にSystem.Net.MailとSecureMailでメールを送信してみましょう。
System.Net.Mailでの実行結果
System.Net.MailでRFCに違反したメールアドレスを指定した場合、メール送信が行われずに実行時エラーとなります。
正しくないアドレスには送信しないという設計は正しいと思います。また、業務システムで、納品先が自社内で利用するアドレスであれば「RFCに準拠していないといろいろ問題がありますから、メールアドレスの整備をお願いします」で済んでしまうと思います。しかし、納品先にとっての顧客メールアドレスとなると、そのような対応が難しいときもあります。
これでは、System.Net.Mailを使って日本の業務システムに合ったものは作れない可能性があります。
SecureMailでの実行結果
SecureMailでは、RFC違反のメールアドレスでもメール送信自体は行います。もちろん、RFC違反のメールアドレスは普通のドメインには存在しないので、Sendメソッドの実行時やメール送信後にエラーメールが返信されてくると思います。
しかし、重要なのはRFC違反のメールアドレスでも送信できるという点です。RFC違反のdocomoとauのメールアドレスが実在する限りは、送信しなければならない場合がある訳ですから非常に重要な仕様と言えるでしょう。
コンポーネント活用で長年のノウハウを手に入れる
以上のように、System.Net.Mailでもできそうに思えたSTMPによるメール送信も、実際に使用してみるといろいろと問題があり、SecureMailを使ったときのように思った形でメールが送信されないことが分かりました。
今回は取り上げませんが、メール受信に至ってはSystem.Net.Mailにはメール受信がないため、System.Net.Sockets.TcpClientを使ってTCP/IPレベルでのプログラミングが必要（参考リンク：「.NETでPOPサーバからメールを受信する方法）ですから、POP3にもIMAP4にも対応したSecureMailを使うと、かなり楽ができます。
もちろん、POP3の勉強をするのであればTCP/IPレベルでのプログラミングをするのは非常に有用です。しかし、初めてPOP3を勉強しながら作ったコードと長年のノウハウが詰まったコンポーネントでは、どちらの品質がよいかは考えるまでもありません。業務アプリケーションを作成するのであれば、グレープシティのノウハウを手に入れることができるSecureMailを採用するという選択は非常に有益であり、それこそがコンポーネントを使う意義でもあります。
製品情報
