The Wait Is Over: MimeKit and MailKit Reach 1.0


#1

After about a year in the making for MimeKit and nearly 8 months for MailKit, they’ve finally reached 1.0 status.

I started really working on MimeKit about a year ago wanting to give the .NET community a top-notch MIME parser that could handle anything the real world could throw at it. I wanted it to run on any platform that can run .NET (including mobile) and do it with remarkable speed and grace. I wanted to make it such that re-serializing the message would be a byte-for-byte copy of the original so that no data would ever be lost. This was also very important for my last goal, which was to support S/MIME and PGP out of the box.

All of these goals for MimeKit have been reached (partly thanks to the BouncyCastle project for the crypto support).

At the start of December last year, I began working on MailKit to aid in the adoption of MimeKit. It became clear that without a way to inter-operate with the various types of mail servers, .NET developers would be unlikely to adopt it.

I started off implementing an SmtpClient with support for SASL authentication, STARTTLS, and PIPELINING support.

Soon after, I began working on a Pop3Client that was designed such that I could use MimeKit to parse messages on the fly, directly from the socket, without needing to read the message data line-by-line looking for a “.\r\n” sequence, concatenating the lines into a massive memory buffer before I could start to parse the message. This fact, combined with the fact that MimeKit’s message parser is orders of magnitude faster than any other .NET parser I could find, makes MailKit the fastest POP3 library the world has ever seen.

After a month or so of avoiding the inevitable, I finally began working on an ImapClient which took me roughly two weeks to produce the initial prototype (compared to a single weekend for each of the other protocols). After many months of implementing dozens of the more widely used IMAP4 extensions (including the GMail extensions) and tweaking the APIs (along with bug fixing) thanks to feedback from some of the early adopters, I believe that it is finally complete enough to call 1.0.

In July, at the request of someone involved with a number of the IETF email-related specifications, I also implemented support for the new Internationalized Email standards, making MimeKit and MailKit the first - and only - .NET email libraries to support these standards.

If you want to do anything at all related to email in .NET, take a look at MimeKit and MailKit. I guarantee that you will not be disappointed.


#2

This is awesome news!! You are absolutely correct that a modern component for interacting with mail servers is needed. I used http://mailsystem.codeplex.com/ in the past but it is not being actively maintained. I will definitely take a look at MailKit. Thank you for your community contribution.


#3

Kudos @jstedfast, will definitely take a look!


#4

Let me know if you run into any problems!


#5

Awesome! If you have any problems, just let me know.


#6

I’ve been working on an Exchange ActiveSync client that I have been planning to open source. It has occurred to me that maybe instead of making it an independent project I should submit it to be added to MailKit. Thoughts @jstedfast?


#7

I don’t really know much about Exchange ActiveSync, so it’s hard for me to comment, but from a quick web search, it looks like a protocol designed to allow fetching of messages and message attachments (as well as calendar and contact info) from mail folders? Seems like a reasonable fit.

Would it be possible to make it implement MailKit’s IMailService, IMailStore, and IMailFolder interfaces?

If so, then definitely!


#8

You summed it up pretty well.

I’ll take a look and let you know


#9

After looking at MaiKit I’m thinking a better idea will be a MailKit wrapper around the API I’m writing. The Exchange ActiveSync API doesn’t fit well with how you’ve structured things (though I completely see how it does for IMAP, POP3, and SMTP). So a wrapper if they want to be protocol agnostic and if they want full power can use the library directly. Makes sense?


#10

Yea, that makes sense. I figured that Calendar and Contact data, at the very least, would probably not fill well with the IMailFolder, etc paradigm.


#11

Just wanted to pop in and say I just used them to have our test runner email us test results and it worked first try. LOVE.


#12

That’s always good to hear!


.NET Foundation Website | Blog | Projects | Code of Conduct