I'm sorry if I offended you. I felt that my argument was discredited by appeal to authority.
I absolutely believe that the difficulties dmbaggett lists are real. I've experienced some of them myself on the few occasions that I've written code that integrates with IMAP and POP3. I don't assume that I could find a solution to all of them in a short time.
But here's what I think: These difficulties are not "a barrier to entry". You don't need to solve all these problems to enter the market. You don't need to compete head on with the best competitors to enter a market. You don't need to make an email client that works for everyone.
You just need to focus on specific audience, and solve a problem that no-one else does. If you do that, people will use your product even though it falls short in other regards. And you can leave the hard parts to the big companies.
Your points are valid, no need for them to be blindly discredited. You obviously have real world experience.
The key here is your approaching the problem from a "here's what I think" standpoint and not a "based on the past 5 years of me doing this" standpoint.
Again, it boils down to no having learned, what you don't yet know.
More thoughts...
I do have to say, though, that integrating email features into software (not an email client) these days can be trivial. For example, Rails makes a lot of it trivial.
But that is a very poor litmus test.
The difference between that and a full blown, production level, narrowly focused, tailored towards a specific audience, solving problems that no-one else does email client... are worlds apart.
You have 2 choices today, third parties (Gmail API, JMAP, Nylas, etc...) or diving into a raw IMAP connections (as an example).
The former provides general purpose layers, abstracting the complexity (to some degree). The disadvantage being they are general purpose, features everyone has.
The latter provides the flexibility to create what has not yet been created. And/Or backfill what the general purpose solution lacks (typically a lot).
In general, your approach to software, products and an MVP is spot on. Obviously you have experience doing this.
The point that I, and others make, is that email does not fall cleanly into that same approach. Why? For all the reason already listed plus a TON more not listed.
This is where you are unwilling to be open minded, and as mentioned previously, it's a classic mistake seen many times before.
I absolutely believe that the difficulties dmbaggett lists are real. I've experienced some of them myself on the few occasions that I've written code that integrates with IMAP and POP3. I don't assume that I could find a solution to all of them in a short time.
But here's what I think: These difficulties are not "a barrier to entry". You don't need to solve all these problems to enter the market. You don't need to compete head on with the best competitors to enter a market. You don't need to make an email client that works for everyone.
You just need to focus on specific audience, and solve a problem that no-one else does. If you do that, people will use your product even though it falls short in other regards. And you can leave the hard parts to the big companies.