Folder Name Case Sensitivity

[thomas-mullaly]

Describe the bug
I'm running into problems with the way MailKit and some IMAP servers (Office 365 in my case) handle casing of folder names. Specifically, it seems MailKit is case-sensitive when LISTing a folder on the IMAP server (via ImapClient.GetFolder(string)), but the IMAP server is not.

To Reproduce
If I have folder called "SWEET" (exact casing) and I call ImapClient.GetFolder("sweet") the IMAP server will acknowledge the folder exists during the LIST command, but will respond with the folder names correct casing ("SWEET"). MailKit correctly parses the results (and caches the ImapFolder), but in ImapEngine.GetFolder(List, string) it iterates through the list of folders that got returned, but does an exact case match to find the one you were trying to load. When it can't find it (because the casing is different) it throws the FolderNotFoundException. I've got some protocol logging output from an Office 365 account which I hope helps explain the situation better:

C: A00000007 LIST "" sweet
S: * LIST (\HasNoChildren) "/" SWEET
S: A00000007 OK LIST completed.

Expected behavior
I would expect MailKit to not throw the FolderNotFoundException since the IMAP server acknowledged that folder actually exists.

Desktop (please complete the following information):

• OS: Windows 10, .NET Framework 4.7.2

Additional context
I'm working on switching an existing application (at my job) over to MailKit from a 3rd party mail library that has caused a lot of problems in the past. The 3rd party library we were using appears to have just papered over the casing problem and correctly returned the right folder. Additionally, the folder names we look for are controlled by customers, so it's not as easy as just "use the right folder name casing" to load the folder.

I'm not sure what the IMAP RFC spec says about folder name case sensitivity, but it appears that Office 365 is somewhat lenient on that front.

I looked around to see if any similar issues had already been posted here, but I didn't see any. My apologies if this behavior has already been reported elsewhere.

[jstedfast]

Would it be acceptable to set a boolean property on MailKit's ImapClient to specify whether MailKit should treat folders as case-insensitive?

Most IMAP servers use case-sensitive folder names so it would be possible to have a folder named "SWEET" and "sweet" and have them refer to different folders.

MailKit needs to be able to look up ImapFolder objects that have already been instantiated in order to route events to them and/or otherwise update their state when it changes.

If I make the internal Dictionary<string,ImapFolder> lookup table case-insensitive to make it work for Exchange, then it breaks for 90% of other IMAP servers.

[jstedfast]

The above fix might be enough for you usage.

[thomas-mullaly]

Yeah, I figured there probably wouldn't be a great overall solution for folder name casing problems. The change you just pushed should be sufficient for my use case. Thanks for the quick fix!

[jstedfast]

Let me know if there are other cases and I can see what I can do.

I figure in the explicit LIST/LSUB cases, at least, we can probably safely match insensitively since the LIST response shouldn't generally return a response for any folder other the one explicitly asked for.

(This isn't always the case when using, for example, the NOTIFY extension but that won't be common).

[thomas-mullaly]

Seems like a relatively safe change.

I'll be sure to let you know if something else comes up. Luckily my use case is pretty simple: Get folder, download messages from it, maybe move messages between folders. I don't interact with folders much beyond that.

Thanks again for the fix!

[jstedfast]

How does the user choose a folder? Do you provide a UI? Or just a textbox for them to enter a folder name?

Could you perhaps use:

var root = client.GetFolder (client.PersonalNamespaces[0]);
var subfolders = root.GetSubfolders ();

var selected = ShowFoldersToUserAndAllowThemToSelectOne (subfolders);
// do stuff with selected folder

Of course, GetSubfolders() only lists 1 level, so you'd have to recursively list them if you wanted the user to be able to select any existing folder, but depending on what kind of UI you have, it'd be similar to the way any other "Select Folder" dialog/etc does it on Windows/Mac/Linux/etc.

[jstedfast]

The above solution would eliminate folder name case sensitivity issues because the UI, MailKit, and the server would all use the same case for the folder names.

[jstedfast]

I think there's also:

var allFolders = client.GetFolders (client.PersonalNamespaces[0]);

which lists them recursively, but that is usually not a good idea for servers like UW.IMAP which use the UNIX file system for folders and so you can get infinite recursion if the user has symlinks.

[thomas-mullaly]

The users choose their folders by typing into a text box (via a web page). We do verify that the folders exist before we let them save the configuration. Unfortunately, that bit of the system is still using the old 3rd party mail library, so they can continue to select folders with the wrong casing (I'll eventually switch that bit over to MailKit).

Long term, I agree it'd be better if we displayed the list of folders to choose from. Unfortunately, that'll have to be a future endeavor due to other things that need to get done. I appreciate your advice on this though! Hopefully I'll have time to make some more improvements in this part of our system.

[thomas-mullaly]

@jstedfast do you know when you might be doing another MailKit release? There's no rush, but I've been asked a few times at work about updates on this issue. I said I'd try and find out.

[jstedfast]

There's 2 bug reports I'm waiting for more info on. Once I get that info and fix those bugs (or determine that they are not bugs?), I'll be making a new release. Hopefully the bug reporters will be giving me that info this week.

[thomas-mullaly]

Sounds good. Thank you for the update!