294293Re: How best to eliminate "domain mismatch" warning in mail clients when TLS is used
- Jul 15, 2013On 7/15/2013 1:10 PM, Viktor Dukhovni wrote:
> On Mon, Jul 15, 2013 at 12:47:53PM -0400, Ben Johnson wrote:Yes, these are submission clients. To be clear, our clients want to be
>> In essence, our clients wish to use their own SSL certificates for their
>> SMTP connections.
> Are these submission clients? What does the above mean?
able to configure their MUAs to use our MTA's submission service via
their own domain names. I know; it is not necessarily a rational or
>> Our clients will not accept the position, "You just have to ignore theThis is an excellent question, and a question to which I lack a "good
>> 'domain mismatch' warning and accept the certificate permanently when
>> you connect to the mail server." And I don't blame them.
> Why are they each using a different name for the same submission
answer". I have no idea why there is such resistance to using our domain
name. The best I can discern is that our company's clients (as in
"customers" -- not "mail clients") want their own domain names and their
own SSL certificates to be used for TLS connections. As I said in my
reply to Wietse, this is not a logical position to take, given that our
clients must "trust" us, implicitly, as we control the server on which
plaintext copies of their mail are stored. For some reason, this
"control" seems to pacify the decision-makers, and falsely so, of course.
>> Also, our clients don't want to create DNS records that contain ourRight, but only provided that the customer can live with its own users
>> hostname or IP address.
> There is certainly no need for that. The right server name lies
> in your DNS zone.
>> The reasons vary, but, in general, our clients
>> don't want to look "unprofessional" by having a hosting company's domain
>> name in their DNS records.
> It would not be in their DNS. It would be in their submission
> client (MUA) configuration.
configuring their MUAs to use our (the hosting company's) domain for
>> They want to maintain the appearance that they handle all of their own I.T.To their own users. I agree with you completely; and that's exactly what
>> needs. I know, it seems silly, but we run into this often.
> To their own users or to people sending them email? 3rd party
> senders don't see the name of the submission service used between
> your clients and their provider. Politely explain that this cosmetic
> preference has a high cost for you and them, and they're better off
> without this.
it is: a cosmetic appearance that carries a high cost while providing no
>I will do that.
>> To quote Peter in the above-cited thread:
>> "I used google apps as an example of a provider that services what
>> probably amounts to tens or hundreds of thousands of domains for email,
>> and they do it all with one SSL certificate with only a single common
>> name. smtp is not http and it does not work the same, you simply do not
>> need to have a separate SSL certificate for every domain you host, one
>> certificate will work for everything."
> Quote this to your clients.
>> Sure, one certificate will "work", but won't using one certificate for
>> all domains cause a "domain mistmatch" warning if the client uses his
>> own hostname to send mail from within his mail client (and we do not
>> have a certificate that includes all of our clients' hostnames in the
>> SubjectAltNames field)? That has certainly been my experience.
> The correct configuration of the MUA is to include the right MSA
> name. When in a decade or so, MUAs generally use SRV records to
> locate the right MSA for a domain, they can find this MSA via SRV
> records, and use DANE to authenticate it. For now they set the
> right server name.
>> I've read over the information atYours is a fair argument, indeed. :) I sympathize.
>> http://www.postfix.org/TLS_README.html#client_tls_dane several times and
>> am still trying to digest it fully. The "gist" seems to be that DANE
>> would require our company's hostname and/or IP address to be present in
>> the client's DNS records.
> No. And in any case MUAs don't yet do DANE.
>> not want rDNS look-ups to return records relating to our Web
>> Design/Development/Hosting company. Again, the rationale for this
>> usually relates to "maintaining a professional and independent I.T.
>> presence" (a euphemism for, "we don't want to appear incompetent by
>> outsourcing our I.T. needs to a third-party").
> Tell they look even more competent when they sensibly choose a well-reputed
> competent provider!
>> To quote Viktor from the same thread:You're right; as long as the MUAs are configured to use
>> "If you want to host submission for large numbers of vanity domains
>> on a single MTA, why must the clients be configured to contact
>> "smtp.vanity-domain.com"? What's wrong with "smtp.provider.net"?"
>> I've explained the problem in this regard ("domain mismatch" warnings).
> There is no mismatch when the MUAs are configured to use
> "smtp.provider.net" and the MSA has the corresponding certificate. You're
> failing to explain what problem you're seeing.
smtp.provider.net, there is no issue.
The challenge for me is explaining why MUAs must be configured with
ourhostingcompany.com and not the customer's own domain name.
>> Have I missed anything fundamental? What are others doing to addressThis seems to be the only course of action. And trust me, I do not
>> similar client demands?
> Publish a single client-independent name for your MSA. Your client
> MUAs must use that name. This works with no domain mismatch or other
undertake this route begrudgingly. Everything that you and the other
respondents have said makes perfect sense, from a logical and technical
perspective. Unfortunately, the majority of folks who depend on people
in our professional is neither technical nor logical (at least where
technology is concerned), so this will be a bit of a "tough sell". But
this thread has given me additional ammo to throw at the challenge.
I appreciate all of the expert insight, Viktor, and everyone else who
- << Previous post in topic Next post in topic >>