On 12 April 2018 at 00:49, Ned Freed <ned.freed@xxxxxxxxxxx> wrote:
And once again I'm afraid what your intution is telling you is exactly the> This workload is what I consider to be the antithesis of "intuitively
> simpler".
opposite of my experience. For me implementing this using a separate query
server actually makes things much easier, not harder, in part because I'm not
constrained to code things in C/C++, which is what the SMTP client is coded in.
You might want to sit down and try mocking this up in, say, node.js. It may
change your mind about the approach.
And the client part is going to be maybe 50 lines of C code. Code of a sort
I've written many, many, many times before. Hardly difficult.
That's all well and good, but people are saying that DANE is simple enough to implement too.
> > > c) Both/either of the above.
> >
> > > I assume the logic behind allowing a wildcard-to-wildcard match is to
> > allow
> > > a Google user to simply specify ".googlemail.com" and ".l.google.com" as
> > > their MX identity patterns; however it feels as though Google could
> > simply
> > > use a known name within the certificate for all their receiving MTAs,
> > > irrespective of the DNS records involved. This, of course, presupposes
> > that
> > > the administrator of the mail domain somehow does not know the precise
> > > names of the MTAs used in their own DNS records.
> >
> > > I further assume the logic in mandating matches against dNSName SANs is
> > > because these are readily available; however sRVName SANs, by restricting
> > > their use to a particular service, have the advantage that customers
> > giving
> > > these to their service provider might be deemed more acceptable.
> >
> > A comparable effect can be achieved by using a subdomain root reserved for
> > email server use.
> >
> > So it's a choice between an easily implemented naming convention and a
> > bunch
> > of PKIX esoterica. This does not strike me as a difficult choice.
> >
> >
> Well, being *able* to use sRVName would be nice at least. The specification
> as written prevents it, which seems unfortunate.
I have to say I like the simplicity of the current specification, and I don't
want to see added complexity in this regard without a compelling reason for
adding it.
OK, as long as you understand this embeds a hack into PKIX.
> > > o MTA-STS Policy: A commitment by the Policy Domain to support PKIX
> > > [RFC5280] authenticated TLS for the specified MX hosts.
> >
> > > Impressively, by my reading, the commitment is for the Policy Domain to
> > > support PKIX for all SMTP; and not just for specified hosts.
> >
> > Of course that's the commitment. How could it be otherwise?
> >
> Then that needs rephrasing, because I didn't see any "Of course" about it.
> A commitment by the Policy Domain to support PKIX [RFC 5280] authenticated
> TLS, using reference identifiers as listed.
> (I'm trying to guess what was meant by "for the specified MX hosts".)
The entire point of the mechanism is to say that the policy domain supports
and wants SSL/TLS transfers and that the servers have validated certs
with the specified names. So I really don't understand what you're getting
at here.
It says "MX host", which, as near as I can guess, is used elsewhere to mean a host used as a Mail Exchanger, and not either of the "MX Hostname" or the "Reference Identifier".
Dave.
