.NET Frameworkにおける日本語メールの問題点
.NET Frameworkは、帳票系が弱いなど機能面で日本の実情や文化にうまくマッチしていない部分はありますが、基本的には日本語もうまく扱え、海外生まれの実行環境だという違和感を感じる場面に出くわすことは少ないと思います。
しかし、メールの送受信に関しては別です。.NET Frameworkの一部であるSystem.Net.Mailも日本語化されており、テスト実施時にも問題が発見されることはあまりないのですが、いざ実運用を開始すると、
「メールを受け取った弊社のお客様から『文字化けしている』という連絡が入っているのだけれど、どういうことでしょうか。説明をお願いします」
といったようなクレームが、納品先から入る事例があるようです。これは、受信側のメールクライアントソフトに問題があることも多いのですが、インターネットにおける国際標準「RFC（Request for Comments）」の日本における実装のデファクトスタンダードに、System.Net.Mailが対応しきれていないのが原因です。
RFCに準拠していないからと片付けてしまうのは簡単ですが、多くのメールクライアントソフトでは、RFCに準拠していないメールでも拒否せずに処理を行います。この点を考えると、納品先のお客様が本当の意味で納得するに至らないケースもあるでしょう。
先ほど、「クレームが納品先から入る事例があるようです」と実体験ではないような書き方をしましたが、私はメール関連のアプリケーションを開発する場合、.NET Frameworkの標準機能ではなく、グレープシティなど、必ず日本のベンダーから発売されている市販のコンポーネントを使っています。そのおかげか、クレームになるようなメール関連のトラブルを体験したことがないのです。
そこで今回は、意図的にトラブルが発生するようなデータを使って、System.Net.Mailとグレープシティのメール送受信コンポーネント「Secure Mail 2.0J」を比較してみたいと思います。
Secure Mail 2.0Jを使う前準備
Visual StudioのプロジェクトでSecure Mailを使うには、インストール後、Secure Mailのコンポーネントの参照設定が必要です。参照設定を行うには、次の2つの方法があります。
- Dart.PowerTCP.SecureMailコントロールをツールボックスに追加（図1）して、Windowsフォームなどにドラッグ＆ドロップする
- Dart.PowerTCP.SecureMail.dllを参照設定する
（2）の方法で参照設定を行った場合は、Visual Studioプロジェクトへのライセンスファイルの追加が自動的に行われません。リスト1の内容を記述した「licenses.licx」というファイルを作成し、［新しい項目の追加］から追加しましょう。
Dart.PowerTCP.SecureMail.Smtp, Dart.PowerTCP.SecureMail
最小限コードによるメール送信
System.Net.MailとSecureMailのどちらも、Sendメソッドにパラメータを指定するだけという最小限のコードでもメールを送信することができます（サンプル「CZ1003Simple」）。まずは、この方法でメールを送信し、その結果を比較したいと思います。
メール送信サンプル画面の作成
メール送信用のサンプル画面として、図2のようなフォーマットのWindowsフォームを作成し、件名や本文に日本語を指定したときの動作を確認してみます。
社内に設置した社内向けSMTPサーバーの場合は、25番ポートを使ってSMTP認証ではなくPOP before SMTPで認証するような従来通りの設定が多いようですが、インターネットプロバイダのSMTPサーバーではSMTP認証を行っているところも多く、またポートも25番ではなく587番を使っている場合があります。そのため、最小限のコードとは言っても、サンプルでは図2に示したように「SMTP認証」と「メール送信」という2つの機能を実装しています。
System.Net.Mailの使用方法
Try
Dim _smtp As New System.Net.Mail.SmtpClient 'IDisposeを実装してない
_smtp.Host = Me.Server_TextBox.Text.Trim
_smtp.Port = Me.Port_TextBox.Text.Trim
_smtp.Credentials = New System.Net.NetworkCredential(Me.UserId_TextBox.Text.Trim, _
Me.Password_TextBox.Text.Trim)
_smtp.Timeout = 100000
_smtp.Send(Me.From_TextBox.Text.Trim, _
Me.To_TextBox.Text.Trim, _
"[SNM]" & Me.Subject_TextBox.Text.Trim, _
Me.MailText_TextBox.Text)
isOK = True
MessageBox.Show("Sytem.Net.Mail送信終了")
Catch ex As Exception
MessageBox.Show(ex.Message, Me.Text, MessageBoxButtons.OK, MessageBoxIcon.Exclamation)
Finally
End Try
System.Net.MailでSMTP認証を行うには、CredentialsプロパティにユーザーIDとパスワードを渡します。しかし、SMTP認証の種類は指定できず、「LOGIN」「PLAIN」「MD5」のいずれにするかはサーバーとの間のネゴシエーションによって自動的に決定されます。また、SMTP認証を行うときには.Timeoutプロパティの値を100,000程度に設定しないと、うまくSMTPサーバーと繋がらないことがあるようです。
ここまで準備ができていれば、後はSendメソッドに「送信元」「送信先」「件名」「本文」を渡すだけでメールが送信できます。サンプルコードの例では、SMTP認証を行っていますが、「POP before SMTP」が使われている場合は、Credentialsプロパティを設定しているコードの代わりにSystem.Net.Socketsを使ってPOP3サーバーに接続するコードを記述します。
Dart.PowerTCP.SecureMailの使用方法
Try
Using _smtp As New Dart.PowerTCP.SecureMail.Smtp
_smtp.Server = Me.Server_TextBox.Text.Trim
_smtp.ServerPort = Me.Port_TextBox.Text.Trim
Select Case True
Case Me.AuthLogin_RadioButton.Checked
smtp.LoginMethod = Dart.PowerTCP.SecureMail.SmtpLoginMethod.AuthLogin
Case Me.AuthPlain_RadioButton.Checked
smtp.LoginMethod = Dart.PowerTCP.SecureMail.SmtpLoginMethod.AuthPlain
Case Me.AuthMd5_RadioButton.Checked
smtp.LoginMethod = Dart.PowerTCP.SecureMail.SmtpLoginMethod.AuthCramMd5
End Select
_smtp.Username = Me.UserId_TextBox.Text.Trim
_smtp.Password = Me.Password_TextBox.Text.Trim
_smtp.Send(Me.To_TextBox.Text.Trim, _
Me.From_TextBox.Text.Trim, _
"[GSM]" & Me.Subject_TextBox.Text.Trim, _
Me.MailText_TextBox.Text)
_smtp.Close()
End Using
isOK = True
MessageBox.Show("SecureMail送信終了")
Catch ex As Exception
MessageBox.Show(ex.Message, Me.Text, MessageBoxButtons.OK, MessageBoxIcon.Exclamation)
End Try
System.Net.Mail.SmtpClientと異なり、SecureMailではSmtpLoginMethodを指定してSMTP認証が行えます。System.Net.Mail.SmtpClientのようなオートネゴシエーションも便利ですが、予期せぬトラブルなどが発生したときに迅速に原因を特定するには、SecureMailのように明示的に指定ができる方が便利です。また、SMTP認証を行っても、タイムアウト値（30,000ミリ秒）を変更せずに問題なくSendメソッドを実行できます。
サンプルコードの例ではSMTP認証を行っていますが、「POP before SMTP」が使われている場合、POP3サーバーに接続するコードを記述します。System.Net.Mailと異なり、SecureMailにはPop3に対応したDart.PowerTCP.SecureMail.Pop3があるので、簡単にPOP3サーバーに接続するコードを記述できます。
Private Function ConnectPop3() As Boolean
Using _pop3 As New Dart.PowerTCP.SecureMail.Pop
_pop3.Login(Me.Server_TextBox.Text.Trim, _
Me.UserId_TextBox.Text.Trim, _
Me.Password_TextBox.Text.Trim)
_pop3.Logout()
End Using
System.Threading.Thread.Sleep(300)
Return True
End Function
実行結果
サンプル「CZ1003Simple」を実行して同一宛先に送信し、どのような内容のメールになっているかを確認してみましょう。
サンプルを実行するときに注意したいのは、どこに日本語を指定しておくかという点です。それというのも、メールクライアントソフトにとって日本語はテキストではないからです。そのため、MIME（Multipurpose Internet Mail Extensions）形式にしてISO-2022-JPで7bitエンコードにするのがデファクトスタンダードになっています。
（1）System.Net.Mail.SmtpClient
System.Net.Mail.SmtpClientから送信したメールをメールクライアントソフト「Becky! Internet Mail Version 2.53 ［ja］」（以下、Becky!）で受信すると、文字化けせずに正しく受信できます。しかし、本来は文字化けしても仕方がないようなメールであっても、メールクライアントソフトが正しく表示できるように内部処理している可能性があるので、受信したメールそのものをBecky!の［表示］-［ソースの表示］で確認してみます。
MIME-Version: 1.0 From: hatsune@wankuma.com To: hatsune@wankuma.com Date: 14 Mar 2010 20:59:38 +0900 Subject: =?utf-8?B?W1NOTV3ml6XmnKzoqp7jga7ku7blkI3jgYzjganjgYblh6bnkIbjgZXjgozjgovjgYvjga50ZXN055So5Lu25ZCN?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 5pel5pys6Kqe5pys5paH
MIME-Versionヘッダがあるので、MIME形式のメールとして送信しているのが分かります。前述のとおり、MIME形式の日本語のメールはISO-2022-JPで7bitエンコードにするのがデファクトスタンダードですが、Content-TypeヘッダやContent-Transfer-Encodingヘッダを見るとUTF-8のBase64として送信しています。これでは、デファクトスタンダードの形式しかサポートしていないメールクライアントソフトの場合、文字化けが発生してしまいます。
（2）SecureMail
SecureMailから送信したメールもBecky!で受信すると文字化けもせずに正しく受信できます。こちらもメールそのものをBecky!の［表示］-［ソースの表示］で確認してみましょう。
To: hatsune@wankuma.com From: hatsune@wankuma.com Subject: [GSM]日本語の件名がどう処理されるかのtest用件名 Date: Sun, 14 Mar 2010 20:44:09 +0900 (JST) 日本語本文
大きく異なるのは、MIME-Versionヘッダがないので非MIME形式だという点です。そして、Subjectや本文についてはシフトJISコードで送信されています。また、Content-TypeヘッダやContent-Transfer-Encodingヘッダはありません。シフトJISコードが読めるのであれば文字化けは発生しないと思いますが、7bitではなく8bitで送信しているので、7bitしか通過できない経路を経由した場合、RFC的には文字化けが発生する可能性があります。
メールアドレスに日本語情報を付与して送信した場合の実行結果
メールを送る際、「hogehoge@hoge.jp」ではなく「"初音"<hogehoge@hoge.jp>」のように、メールアドレスだけではなく姓名や役職名なども含めて送信したいときがあります。
このような指定を行った場合、サンプル「CZ1003Simple」の実行結果は次のようになります。
（1）System.Net.Mail.SmtpClientの場合
System.Net.Mail.SmtpClinetのSendメソッドはこの形式のアドレス指定に対応していないため、指定をした場合は実行時エラーとなります。
（2）SecureMailの場合
SecureMailのSendメソッドはこの形式のメールアドレス指定にも対応しているため、正常に送信が行えます。
To: "初音玲" <hatsune@wankuma.com> From: "初音玲" <hatsune@wankuma.com> Subject: [GSM]Fromも件名も日本語がどう処理されるかのtest用件名 Date: Sun, 14 Mar 2010 21:03:33 +0900 (JST) 日本語本文
SecureMailのSendメソッドが日本のデファクトスタンダード仕様をデフォルトでサポートしていれば最も良いのですが、デフォルトが非MIMEメールクライアント用であるというコンセプトは一概に否定できません。
エンコードを指定してメールを送信する
Sendメソッドでシンプルにメール送信した場合、どちらを使っても日本語の扱いが心許なかったと思います。そこで次に、エンコードを指定するコードを追加した場合の送信メールについて確認してみましょう（サンプル「CZ1003Message」）。
System.Net.Mailの使用方法
Using msg As New System.Net.Mail.MailMessage
msg.To.Add(New System.Net.Mail.MailAddress(Me.To_TextBox.Text.Trim))
msg.From = New System.Net.Mail.MailAddress(Me.From_TextBox.Text.Trim)
msg.Subject = "[SNM]" & Me.Subject_TextBox.Text.Trim
msg.Body = Me.MailText_TextBox.Text
msg.SubjectEncoding = System.Text.Encoding.GetEncoding("iso-2022-jp")
msg.BodyEncoding = msg.SubjectEncoding
msg.Headers.Add("Content-Transfer-Encoding", "7bit")
Try
Dim smtp As New System.Net.Mail.SmtpClient 'IDisposeを実装してない
smtp.Host = Me.Server_TextBox.Text.Trim
smtp.Port = Me.Port_TextBox.Text.Trim
smtp.Credentials = New NetworkCredential(Me.UserId_TextBox.Text.Trim, _
Me.Password_TextBox.Text.Trim)
smtp.Timeout = 100000
smtp.Send(msg)
isOK = True
MessageBox.Show("Sytem.Net.Mail送信終了")
Catch ex As Exception
MessageBox.Show(ex.Message, Me.Text, MessageBoxButtons.OK, MessageBoxIcon.Exclamation)
Finally
End Try
End Using
System.Net.Mailでエンコードを指定するときには、System.Net.Mail.MailMessageを使ってSubjectEncodingとBodyEncodingにSystem.Text.Encoding.GetEncoding("iso-2022-jp")を指定します。Content-Transfer-Encodingヘッダについては、Headers.Addメソッドによって明示的に指定します。
まず注目してほしいのは、SubjectとBodyにはEncoding指定があるのに、ToやFromには存在しない点です。ToやFromにエンコードを施すには、System.Net.Mail.MailAddressの指定を次のようにしなければなりません。
msg.To.Add(New MailAddress(Me.To_TextBox.Text.Trim),"表示名",GetEncoding("iso-2022-jp"))
よって、図5のように表示名も同時に指定できるような場合は、メールアドレスと表示名に切り分ける必要があります。
このコードを使って送信したメールをBecky!で受信すると、ToやFromの表示名、Subjectの日本語が文字化けしてしまいます。Becky!の［表示］-［ソースの表示］で確認してみます。
Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: =?utf-8?Q?=E5=88=9D=E9=9F=B3=E7=8E=B2?= <hatsune@wankuma.com> To: =?utf-8?Q?=E5=88=9D=E9=9F=B3=E7=8E=B2?= <hatsune@wankuma.com> Date: 15 Mar 2010 23:26:24 +0900 Subject: =?iso-2022-jp?Q?[SNM]Charset=1B$B@_DjF|K\8l$N7oL>$,$I$&=3DhM}$5$l$k$+$N=1B(Btest=1B$BMQ7oL>=1B(B?= Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable =1B$BF|K\8lK\J8=1B(B
Content-Transfer-Encodingヘッダが2種類あったり、Content-TypeヘッダでISO-2022-JPを指定しているのにToとFromの表示名はUTF-8で扱われていたりと、不思議な内容になっています。
また、Subjectや本文は確かにISO-2022-JPのコード系のようですが、7bitの指定は無視され、Qエンコードされてquoted-printableになっているなど、やはり日本でのデファクトスタンダードに合った形式では遅れませんでした。Becky!は比較的文字化けが起こらないメールクライアントソフトですが、そのメールクライアントソフトですらお手上げのようです。
Dart.PowerTCP.SecureMailの使用方法
Using msg As New Dart.PowerTCP.SecureMail.MessageStream
msg.To.Add(New Dart.PowerTCP.SecureMail.MailAddress(Me.To_TextBox.Text.Trim))
msg.From = New Dart.PowerTCP.SecureMail.MailAddress(Me.From_TextBox.Text.Trim)
msg.Subject = "[GSM]" & Me.Subject_TextBox.Text.Trim
msg.Text = Me.MailText_TextBox.Text
msg.Charset = "ISO-2022-JP"
msg.ContentType = "text/plain"
msg.Header.Add(Dart.PowerTCP.SecureMail.HeaderLabelType.ContentTransferEncoding, "7bit")
Try
Using smtp As New Dart.PowerTCP.SecureMail.Smtp
smtp.Server = Me.Server_TextBox.Text.Trim
smtp.ServerPort = Me.Port_TextBox.Text.Trim
Select Case True
Case Me.AuthLogin_RadioButton.Checked
smtp.LoginMethod = Dart.PowerTCP.SecureMail.SmtpLoginMethod.AuthLogin
Case Me.AuthPlain_RadioButton.Checked
smtp.LoginMethod = Dart.PowerTCP.SecureMail.SmtpLoginMethod.AuthPlain
Case Me.AuthMd5_RadioButton.Checked
smtp.LoginMethod = Dart.PowerTCP.SecureMail.SmtpLoginMethod.AuthCramMd5
End Select
smtp.Username = Me.UserId_TextBox.Text.Trim
smtp.Password = Me.Password_TextBox.Text.Trim
smtp.Send(msg)
smtp.Close()
End Using
isOK = True
MessageBox.Show("SecureMail送信終了")
Catch ex As Exception
MessageBox.Show(ex.Message, Me.Text, MessageBoxButtons.OK, MessageBoxIcon.Exclamation)
End Try
End Using
System.Net.Mail.SmtpClientと異なり、SecureMailでは個別にエンコードを指定するのではなくDart.PowerTCP.SecureMail.MessageStream全体に対して指定を行います。
msg.Charset = "ISO-2022-JP" msg.ContentType = "text/plain"
そのため、リストにあるように表示名も含んだ形で処理しても、指定されたエンコードの対象になります。なお、Content-Transfer-Encodingヘッダの省略値は7bitなので、Header.Addメソッドによって明示的に追加を行わなくても問題ありません。
このコードを使って送信したメールをBecky!の［表示］-［ソースの表示］で確認すると、次のようにMIME形式でISO-2022-JPで7bitエンコードされたメールになります。これがデファクトスタンダードの日本語メールです。
From: "=?iso-2022-jp?B?GyRCPWkyO05oGyhC?=" <hatsune@wankuma.com> To: "=?iso-2022-jp?B?GyRCPWkyO05oGyhC?=" <hatsune@wankuma.com> Subject: [GSM]Charset=?iso-2022-jp?B?GyRCQF9EakZ8S1w4bCRON29MPiQsJEkkJj1oTX0kNSRsJGskKyROGyhCdGVzdBskQk1RN29MPhsoQg==?= Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Mon, 15 Mar 2010 23:26:29 +0900 MIME-Version: 1.0 $BF|K\8lK\J8(B
惜しむらくは、若干ではありますが、Subjectなどが72バイトよりも長くなった時の折り返しの関係で文字化けする可能性があることです。
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を採用するという選択は非常に有益であり、それこそがコンポーネントを使う意義でもあります。
製品情報
