The question is whether there's something we can assemble from parts known to work that is less bloated than a full HTTPS client.
R's from my fone,
John
On Apr 6, 2016 12:34, Daniel Margolis <[email protected]> wrote:
That's a pretty depressing conclusion, but yes, I think this is a compromise solution.To be mildly contrarian, though, I would consider HTTP's pervasiveness to be a feature rather than a bug, and the idea that someone could implement the server-side component by using "whatever existing technology they have lying around" to be a benefit rather than a cost. I'd prefer to require people to use robust, well-tested common libraries rather than implement something custom to support a protocol we had designed de novo.I am making no claims that this is anything other than pragmatism at work--we haven't invented the most elegant protocol ever! But if we need out-of-band communication (which we do, given the assumed constraints), HTTPS seems as good as anything because there are many implementations of clients and servers and because it's well-understood and widely supported.DanOn Wed, Apr 6, 2016 at 4:52 PM, John Levine <[email protected]> wrote:>> Speaking as the maintainer of an MTA, no it is not. Having to add
>> support for another protocol to an application which deals in SMTP,
>> and knows how to use a library to get DNS, just feels wrong.
At the dinner a few nights ago we spent a lot of time thinking about
this, and I believe there was a general sense that asking MTAs to
become https clients isn't going to work. But in the absence
of DNSSEC, we didn't have any better ideas.
R's,
John
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
