Exactly. I'd like to see 'new' email protocol built built on non-optional foundations. When we use http over SSL/TLS, browser either shows padlock icon or does not show padlock icon. While implementation has its occasional flaws and bugs, specification does have defined on/off state, not many optional layers in between.
We can make any communication channel secure, by adding layers of encryption, no problem with that. But unless it is defined deep down as a part of the standard, it all ends with no security at all and no means to be sure what happened with the message along the way.
Having headers exposed is one of the reasons why I raised initial concern. It is part of the specification and unlikely to go away by building on top of the standard.
No, "adding layers of encryption" does not equal "security". For encryption to provide real security, you need to solve key distribution, which for all practical purposes is unsolved.
And no, when you claim that HTTPS has "not many optional layers in between" that mostly suggests that you just treat it as a black box rather than that there is no complexity there. The simplicity is in the user interface only, and that is arguably broken because it does not actually reliably reflect actual security.
Really, once again, you mostly make the impression that you don't really understand the problems with email and just think that it's broken because it's old. Anyone with that attitude is likely to just repeat all the same mistakes that we've been through with email, and in the end not solve any of the actual problems.
There is no way in hell I could be accidentally misquoted and misunderstood, three out of three 'arguments' in single post. Yeah, let's pretend that I have no idea what I am talking about -- much easier than acknowledging any kind of flaw in actual foundation of the architecture.
I can't be any more clear than what I already said. If you decide to take an easy road and kill the messenger, no problem with that. I don't have any intention to continue with this discussion indefinitely, especially if it turns out to ad hominem. History teaches that killing the messenger does not make problem go away. You see it or not, decide to ignore it or not... fine by me.
You also might want to look up what an ad hominem is. Hint: Suggesting that someone lacks knowledge about what they are talking about is not. And in particular, it is not logically fallacious to deduce that if someone lacks knowledge that therefore they might be providing unreliable information.
And while you are at it, maybe also look up what "killing the messenger" means and how it is used.
But you are right that the much more fundamental problems that are actually there won't go away if you keep ignoring them.
By the way, the one who claimed that you were not really an expert on this was you, a few posts ago.
Now, if you have any actual specific problems with email that you think a new system would be better able to solve, feel free to explain it, then I can explain more concretely what the problem with your proposal is or how you are missing the actual underlying problem - or possibly accept that you indeed do have a valid point, though I wouldn't be too optimistic about that at the moment.
We can make any communication channel secure, by adding layers of encryption, no problem with that. But unless it is defined deep down as a part of the standard, it all ends with no security at all and no means to be sure what happened with the message along the way.
Having headers exposed is one of the reasons why I raised initial concern. It is part of the specification and unlikely to go away by building on top of the standard.