Loading ...
Sorry, an error occurred while loading the content.

294293Re: How best to eliminate "domain mismatch" warning in mail clients when TLS is used

Expand Messages
  • Ben Johnson
    Jul 15, 2013
    • 0 Attachment
      On 7/15/2013 1:10 PM, Viktor Dukhovni wrote:
      > On Mon, Jul 15, 2013 at 12:47:53PM -0400, Ben Johnson wrote:
      >
      >> In essence, our clients wish to use their own SSL certificates for their
      >> SMTP connections.
      >
      > Are these submission clients? What does the above mean?
      >

      Yes, these are submission clients. To be clear, our clients want to be
      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
      reasonable request.

      >> Our clients will not accept the position, "You just have to ignore the
      >> '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
      > service?
      >

      This is an excellent question, and a question to which I lack a "good
      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 our
      >> 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.
      >

      Right, but only provided that the customer can live with its own users
      configuring their MUAs to use our (the hosting company's) domain for
      submission.

      >> They want to maintain the appearance that they handle all of their own I.T.
      >> 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.

      To their own users. I agree with you completely; and that's exactly what
      it is: a cosmetic appearance that carries a high cost while providing no
      real value.

      >
      >> 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.

      I will do that.

      >
      >> 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.
      >

      Understood.

      >> I've read over the information at
      >> 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!
      >

      Yours is a fair argument, indeed. :) I sympathize.

      >> To quote Viktor from the same thread:
      >>
      >> "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.
      >

      You're right; as long as the MUAs are configured to use
      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 address
      >> 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
      > warnings.
      >

      This seems to be the only course of action. And trust me, I do not
      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
      responded.

      Best regards,

      -Ben
    • Show all 15 messages in this topic