Thanks for your comments. Really good.
About working together is good if anyone wants it. There are several projects about SMTP, POP3, IMAP, MIME...maybe anyones working together for improvement better libraries, all efforts to Community. However, every developer is free to do it or not. Like I'm newbie, if only suggestions for all good developers like you and others in those projects.
Christtian Nilsson say
Why I started to use and still use S22.Imap instead of any other lib:
S22.Imap is a IMAP Client, nothing else just a IMAP client.
When I was trying to find a IMAP Client I found and looked on AENetMail however that is not a IMAP Client, it is a full email client library.
Any other library that is not only a IMAP Client is bloated for my purposes (sorry for the choice of word)
Something that might be interesting however is https://github.com/jstedfast/MimeKit
If I can find the time I would like to check it out and see if it could be reused.
But MailKit is of no use to me since (as with many of the others) it contains a POP3 client as well.
And then we have Comments like "Wow, this is pure crap" who wants to work with someone with a attitude like that?
One of the biggest issues with the .Net implementation of mail is the standard Net.Mail namespace, but most of what is needed for other client libraries are Internal in the base framework, and thus must be recreated with extra code.
Jeffrey Stedfast says:
MimeKit can be reused (that was the goal of the project). In fact, I wasn't really planning to write MailKit since I have no real interest in writing a mail client. The plan was for other people to write POP3, SMTP, and IMAP libraries built on top of MimeKit.
After getting a bunch of emails asking me how to send MimeKit messages via SMTP and/or asking me to plug MimeKit into this or that POP3 library, I gave up and implemented my own SmtpClient and Pop3Client. Since these clients are vastly more robust than any of the other Smtp and Pop3 clients I've seen, I can just point people at using those. I'm not super enthusiastic about writing an ImapClient because the last C implementation I wrote was ~10,000 lines of code to support all of the features and be usable while the network is offline, handling reconnecting when the server sends back untagged BYE responses that weren't the result of a LOGOUT command, etc. and that didn't even include IDLE support (which these days is a pretty MUST HAVE feature).
You'll notice that unlike every other POP3 .NET library, MailKit's Pop3Client does not use a lame line-reader approach (see Pop3Stream), nor does it duplicate the retrieved messages into a memory stream before parsing, it parses directly from the socket doing on-the-fly dot-decoding and is completely cancelable (another advantage of MimeKit).
I called that other IMAP client implementation crap because, well, it's crap. I mean, you can't just read a hunk of data from the socket, convert it into unicode (without first knowing what charset the mime message is in) and then use IndexOf(')') to figure out where the end of the message is with the assumption that that character does not appear in the message itself (haha, good luck with that).
Most people who implement POP3 and IMAP clients assume that the protocols are string-based, but they really aren't. At least not when you are using a programming language where strings are multi-byte (such as UTF-16). Sure, they are text-based, but when using Java or C#, you can't really use strings because you need to know the charset first and you can't know the charset before you parse the email message (or, in the case of IMAP, envelope data as well), and even then, each part might be in a different charset, so you can't use a single charset for conversion into unicode. The only parts of the response that you can read as strings are the actual protocol tokens (because they are ASCII tokens), which means you CANNOT use a TextReader. You have to read raw bytes (you can convert segments of the byte[] into strings as you go, of course, but you can't just gulp up the entire response as a string).
Then, of course, there's the fact that when reading a literal string response from the IMAP server, most IMAP implementations I've seen make the incorrect assumption that the octet count provided in the "{xxx}" is the same as the String.Length, which of course is wrong.
Now that I've pointed out these fundamental problems that plague every Pop3 and IMAP client I've seen for .NET, I'm sure you better understand why I call such clients crap.
Just an example of what I'm talking about: andyedinborough/aenetmail#150
AENetMail doesn't properly decode the dot-encoding that is used in the RETR command, nor does it even use the correct approach to figuring out the end of the response which is what causes any further commands to fail.
Some bugs are just bugs, but others are fundamental design problems.
Anyway, I don't care one way or another if S22.Imap decides to use MimeKit, although I'm more than willing to answer any questions the developers have about using it and fixing any bugs or adding any features they need (within reason, of course).
Most of the time, plugging in an alternative XYZ library is not trivial and requires a lot of rewriting of significant chunks of code, and generally developers of libraries such as this aren't going to bother rewriting their library if the itch they set out to scratch has already been solved well enough for their needs.
https://github.com/smiley22/S22.Imap/issues/72
About working together is good if anyone wants it. There are several projects about SMTP, POP3, IMAP, MIME...maybe anyones working together for improvement better libraries, all efforts to Community. However, every developer is free to do it or not. Like I'm newbie, if only suggestions for all good developers like you and others in those projects.
Christtian Nilsson say
Why I started to use and still use S22.Imap instead of any other lib:
S22.Imap is a IMAP Client, nothing else just a IMAP client.
When I was trying to find a IMAP Client I found and looked on AENetMail however that is not a IMAP Client, it is a full email client library.
Any other library that is not only a IMAP Client is bloated for my purposes (sorry for the choice of word)
Something that might be interesting however is https://github.com/jstedfast/MimeKit
If I can find the time I would like to check it out and see if it could be reused.
But MailKit is of no use to me since (as with many of the others) it contains a POP3 client as well.
And then we have Comments like "Wow, this is pure crap" who wants to work with someone with a attitude like that?
One of the biggest issues with the .Net implementation of mail is the standard Net.Mail namespace, but most of what is needed for other client libraries are Internal in the base framework, and thus must be recreated with extra code.
Jeffrey Stedfast says:
MimeKit can be reused (that was the goal of the project). In fact, I wasn't really planning to write MailKit since I have no real interest in writing a mail client. The plan was for other people to write POP3, SMTP, and IMAP libraries built on top of MimeKit.
After getting a bunch of emails asking me how to send MimeKit messages via SMTP and/or asking me to plug MimeKit into this or that POP3 library, I gave up and implemented my own SmtpClient and Pop3Client. Since these clients are vastly more robust than any of the other Smtp and Pop3 clients I've seen, I can just point people at using those. I'm not super enthusiastic about writing an ImapClient because the last C implementation I wrote was ~10,000 lines of code to support all of the features and be usable while the network is offline, handling reconnecting when the server sends back untagged BYE responses that weren't the result of a LOGOUT command, etc. and that didn't even include IDLE support (which these days is a pretty MUST HAVE feature).
You'll notice that unlike every other POP3 .NET library, MailKit's Pop3Client does not use a lame line-reader approach (see Pop3Stream), nor does it duplicate the retrieved messages into a memory stream before parsing, it parses directly from the socket doing on-the-fly dot-decoding and is completely cancelable (another advantage of MimeKit).
I called that other IMAP client implementation crap because, well, it's crap. I mean, you can't just read a hunk of data from the socket, convert it into unicode (without first knowing what charset the mime message is in) and then use IndexOf(')') to figure out where the end of the message is with the assumption that that character does not appear in the message itself (haha, good luck with that).
Most people who implement POP3 and IMAP clients assume that the protocols are string-based, but they really aren't. At least not when you are using a programming language where strings are multi-byte (such as UTF-16). Sure, they are text-based, but when using Java or C#, you can't really use strings because you need to know the charset first and you can't know the charset before you parse the email message (or, in the case of IMAP, envelope data as well), and even then, each part might be in a different charset, so you can't use a single charset for conversion into unicode. The only parts of the response that you can read as strings are the actual protocol tokens (because they are ASCII tokens), which means you CANNOT use a TextReader. You have to read raw bytes (you can convert segments of the byte[] into strings as you go, of course, but you can't just gulp up the entire response as a string).
Then, of course, there's the fact that when reading a literal string response from the IMAP server, most IMAP implementations I've seen make the incorrect assumption that the octet count provided in the "{xxx}" is the same as the String.Length, which of course is wrong.
Now that I've pointed out these fundamental problems that plague every Pop3 and IMAP client I've seen for .NET, I'm sure you better understand why I call such clients crap.
Just an example of what I'm talking about: andyedinborough/aenetmail#150
AENetMail doesn't properly decode the dot-encoding that is used in the RETR command, nor does it even use the correct approach to figuring out the end of the response which is what causes any further commands to fail.
Some bugs are just bugs, but others are fundamental design problems.
Anyway, I don't care one way or another if S22.Imap decides to use MimeKit, although I'm more than willing to answer any questions the developers have about using it and fixing any bugs or adding any features they need (within reason, of course).
Most of the time, plugging in an alternative XYZ library is not trivial and requires a lot of rewriting of significant chunks of code, and generally developers of libraries such as this aren't going to bother rewriting their library if the itch they set out to scratch has already been solved well enough for their needs.
https://github.com/smiley22/S22.Imap/issues/72