Известные баги System.Net.Mail.SmtpClient в .NET 3.5

Сегодня открыл для себя некоторые глюки класса System.Net.Mail.SmtpClient в .net framework 3.5. (Я уже не говорю что творилось с System.Web.Mail.*, но оно уже obsolete и слава небесам. RIP).

1. Некорректная реализация команды EHLO протокола SMTP. Согласно RFC#821 ещё лохматого года необходимо передавать FQDN хоста-отправителя, причем по RFC это правило строгое. Вместо этого в MS решили, что хватит и NetBIOS-имени компа. Соответственно сервера, не отклоняющиеся от стандарта посылают ентот SmtpClient лесом, как пытающийся разослать спам. Решения нет. Есть только очень неочевидный WorkAround через Reflection.

2. Вытекает из первого. MS хотела как лучше, и разрешила называть компьютеры в NetBIOS сетях именами с символами из национальных алфавитов. Мало того, собсно Windows 7 RU предлагает подобное имя при установке! (Правда при попытке сменить руками, уже после установки, честно предупреждает что нехорошо использовать символы русского алфавита). И, как я уже говорил выше, это NetBIOS-имя использует SmtpClient в качестве имени хоста, правда никак не кодируя символы национальных алфавитов. После чего сам же валится с исключением "недопустимый знак в заголовке электронной почты". Собственно исключение то другое, но вот InnerException именно такой. Решения нет. Есть только очень неочевидный WorkAround через Reflection.

3. Очень интересный взгляд на стандарты почтовых протоколов со стороны MS. Все уже привыкли, что MS если и читает чужие стандарты, то как то очень избирательно. Вот и стандарт на SMTP также ими был прочитан. И, соответственно, также реализован. Что привело к тому, что некоторые SMTP сервера напрочь не работают с SmtpClient от MS. Например Kerio. Решения нет. WorkAround'ов нет.

Обиднее всего то, что все это хозяйство тянется ещё с .net 2.0, все эти баги давно зарегистрированы, но MS плевало на отправку почты. Надо бы их SmtpClient с hotmail'ом проверить. Интересно, заработает ли?