we wrote a c# app to handle creating all the required ssl cents and bindings for all our domains, but the auto discovery stuff in SM needs to be more flexible in allowing us to specify an override host name per protocol. 

Configuring an SRV record rather than an 'autodiscover' CNAME seems to yield better results, albeit Outlook complains once due to a redirect but it causes less alarm to users than the certificate error. 

Certificate technology is pretty generic, it appears that you do not have the right certificate configuration.   I don't see any way that this is a SmarterMail problem.

Basic certificate logic is that the DNS name used to make a connection must match a name on the certificate presented by the server.   This match proves that you are connected to the intended server, and that your session was not hijacked in transit.

Consequently, autodiscover.yourdomain needs to be a SAN on your server certificate.   If you create a unique host name for each client, you need autodiscover.clientdomain and actualhost.clientdomain included on the certificate.  As far as I know, you can have an essentially unlimited number of Server Alternate Name (SAN) entries on a certificate (for a price).   I have certainly seen certificates with a very long list of entries.   If you are using the freebie Let's Encrypt certificate, your options may be more limited.  

You can also use wildcard certificates to make the host portion unimportant.  As far as I know, a wildcard can only be the primary entry, not a SAN, so you can only have one wildcard domain on a certificate.

We only have a few domains, but I would prefer to have everyone using a single domain for configuration.  Is that even possible?

For example:

DomainA

DomainB

DomainC

DomainD

Everyone can use www.domainA.com for webmail. 

Everyone can manually configure IMAP etc to use mail.domainA.com.  

So why can't autodiscover do the same thing for IMAP?  If it can be done, can someone please explain it?

Thank you!

mail.domainA.com is a different name than www.domaina.com, so both names need to be on the certificate.  But you do not need to use two different names when only one server is involved.    The DNS name is used to generate an IP address, and the name-to-ip process is the same regardless of the protocol being used.  But if you have already configured users with multiple host names, it may be easier to pay for a certificate with extra SANS than to annoy your users.

As an aside, I would avoid using the www prefix for the web interface, as most domains want to use that name as a public-facing home page for the domain.  But you may have just been using that as an example.

If you have an incoming gateway (a server sitting in front of SmarterMail), then you will need a unique name for each server and a certificate for each host name (or a wildcard certificate).   For example, mx.domaina.com could be your incoming gateway server, and webmail.domaina.com could be your SmarterMail server.  But it sounds like you have a single-server configuration.

In a service provide scenario the goal is to not have to manage multiple certificates or SAN certificates but to have a mechanism that autodiscovers using the correct/underlying server name. SRV records seem like the easiest way of achieving this as the server name to discover against can be specified but due to the implementation within Outlook it appears this will flag a 'redirect' which disrupts the automated nature of discovery.

Hey all,

Here are a couple of links you may find helpful on how Outlook performs it's autodiscover lookups.

https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover 

Right now in SmarterMail, we have web request handlers that listen for autodiscover requests regardless of what domain name they come from.  So if your SmarterMail server is configured to receive requests from domainA.com and domainB.com, then we will handle autodiscover requests that have either domain.  I think this is part of the problem that you are reporting because in Outlook you will setup a profile for user@domainA.com and Outlook will use the domain of user@domainA.com to start autodiscover lookups.  Since our handlers are not restrictive, we'll return an autodiscover response with domainA.com for that user.

If we wanted to limit these requests to the main SmarterMail domain, or at least have it configurable, then that would require changes on our part.  I think if you properly have your SRV records setup and SmarterMail only honored autodiscover requests based on those records, then this should point us in the right direction that you are asking for.

Since we don't have support for this today I'll have to mark it as a feature request that will probably span across all protocols with autodiscover.

Our biggest request is to allow overriding of each protocols hostname. Since MAPI, EWS and EAS can all easily use mail.customerdomain and protocols that cannot really have per host certificates like SMTP, POP, IMAP, XMPP, we use mail.ourhostname for those.

I know it's on the board, but it would be a big help for our environment.

I second the above comment from @echoDreamz

My testing today shows that having just the SRV record works. 

The problem with having both the A or CNAME for autodiscover.customerdomain.com AND an SRV record pointing to mail.yourserver.com, is that the autodiscover.customerdomain.com takes priority over the SRV record.

Therefore requires that autodiscover.customerdomain.com matches the SSL certificate. In other words, you would need to add autodiscover.customerdomain.com for each of your customers on the certificate. They do have multi-domain certificates available for this.

You can remove the A / CNAME for autodiscover.customerdomain.com and have just the SRV record only.

Per Nathan Y's reply above, Outlook only nags you the first time you setup an email account in it.