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

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

Expand Messages
  • 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 1 of 15 , Jul 15, 2013
    • 0 Attachment
      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 2 of 15 , Jul 15, 2013
      • 0 Attachment

        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 3 of 15 , Jul 15, 2013
        • 0 Attachment
          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 4 of 15 , Jul 15, 2013
          • 0 Attachment
            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 5 of 15 , Jul 15, 2013
            • 0 Attachment
              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 6 of 15 , Jul 15, 2013
              • 0 Attachment
                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 7 of 15 , Jul 15, 2013
                • 0 Attachment
                  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.