Could not load the file 'I18N, Version=2.0.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756'.

[amrutha786]

Describe the bug
System.IO.FileNotFoundException has been thrown

System.IO.FileNotFoundException

Could not load the file 'I18N, Version=2.0.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756'.

Platform (please complete the following information):

• OS: Mac OD
• Visual Studio Community Version 8.4.8
• MimeKit Version: 2.6.0

To Reproduce
Steps to reproduce the behavior:

I have created a contact Us page and upon filling all the info and click on submit I see the crash with

System.IO.FileNotFoundException has been thrown
System.IO.FileNotFoundException
Could not load the file 'I18N, Version=2.0.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756'.

Expected behavior
When I click on Submit the form submits successfully

[amrutha786]

Crash as seen

[jstedfast]

Is this on a Xamarin mobile platform?

[amrutha786]

Yes, @jstedfast This is on a Xamarin Mobile Platform (iOS)

And this crash is not very consistent, 5/10times it crashes

[amrutha786]

Now after couple of attempts I am seeing a different crash at the same line of code

System.NotSupportedException has been thrown
Encoding 10079 data could not be found. Make sure you have correct international codeset assembly installed and enabled.

[jstedfast]

This seems like some weird bug in Xamarin?

In MimeKit's CharsetUtils helper class, there's a line of code that does this:

AddAliases (aliases, 10079, -1, "x-mac-icelandic");

If we look at the AddAliases method, we see:

static int AddAliases (Dictionary<string, int> dict, int codepage, int fallback, params string[] names)
{
	int value = ProbeCharset (codepage) ? codepage : fallback;

	for (int i = 0; i < names.Length; i++)
		dict.Add (names[i], value);

	return value;
}

Then, check the implementation of ProbeCharset and we see:

static bool ProbeCharset (int codepage)
{
	try {
		Encoding.GetEncoding (codepage);
		return true;
	} catch {
		return false;
	}
}

It's pretty clear you shouldn't be getting that exception because Encoding.GetEncoding() is wrapped with a try-catch that catches literally every exception.

Can you file a bug with them at https://github.com/xamarin/xamarin-macios ? That's the bug tracker for the Xamarin.iOS and Xamarin.Mac products. Link them back to this ticket so that they can take a look at what the MimeKit code is doing so that they can easily create a test-case and/or perhaps make a suggestion on how to work around this issue.

[jstedfast]

FWIW, what CharsetUtils in MimeKit essentially does is to map non-standard charset names to codepages and in a few cases, overrides the charset name / codepage mapping.

[jstedfast]

Oh, the original crash you had was a FileNotFoundException - not sure where that could be coming from. Perhaps that is also being thrown by Encoding.GetEncoding()?

[jstedfast]

FWIW, before you submit a bug to Xamarin.iOS - make sure that in your Project Options, you enable ALL of the i18n charset regions. You'll need them and the error you are getting probably indicates that you don't have them.

[jstedfast]

Any update on this? Can I close it?

[amrutha786]

Hi @jstedfast I haven't been able to make this change in the Project Options, you enable ALL of the i18n charset regions.

Can you please tell me how to?

[amrutha786]

Opened a issue in Xamarin ios github project dotnet/macios#8815

[jstedfast]

1. Open the Project menu
2. Select the {Project Name} Options menu item
3. Once the Options dialog opens, select iOS Build
4. Scroll down the page until you find the Internationalization section
5. Enable all of the checkboxes (cjk, mideast, other, rare, and west).

[amrutha786]

After i enabled all of the checkboxes and i still get the same crash but with a different message

[jstedfast]

Try calling System.Text.Encoding.RegisterProvider (System.Text.CodePagesEncodingProvider.Instance); in your program during initialization.

[amrutha786]

No Luck, I am still getting the same crash with same message

No data is available for encoding 51936. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method.

[jstedfast]

Maybe the Xamarin.iOS guys know.

[amrutha786]

I have updated the issue opened in Xamarin.iOS github with most of the info,

[amrutha786]

On a side note how secure is using Mimekit & MailKit in our App? because we will be adding sensitve information like our mail client email id with app specific password, smtp server url, and also some more email ids of different selections

How can we be sure that anyone cannot reverse engineer and get to the email id and other details?

[jstedfast]

I wouldn't know how to answer that question.

I guess for MimeKit, there shouldn't be anything to worry about since it'll never have access to your username/password since all it does is construct and parse MIME.

MailKit obviously has APIs where you pass around the username and password as strings to lower-level APIs that encrypt them to send to the server.

If you always use TLS, then passwords will never be sent in the clear no matter what since the TCP/IP layer will be encrypted.

If you don't use TLS, then it's possible they will be sent in the clear if the authentication mechanism employed by the server is plain-text.

For example, IMAP's LOGIN command looks like this:

A00000001 LOGIN "user" "password"

MailKit will only use the the IMAP LOGIN command if the server does not support any SASL mechanisms.

Then we've got SASL mechanisms that we'd need to talk about...

For example, the PLAIN and LOGIN SASL mechanisms only go so far as to base64 encode the user name and password strings (the mechanisms are slightly different, but effectively only base64 encode them).

Not rocket science to reverse engineer, but most IMAP/POP3/SMTP servers do not allow PLAIN or LOGIN SASL mechanisms to be used for authenticating over a clear-text TCP/IP connection - they typically force the client to upgrade to a TLS connection first.

The remainder of the SASL mechanisms (all of which MailKit prefers over PLAIN or LOGIN) hash the password in some way so as to prevent reverse engineering.

I guess the answer is: "no less secure than any other library that handles authentication could possibly be".

[jstedfast]

Interestingly, it looks like MimeKit already calls Encoding.RegisterProvider (CodePagesEncodingProvider.Instance); for you in CharsetUtils.cs before it tries to use any charsets.

[jstedfast]

Since MimeKit already calls Encoding.RegisterProvider (CodePagesEncodingProvider.Instance); in the netstandard versions and it also has try/catches that should be catching these exceptions (but somehow aren't when used with Xamarin), I'm going to close this as there appears to be nothing that can be done on MimeKit's side.

[ryanslovakia]

I am still struggle for this issue in Xamarin 2022, do you have any updates about this?
Thank you very much!

[jstedfast]

@ryanslovakia ask Xamarin