On Wed, Jul 30, 2014 at 07:17:43PM +0200, BlueStar88 wrote:
> First, I still like to limit my proposal to MTA-MTA connections.
You have no proposal, you just don't have the expertise to see
that. Unfortunately there is no royal road to expertise in this
or most other fields.
> This proposal depends on being able to build a reverse tunnel through
> the previously established connection. I don't know, if it is possible
> at all, but I can imagine it is.
It depends on a failure to understand most of what I posted upthread.
What you are suggesting is plain and simple impossible.
> Software developers are in fact only limited by their fantasy. Well, at
> most. ;-P
And mathematical logic, and the laws of physics.
> > I'm afraid your desire for a solution is overwhelming your analytical
> > skills to assess the problem. Your best bet is to hope that the
> > folks with the requisite skills are not negligent in addressing
> > the issue to the extent possible.
>
> Maybe it's just an insufficient communication issue here. I'm not sure
> to express myself correctly. Furthermore your mind maybe still sticks
> too much on thinking about the classical use of client certificates as
> authentication factor only.
No, this is a lack of subject-matter skill, not a failure to
communicate.
> > Contrary to popular belief, in no application protocols (not just
> > SMTP) do TLS client certificates solve the MiTM problem when the
> > client fails to authenticate the server. Rather, what client
>
> Sure, we would have to touch the TLS protocol to "some" degree adding a
> reversed tunnel. That's the point you most likely don't want or are not
> able to. ;-)
Achieving nothing. Google "Dunning-Kruger effect".
> > Bottom line, we're doing what's possible to protect SMTP and no
> > more.
>
> As far as I know STARTTLS was invented after SMTP was. It guarantees
> interoperability and a choice for the peer. The same would apply to
> above proposal.
There is no proposal, just confused banter. You'd best stop here.
--
Viktor.
