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
