After a year of working on MimeKit and MailKit, Jeffrey Stedfast has completed what are probably the most comprehensive MIME and email libraries for .NET. These libraries support SMTP, POP3, and IMAP, including dozens of IMAP4 extensions. Also included is support for the new International Emails standards, a first for the .NET platform.
InfoQ: What problems were you seeing in other MIME libraries that made you want to create your own?
Jeffrey Stedfast: The first thing I noticed about many of the other MIME libraries out there is that their parser methods took a System.String instead of a System.IO.Stream. If we could depend on mail clients, automated email scripts, and spambots to send RFC-compliant email messages, then there would be nothing wrong with treating messages as strings. The problem is that this is not the case. In all fairness to the MIME libraries that I had looked at, this sort of problem is not something you can expect a developer to necessarily know without having been exposed to these problems before he or she went on to design their library.
The other major reason for me deciding to try my hand at writing a good MIME parser library and later a POP3, IMAP, and SMTP library was performance. Having done a lot of work with I/O using C in the past (and having written a C MIME parsing library), I knew that it should be possible to parse multiple gigabytes of email within the span of a few seconds, but every .NET library capable of parsing MIME that I could find took minutes. To me, this was unacceptably slow.
I guess that you could say that a third contributing factor was that my boss, Miguel de Icaza, had been dropping hints that I should write a good email library for .NET since at least 2007 when I joined his Mono team at Novell.
InfoQ: What made IMAP harder to implement than SMTP and POP3?
Jeffrey: SMTP and POP3 are both very simple protocols with very simple responses that you need to worry about parsing. IMAP, on the other hand, has dozens of commands that have much more complex responses as well as unsolicited responses (e.g. another client has just deleted a message or a new message has arrived, etc), not to mention some 40 or more extensions which each introduce their own commands or syntactical changes to the core IMAP protocol (most of which I've implemented in MailKit at this point).
InfoQ: In the original announcement, you mentioned IETF email-related specifications. Can you explain what those are and why they are important?
Jeffrey: The IETF is the Internet Engineering Task Force which is a standards body for internet protocols (POP3, IMAP, SMTP, etc) and data exchange formats (such as MIME). They consist mostly of volunteers (as far as I understand it) that work together to design and document new protocols and formats to allow software to interoperate. The reason that they are important for email is because the IETF designed the protocols that every mail client and server in the world uses today to communicate, so to achieve maximum interoperability with those other clients and servers, it is necessary to take advantage of the freely available protocol and format specifications that are available on the IETF's website (www.ietf.org).
Anyone that clones MimeKit or MailKit from my GitHub page (https://github.com/jstedfast) will notice that both MimeKit and MailKit have a directory containing all of the relevant specifications. This is because I find adhering to these specifications so important that I want to make it trivial for any contributors (as well as myself) to find the specifications for whatever code they are working on.