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

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

Expand Messages
  • Ben Johnson
    Hello, We host mail services for a few dozen domains. We will eventually require TLS for all client connections. I have reviewed what seems to be the most
    Message 1 of 15 , Jul 15, 2013
      Hello,

      We host mail services for a few dozen domains. We will eventually
      require TLS for all client connections.

      I have reviewed what seems to be the most comprehensive thread on this
      subject (
      http://postfix.1071664.n5.nabble.com/TLS-SNI-support-td25552.html ) and,
      in light of that information, am trying to determine the best course of
      action.

      In essence, our clients wish to use their own SSL certificates for their
      SMTP connections. Given that there are no plans to implement SNI in
      Postfix (it seems not to be sufficiently useful to justify the work
      involved, which I understand), I am left wondering what the alternative
      might be.

      Our clients will not accept the position, "You just have to ignore the
      'domain mistmatch' warning and accept the certificate permanently when
      you connect to the mail server." And I don't blame them.

      Also, our clients don't want to create DNS records that contain our
      hostname or IP address. 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. 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 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."

      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.

      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. Some of our clients have stated that they do
      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").

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

      We have considered using SubjectAlternativeNames, but we would have to
      change our SSL work-flow considerably and spend a lot of money with our
      "trusted" friends in the SSL CA business.

      Have I missed anything fundamental? What are others doing to address
      similar client demands?

      Thanks for any pointers,

      -Ben
    • Patrick Ben Koetter
      ... In absence of SNI either the MX of all domains point to one MX with a valid cert or you bring up an instance per domain. If your clients insist that a mail
      Message 2 of 15 , Jul 15, 2013
        * Ben Johnson <ben@...>:
        > Hello,
        >
        > We host mail services for a few dozen domains. We will eventually
        > require TLS for all client connections.
        >
        > I have reviewed what seems to be the most comprehensive thread on this
        > subject (
        > http://postfix.1071664.n5.nabble.com/TLS-SNI-support-td25552.html ) and,
        > in light of that information, am trying to determine the best course of
        > action.
        >
        > In essence, our clients wish to use their own SSL certificates for their
        > SMTP connections. Given that there are no plans to implement SNI in
        > Postfix (it seems not to be sufficiently useful to justify the work
        > involved, which I understand), I am left wondering what the alternative
        > might be.
        >
        > Our clients will not accept the position, "You just have to ignore the
        > 'domain mistmatch' warning and accept the certificate permanently when
        > you connect to the mail server." And I don't blame them.
        >
        > Also, our clients don't want to create DNS records that contain our
        > hostname or IP address. 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. 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.

        In absence of SNI either the MX of all domains point to one MX with a valid
        cert or you bring up an instance per domain.

        If your clients insist that a mail server is only professional if the TLS
        session has their domain name written on it, then give them what they want at
        the price it costs to implement it.

        Those are the choices and don't mean to start a flame war.

        p@rick



        --
        [*] sys4 AG

        http://sys4.de, +49 (89) 30 90 46 64
        Franziskanerstraße 15, 81669 München

        Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
        Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
        Aufsichtsratsvorsitzender: Florian Kirstein
      • Viktor Dukhovni
        ... Are these submission clients? What does the above mean? ... Why are they each using a different name for the same submission service? ... There is
        Message 3 of 15 , Jul 15, 2013
          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?

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

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

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

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

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

          --
          Viktor.
        • Wietse Venema
          ... You are creating massive confusion because you fail to explain a) whether you re talking about MUA service or MTA service, and b) what name is
          Message 4 of 15 , Jul 15, 2013
            Ben Johnson:
            > Hello,
            >
            > We host mail services for a few dozen domains. We will eventually
            > require TLS for all client connections.
            >
            > I have reviewed what seems to be the most comprehensive thread on this
            > subject (
            > http://postfix.1071664.n5.nabble.com/TLS-SNI-support-td25552.html ) and,
            > in light of that information, am trying to determine the best course of
            > action.
            >
            > In essence, our clients wish to use their own SSL certificates for their
            > SMTP connections. Given that there are no plans to implement SNI in
            > Postfix (it seems not to be sufficiently useful to justify the work
            > involved, which I understand), I am left wondering what the alternative
            > might be.
            >
            > Our clients will not accept the position, "You just have to ignore the
            > 'domain mistmatch' warning and accept the certificate permanently when
            > you connect to the mail server." And I don't blame them.

            You are creating massive confusion because you fail to explain

            a) whether you're talking about MUA service or MTA service, and

            b) what name is "mismatching" with your SMTP server name, and

            c) why the customer is using that name.

            Wietse
          • Jeffrey 'jf' Lim
            ... surely even using SNI would not help you in this regard? (rDNS lookup) ... I would look into the possibility of using an SNI proxy. -jf -- He who settles
            Message 5 of 15 , Jul 15, 2013
              On Tue, Jul 16, 2013 at 12:47 AM, Ben Johnson <ben@...> wrote:
              > Hello,
              >
              > We host mail services for a few dozen domains. We will eventually
              > require TLS for all client connections.
              >
              > I have reviewed what seems to be the most comprehensive thread on this
              > subject (
              > http://postfix.1071664.n5.nabble.com/TLS-SNI-support-td25552.html ) and,
              > in light of that information, am trying to determine the best course of
              > action.
              >
              > In essence, our clients wish to use their own SSL certificates for their
              > SMTP connections. Given that there are no plans to implement SNI in
              > Postfix (it seems not to be sufficiently useful to justify the work
              > involved, which I understand), I am left wondering what the alternative
              > might be.
              >
              > Our clients will not accept the position, "You just have to ignore the
              > 'domain mistmatch' warning and accept the certificate permanently when
              > you connect to the mail server." And I don't blame them.
              >
              > Also, our clients don't want to create DNS records that contain our
              > hostname or IP address. 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. 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.
              >
              > <snip>
              >
              > 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.
              >
              > 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. Some of our clients have stated that they do
              > 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").
              >

              surely even using SNI would not help you in this regard? (rDNS lookup)


              > 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).
              >
              > We have considered using SubjectAlternativeNames, but we would have to
              > change our SSL work-flow considerably and spend a lot of money with our
              > "trusted" friends in the SSL CA business.
              >
              > Have I missed anything fundamental? What are others doing to address
              > similar client demands?
              >

              I would look into the possibility of using an SNI proxy.

              -jf

              --
              He who settles on the idea of the intelligent man as a static entity
              only shows himself to be a fool.

              "Every nonfree program has a lord, a master --
              and if you use the program, he is your master."
              --Richard Stallman
            • Ben Johnson
              ... Bringing-up a Postfix instance per domain would require unique ports (or a dedicated IP address) for each instance, correct? Seems like a maintenance
              Message 6 of 15 , Jul 15, 2013
                On 7/15/2013 1:03 PM, Patrick Ben Koetter wrote:
                > In absence of SNI either the MX of all domains point to one MX with a valid
                > cert or you bring up an instance per domain.
                >

                Bringing-up a Postfix instance per domain would require unique ports (or
                a dedicated IP address) for each instance, correct? Seems like a
                maintenance nightmare.

                > If your clients insist that a mail server is only professional if the TLS
                > session has their domain name written on it, then give them what they want at
                > the price it costs to implement it.
                >

                Your position is perfectly reasonable, and is more or less the position
                that I've taken on the matter. I just wanted to be sure that there isn't
                some panacea that I had overlooked.

                In order to give our clients what they want, what are our choices? To
                use a SAN certificate that includes each client's domain name?

                The most obvious problem with this seems to be that this would leak our
                "client list" to the public. That is, it would be trivial to inspect the
                certificate and discern the companies for which we host email services.

                The second problem is adding new domains to the SAN field as new clients
                come online. Presumably, this requires having the certificate re-issued.
                Is anyone else using this approach, and if so, does the CA charge you
                for each re-issue? Or are you able to add new domains at a whim without
                incurring additional costs?

                > Those are the choices and don't mean to start a flame war.
                >

                I appreciate the frankness of your reply; I was looking for a succinct
                response, and you provided it.

                As final point of note, I realize that it is impossible to avoid having
                IP addresses that our company controls present in our clients' DNS
                records, unless we issue unique IP addresses to each client. (I had made
                a few conflicting statements in my initial post.)

                Thank you!

                -Ben
              • Ben Johnson
                (Viktor, I m going to reply to Wietse first, just because his questions are fewer and I am hoping to clarify the points of confusion before others reply.) ...
                Message 7 of 15 , Jul 15, 2013
                  (Viktor, I'm going to reply to Wietse first, just because his questions
                  are fewer and I am hoping to clarify the points of confusion before
                  others reply.)

                  On 7/15/2013 1:24 PM, Wietse Venema wrote:
                  > Ben Johnson:
                  >> Hello,
                  >>
                  >> We host mail services for a few dozen domains. We will eventually
                  >> require TLS for all client connections.
                  >>
                  >> I have reviewed what seems to be the most comprehensive thread on this
                  >> subject (
                  >> http://postfix.1071664.n5.nabble.com/TLS-SNI-support-td25552.html ) and,
                  >> in light of that information, am trying to determine the best course of
                  >> action.
                  >>
                  >> In essence, our clients wish to use their own SSL certificates for their
                  >> SMTP connections. Given that there are no plans to implement SNI in
                  >> Postfix (it seems not to be sufficiently useful to justify the work
                  >> involved, which I understand), I am left wondering what the alternative
                  >> might be.
                  >>
                  >> Our clients will not accept the position, "You just have to ignore the
                  >> 'domain mistmatch' warning and accept the certificate permanently when
                  >> you connect to the mail server." And I don't blame them.
                  >
                  > You are creating massive confusion because you fail to explain
                  >
                  > a) whether you're talking about MUA service or MTA service, and
                  >

                  The "domain mismatch" occurs in the MUA (e.g., Thunderbird, Apple Mail,
                  etc.).

                  > b) what name is "mismatching" with your SMTP server name, and
                  >

                  Some of our clients insist that they access the the MTA that handles
                  their mail, which resides on one of our servers, via their own domain
                  names. So, these clients are using smtp.client.com instead of
                  smtp.provider.com. Whether or not this is a "necessary" or "a good idea"
                  is, unfortunately, largely irrelevant. I have tried to convince clients
                  that they should be connecting to the submission service via *our*
                  domain name, and not their own domain name, but have faced nothing but
                  resistance.

                  > c) why the customer is using that name.
                  >

                  Because the customer wants to "control" his own SSL certificate,
                  including its renewal, re-issuance, and revocation. This does not seem
                  like an entirely unreasonable request, to be fair. (I do realize that
                  this is a "false sense of security", given that the client must relay
                  all certificate changes through us, since we control the MTA.)

                  > Wietse
                  >

                  I really appreciate your time, Wietse. Thanks for the reply. Let me know
                  if anything else is unclear.

                  -Ben
                • Ben Johnson
                  ... 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
                  Message 8 of 15 , Jul 15, 2013
                    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
                  • Wietse Venema
                    ... It s entirely reasonable if they want to be able to change email provider without having to update all their clients. Unfortunately there are not a lot of
                    Message 9 of 15 , Jul 15, 2013
                      Ben Johnson:
                      > 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.

                      It's entirely reasonable if they want to be able to change email
                      provider without having to update all their clients.

                      Unfortunately there are not a lot of development cycles for adding
                      a decent SNI implementation to Postfix.

                      Wietse
                    • Jeffrey 'jf' Lim
                      ... their ... What about using an SNI proxy? Would u have any to recommend? -jf
                      Message 10 of 15 , Jul 15, 2013

                        On 16 Jul 2013 03:15, "Wietse Venema" <wietse@...> wrote:

                        >
                        > Ben Johnson:
                        > > 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.
                        >
                        > It's entirely reasonable if they want to be able to change email
                        > provider without having to update all their clients.
                        >
                        > Unfortunately there are not a lot of development cycles for adding
                        > a decent SNI implementation to Postfix.
                        >

                        What about using an SNI proxy? Would u have any to recommend?

                        -jf

                      • Ben Johnson
                        ... This is the strongest argument that I ve seen for adding SNI support to Postfix. I hadn t even considered this. Maybe this is the basis for our customers
                        Message 11 of 15 , Jul 15, 2013
                          On 7/15/2013 3:14 PM, Wietse Venema wrote:
                          > Ben Johnson:
                          >> 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.
                          >
                          > It's entirely reasonable if they want to be able to change email
                          > provider without having to update all their clients.
                          >

                          This is the strongest argument that I've seen for adding SNI support to
                          Postfix. I hadn't even considered this. Maybe this is the basis for our
                          customers' respective positions; I wish they had made it clearer to
                          begin with.

                          > Unfortunately there are not a lot of development cycles for adding
                          > a decent SNI implementation to Postfix.
                          >
                          > Wietse
                          >

                          I can't even imagine the complexities; I understand.

                          In the meantime, I am all ears, regarding jf's question about SNI
                          proxying via, for example, nginx. If that subject is best addressed to
                          the nginx mailing list, I am happy to take the discussion to the
                          appropriate list.

                          Thanks again,

                          -Ben
                        • Wietse Venema
                          ... According to a thread in March 2013 they did not support SNI in the MAIL feature.
                          Message 12 of 15 , Jul 15, 2013
                            Ben Johnson:
                            > In the meantime, I am all ears, regarding jf's question about SNI
                            > proxying via, for example, nginx. If that subject is best addressed to
                            > the nginx mailing list, I am happy to take the discussion to the
                            > appropriate list.

                            According to a thread in March 2013 they did not support SNI in the
                            MAIL feature.

                            http://list-archives.org/2013/03/29/nginx-nginx-org/mail-proxy-with-sni/f/1433768745

                            Wietse
                          • Viktor Dukhovni
                            ... There s a lot more to SNI support than having a server that can context-switch between multiple certificates. You need a provisioning system that allows
                            Message 13 of 15 , Jul 15, 2013
                              On Mon, Jul 15, 2013 at 03:38:31PM -0400, Ben Johnson wrote:

                              > > It's entirely reasonable if they want to be able to change email
                              > > provider without having to update all their clients.
                              >
                              > This is the strongest argument that I've seen for adding SNI support to
                              > Postfix. I hadn't even considered this. Maybe this is the basis for our
                              > customers' respective positions; I wish they had made it clearer to
                              > begin with.

                              There's a lot more to SNI support than having a server that can
                              context-switch between multiple certificates. You need a provisioning
                              system that allows clients to upload private keys and matching
                              certificates on a self-service basis via suitably authorized
                              administrator accounts.

                              You need to send the administrators reminders about iminent
                              certificate expiration, and alert your staff if they don't respond
                              promptly, so they ultimately get phone calls when they don't act
                              in a timely manner.

                              The whole thing is a major PITA for very little gain.

                              > > Unfortunately there are not a lot of development cycles for adding
                              > > a decent SNI implementation to Postfix.

                              I have no time for this.

                              --
                              Viktor.
                            • Stan Hoeppner
                              ... And this is precisely why an entire VPS industry has sprouted over the past few years. As someone stated down thread, give your customers what they want
                              Message 14 of 15 , Jul 15, 2013
                                On 7/15/2013 3:35 PM, Viktor Dukhovni wrote:

                                >>> Unfortunately there are not a lot of development cycles for adding
                                >>> a decent SNI implementation to Postfix.
                                >
                                > I have no time for this.

                                And this is precisely why an entire VPS industry has sprouted over the
                                past few years. As someone stated down thread, give your customers what
                                they want and charge them accordingly. This is trivially easy to do
                                with your choice of hypervisor with memory consolidation (same page
                                merging) and a guest OS template. If your pool of IPv4 addresses is
                                limited charge them extra for that. If they're exhausted, well, you can
                                go IPv6 only but that really has downsides.

                                Here's an even better idea. Do what everyone else in your shoes does:
                                partner with a VPS provider and farm the bulk of this out. There are
                                tons of small companies that do exactly this. They buy X number of VPS
                                instances each with an IP address from a provider and rebrand them. The
                                VPS provider does all the heavy lifting WRT provisioning. You would
                                simply do the customization for your individual customers, i.e. DNS,
                                hostname, domain name, certificate, etc. A basic VPS for this kind of
                                thing can normally be had for well less than $10/month. The really
                                stripped down VPS services I see offered are $4.95/month. All prices
                                USD. If you already have a mailbox (IMAP/POP) server that currently
                                handles MX duty for all these customers, moving MX to these VPS
                                instances and relaying the mail to your mailbox server is easy as well.

                                --
                                Stan
                              • Peter
                                ... Probably the best option is to go old tech here. Get a separate IP for each hostname that a client wants to connect to and set up separate listeners in
                                Message 15 of 15 , Jul 15, 2013
                                  On 07/16/2013 05:30 AM, Ben Johnson wrote:
                                  >> If your clients insist that a mail server is only professional if the TLS
                                  >> session has their domain name written on it, then give them what they want at
                                  >> the price it costs to implement it.
                                  >
                                  > Your position is perfectly reasonable, and is more or less the position
                                  > that I've taken on the matter. I just wanted to be sure that there isn't
                                  > some panacea that I had overlooked.
                                  >
                                  > In order to give our clients what they want, what are our choices?

                                  Probably the best option is to go old tech here. Get a separate IP for
                                  each hostname that a client wants to connect to and set up separate
                                  listeners in master.cf for each of those IPs with the appropriate TLS
                                  options. Then let the clients buy their own cert and provide it to you
                                  to use on the server. Up to you to come up with the additional pricing
                                  for all of this. The extra dedicated IP is the first and most obvious
                                  cost, the rest is administrative.

                                  Keep in mind that you'll have to configure dovecot (or whatever you use
                                  for IMAP/POP3) to listen on these other IPs and use those
                                  customer-supplied certs as well.

                                  Personally I would ramp up the extra fee even more to account for the,
                                  "I don't want to do this really stupid unnecessary vain thing" reason.
                                  I would make sure the client knows that they are just spending extra
                                  money to satisfy their own vanity and if they still want to go ahead
                                  then do it for them.


                                  Peter
                                Your message has been successfully submitted and would be delivered to recipients shortly.