I'm not the only one working on it, but I am the lead. I have my doubts too - but I don't see that as an issue. Any email replacement has a long way to go before it would be used widely - getting a real standard through the IETF alone will be difficult. But, this is a starting point - it's something to build from, a conversation starter if nothing else. Even if it gets ripped to shreds, if it gets people actively working on another solution, then it was worth it.
It's the conversion that matters to me, there needs to be a solution to this, and for that to happen people need to get engaged.
As for anonymity, I don't think there's a good option there - the spec I'm writing isn't anonymous to the recipient, or to the recipient's server. My focus is on encryption and authentication. There's more metadata exposed than I'd like in my model, but it's a balancing act between competing goals. We'll see that in any standard that replaces email - there are many forces at play with different goals and different requirements. No solution will make everyone happy.
There are issues, metadata being a big one, that the proposal I'm working one doesn't address as well as I'd like. I'm hoping others will try to tackle this issue as well, and come up with other methods that may work better.
When we are ready to release a public draft, it'll just be the first step. We don't expect anyone to just say "Hey, that's perfect, let's replace all the email servers" - that isn't going to happen, and it's not our goal. A lot of review will be needed, changes will need to be made to address different concerns, and maybe it'll progress to a useful system. Maybe somebody else will come along with a different idea, and that one will get the community backing. What I want is a replacement system that is secure - I don't care who's design it is. It's not about ego, not about winning for me - it's about prodding the community into action.
As to the last question, as others have answered, K-9 Mail. It works well enough for my needs.
Change has to start somewhere. Starting with a draft and getting feedback from the community before pushing it ahead for more formal standardization seems like the right place to me.
As I said in the article, my goal is to get people talking about potential solutions. I have little hope that the solution I propose will be accepted and used as is - but if it gets more people talking, and discussions going about something that will work, then it was worth the effort.
Yeah, I have mixed feelings about that one; I almost didn't include it, but it's an argument that I hear often enough that I thought it was worth pointing out.
Personally, I have my key on my phone, and I'm fairly comfortable with it - though there are certainly some that aren't.
Based on what's been said here, and on twitter (i.e. https://twitter.com/rmhrisk/status/300351604715057154 ), doesn't it appear that they are in violation of that requirement? Unless contracts and audits meet the requirement for "cannot."