pop ssl with office365

[madagaga]

When authenticating, the SaslMechanismPlain(PLAIN) build password by getting byte[] from UTF8 encoding.

var userName = Encoding.UTF8.GetBytes (cred.UserName);
var password = Encoding.UTF8.GetBytes (cred.Password);

The test password contains "µ".

System.Text.Encoding.UTF8.GetBytes("µ") => byte[2] { 194, 181 }
System.Text.Encoding.GetEncoding("iso-8859-1").GetBytes("µ") => byte[1] { 181 }

If I replace Encoding.UTF8. by Encoding.Default (wich is iso-8859-1 in my case) it works.

[jstedfast]

What if the user is in a country that does not use iso-8859-1? What if the code is running on a .NET runtime that doesn't have Encoding.Default and/or always sets Encoding.Default to unicode (like some of the Silverlight and WindowsPhone and possibly other versions do)? What if the server expects UTF-8 but your desktop's default charset is iso-8859-1? Or what if the server expects iso-8859-1 but your desktop's default charset is UTF-8?

[madagaga]

I don't really understand your comment. I just say, that when authenticating on office365 pop3 account using ssl, I saw this issue.
I don't think changing enconding is the best solution.
This is my first observation on why and how.

[jstedfast]

I can provide an alternate Authenticate() API that allows you to specify a charset, but there's no way for MailKit to know what charset to use. Most of the time, UTF8 is the correct charset to use. In your case, it isn't.

Most likely Outlook365 is brokenly encoding your password in their database, because they should not be using iso-8859-1.

[jstedfast]

You can now use:

client.Authenticate (Encoding.Default, "username", "password");

[madagaga]

Thanks for your assistance , and your patience !

[jstedfast]

FWIW, I've released MailKit 1.2.18 with the new APIs to allow specifying a charset override.