SMTPサーバやMIMEメッセージの処理は、確かlumisoftというとこのソースを参考にして私もコーディングしましたが、大変でした。
おがわさんのソースも公開されましたら、是非参考にさせていただきたく楽しみにしております。
ただこの問題について、frameworkがSMTPサーバやMIMEメッセージ関連を
提供していないという点についてはRFCと現実とのギャップが大きい事など、納得できるのですが
もっとミクロな観点で、エンコードして格納した文字列をデコードして出力してくれないクラス
というのは、実装が不十分なのではないかと思ってしまうのです。
frameworkのレベルで解決していただけるとありがたいと思います。
BASP21のようにみんなが使うものにしたいですね。(^^
がんばってくださーーい(^^
これの回答は SmtpClient/MailMessage/MailAddress/MailAddressCollection などのクラスを独自実装するしかないという結論に至っています。
AUTH-PLAIN/AUTH-LOGIN/CRAM-MD5/DIGEST-MD5 の対応や POP before SMTP 、 APOP 、 SSL(SMTPS/POPS) 、 RFC 違反のメールアドレス（特に携帯のメールアドレス）などのサポートを考えると独自の道に進むしかないと思います。
機能的な検証はほぼ終わっているので、後は互換性があるものをコンポーネント化するところまできています。
そうとう先になりますが、そのうちオープンソースで公開するでしょう。
MailMessage と同様に、MailAddressやMailAddressCollectionでも
日本語を含む値をセットすると、quoted-printableでセットされてしまいます。
（MSDN Product Feedback Centerにも以前記載しました）
http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=1b1096df-45c6-4412-80b3-a4ec100cde32
意地と根性で、完全な回避策に限りなく近い方法を見つけ出しました。
[.NET 2.0]日本語(ISO-2022-JP) を Content-Transfer-Encoding: 7bit で送信する方法
この方法だと表題も Base64 でエンコードしてますし、実際の Content-Transfer-Encoding は 7bit です。
ただし、問題があります。
メールヘッダが Content-Transfer-Encoding: sevenbit という記述になるということです。
これを Content-Transfer-Encoding: 7bit にする方法があれば、完璧なんですが。
これquoted-printableですよね。
私も以前試して一人落胆していました(--;;
System.Net.Mail.MailMessage を使用して、日本で一般的な iso-2022-jp で送信すると Content-Transfer-Encoding が quoted-printable で送信されます。
MailMessage の Headers の Content-Transfer-Encoding に 7bit としても Content-Transfer-Encoding: 7bit がメールヘッダに追加されるだけで、実際には quoted-printable で送信されます。
多くのメーラは quoted-printable を対応しつつありますが、まだ一部対応していないメーラも数多く残っています。
自動判別で Content-Transfer-Encoding を決定するだけではなく、指定した Content-Transfer-Encoding でメールを送信できるようにしてほしいと思います。
この実装で、かなりのメールが文字化けになる可能性があります。
System.Web.Mail では Content-Transfer-Encoding が指定できて、いろいろ助かったのですが、.NET Framework 2.0 では推奨されないということなので、何とかならないものかと。
-- サンプルコード --
using System.Net.Mail;
using System.Text;
...
SmtpClient smtpClient = new SmtpClient("localhost", 25);
MailMessage message = new MailMessage(from, to);
message.Headers["Content-Transfer-Encoding"] = "7bit";
message.BodyEncoding = Encoding.GetEncoding("iso-2022-jp");
message.SubjectEncoding = Encoding.GetEncoding("iso-2022-jp");
message.IsBodyHtml = false;
message.Body = "にほんご本文";
message.Subject = "にほんご表題";
smtpClient.Send(message);
-- サンプルコード --
SMTPサーバやMIMEメッセージの処理は、確かlumisoftというとこのソースを参考にして私もコーディングしましたが、大変でした。
おがわさんのソースも公開されましたら、是非参考にさせていただきたく楽しみにしております。
ただこの問題について、frameworkがSMTPサーバやMIMEメッセージ関連を
提供していないという点についてはRFCと現実とのギャップが大きい事など、納得できるのですが
もっとミクロな観点で、エンコードして格納した文字列をデコードして出力してくれないクラス
というのは、実装が不十分なのではないかと思ってしまうのです。
frameworkのレベルで解決していただけるとありがたいと思います。
BASP21のようにみんなが使うものにしたいですね。(^^
がんばってくださーーい(^^
これの回答は SmtpClient/MailMessage/MailAddress/MailAddressCollection などのクラスを独自実装するしかないという結論に至っています。
AUTH-PLAIN/AUTH-LOGIN/CRAM-MD5/DIGEST-MD5 の対応や POP before SMTP 、 APOP 、 SSL(SMTPS/POPS) 、 RFC 違反のメールアドレス（特に携帯のメールアドレス）などのサポートを考えると独自の道に進むしかないと思います。
機能的な検証はほぼ終わっているので、後は互換性があるものをコンポーネント化するところまできています。
そうとう先になりますが、そのうちオープンソースで公開するでしょう。
MailMessage と同様に、MailAddressやMailAddressCollectionでも
日本語を含む値をセットすると、quoted-printableでセットされてしまいます。
（MSDN Product Feedback Centerにも以前記載しました）
http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=1b1096df-45c6-4412-80b3-a4ec100cde32
意地と根性で、完全な回避策に限りなく近い方法を見つけ出しました。
[.NET 2.0]日本語(ISO-2022-JP) を Content-Transfer-Encoding: 7bit で送信する方法
この方法だと表題も Base64 でエンコードしてますし、実際の Content-Transfer-Encoding は 7bit です。
ただし、問題があります。
メールヘッダが Content-Transfer-Encoding: sevenbit という記述になるということです。
これを Content-Transfer-Encoding: 7bit にする方法があれば、完璧なんですが。
これquoted-printableですよね。
私も以前試して一人落胆していました(--;;
System.Net.Mail.MailMessage を使用して、日本で一般的な iso-2022-jp で送信すると Content-Transfer-Encoding が quoted-printable で送信されます。
MailMessage の Headers の Content-Transfer-Encoding に 7bit としても Content-Transfer-Encoding: 7bit がメールヘッダに追加されるだけで、実際には quoted-printable で送信されます。
多くのメーラは quoted-printable を対応しつつありますが、まだ一部対応していないメーラも数多く残っています。
自動判別で Content-Transfer-Encoding を決定するだけではなく、指定した Content-Transfer-Encoding でメールを送信できるようにしてほしいと思います。
この実装で、かなりのメールが文字化けになる可能性があります。
System.Web.Mail では Content-Transfer-Encoding が指定できて、いろいろ助かったのですが、.NET Framework 2.0 では推奨されないということなので、何とかならないものかと。
-- サンプルコード --
using System.Net.Mail;
using System.Text;
...
SmtpClient smtpClient = new SmtpClient("localhost", 25);
MailMessage message = new MailMessage(from, to);
message.Headers["Content-Transfer-Encoding"] = "7bit";
message.BodyEncoding = Encoding.GetEncoding("iso-2022-jp");
message.SubjectEncoding = Encoding.GetEncoding("iso-2022-jp");
message.IsBodyHtml = false;
message.Body = "にほんご本文";
message.Subject = "にほんご表題";
smtpClient.Send(message);
-- サンプルコード --
SMTPサーバやMIMEメッセージの処理は、確かlumisoftというとこのソースを参考にして私もコーディングしましたが、大変でした。
おがわさんのソースも公開されましたら、是非参考にさせていただきたく楽しみにしております。
ただこの問題について、frameworkがSMTPサーバやMIMEメッセージ関連を
提供していないという点についてはRFCと現実とのギャップが大きい事など、納得できるのですが
もっとミクロな観点で、エンコードして格納した文字列をデコードして出力してくれないクラス
というのは、実装が不十分なのではないかと思ってしまうのです。
frameworkのレベルで解決していただけるとありがたいと思います。
BASP21のようにみんなが使うものにしたいですね。(^^
がんばってくださーーい(^^
これの回答は SmtpClient/MailMessage/MailAddress/MailAddressCollection などのクラスを独自実装するしかないという結論に至っています。
AUTH-PLAIN/AUTH-LOGIN/CRAM-MD5/DIGEST-MD5 の対応や POP before SMTP 、 APOP 、 SSL(SMTPS/POPS) 、 RFC 違反のメールアドレス（特に携帯のメールアドレス）などのサポートを考えると独自の道に進むしかないと思います。
機能的な検証はほぼ終わっているので、後は互換性があるものをコンポーネント化するところまできています。
そうとう先になりますが、そのうちオープンソースで公開するでしょう。