Autodiscover Setup and Format

Question asked by Montague WebWorks - 2/22/2021 at 10:50 AM

Answered

We mainly host websites, and host email for about 1/2 of those customers. For them, we have the following set up in their DNS...

autodiscover IN A [my-ip]
autoconfig IN A [my-ip]
_autodiscover._tcp SRV 0 0 443 mail.[my-SM-domain].com.

... all of which points to my SM server.

Question 1: Setting up the hostname for each domain is relatively new (we've been using SM since v8) and so there's a lot of domains to Manage and enter in the hostname for. Is there an easy way to update them all to our main email server hostname (ie; mail.[my-SM-domain].com, not mail.[their-domain].com). At the very least, it would be great to include the hostname in the [...] Export Domains so I can see what each domain is configured for so I'd know who to update.

-----

Some web customers have their email domains hosted elsewhere (ie; G-Suite or Outlook-365) and for those clients we can't do much. However, there is one client who keeps showing up in our web logs:

https://[their-domain].com:443/autodiscover/autodiscover.xml

For those customers, I'd like to set up an autodiscover.xml file in that folder.

Question 2: What are my best options for this? There are many email hosting companies out there, and although it appears I can redirect the request to the appropriate server within the autodiscover.xml syntax ... it could turn into a configuration nightmare on my end. Not sure it's even worth the effort, unless I just focus on the main two, mentioned above.

https://www.howto-outlook.com/howto/autodiscoverconfiguration.htm

In either case, I'd like to have a backup autodiscover file set up for each domain we host email, just in case their email client comes to the webserver instead of our email server (despite the DNS having the proper subs set up, see above). What's the best format / syntax for this file?

In an attempt to see the file on my own SM server, I went to this url...

https://autodiscover.[my-SM-domain].com/autodiscover/autodiscover.xml

... and, after entering in my email address and password, received this error:

Invalid XML Request - Error: User does not exist.

Server stack trace: 
   at MailService.Remoting.Mail.GetUserStatic(String email)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at SmarterMail.RemoteInterface.IMail.GetUser(String sessionStr, String emailAddress)
   at SmarterMail.Logic.Remoting.RemoteMail.GetUser(String sessionStr, String email)
   at SmarterMail.Web.SyncProtocols.AutoDiscover.AutoDiscoverProcessor.DoWork(Object workItemState),

So, that didn't work.

Looking for anyone's sage thoughts.

Thanks,

Mik

Mik MullerMontague WebWorks

8 Replies

Reply to Thread

Montague WebWorks Replied

2/22/2021 at 10:50 AM

BTW, we only offer IMAP and POP

Mik MullerMontague WebWorks

Douglas Foster Replied

2/22/2021 at 5:57 PM

Marked As Answer

Use CNAME

Your autodiscover records should use a CNAME rather than an A record. Otherwise the client will attempt to connect to https://ipaddress and will see a certificate error. So one option is

autodiscover.,clientdomain.com CNAME mail.hostingdomain.com, but you can certainly resolve it to mail.clientdoimain.com and that will probably be your client preference., I assume you use automation to manage the complexity of many clients.

Split-mode clients

When using the Microsoft Remote Connectivity Analyzer, and closely examining the results, I learned that it checks first for a response at

domainname.com

before testing for

autodiscover.domainname.com

(If this tidbit is documented anywhere, I have never seen it.)

Since most organizations use a null host name for web traffic but not for mail traffic, you server will see autodiscover requests for your non-mail clients, but you should not respond. I guess you have an email domain configured for them or this would not even be a question. Whoever controls their DNS should publish a correct autodiscover record which points to their actual email service.

I hope I understood your question.

Montague WebWorks Replied

2/23/2021 at 9:58 AM

So, you're suggesting instead of doing this...

autodiscover IN A [my-ip]
autoconfig IN A [my-ip]

... I should do this, instead...

autodiscover CNAME mail.[my-SM-domain].com.
autoconfig CNAME mail.[my-SM-domain].com.

I only have email domains configured in SM for clients I host email for. If they have email elsewhere, I ask for the appropriate MX records for their zone file, ie;

@ MX 30 ASPMX3.GOOGLEMAIL.com.
@ MX 30 ASPMX4.GOOGLEMAIL.com.
@ MX 30 ASPMX5.GOOGLEMAIL.com.
@ MX 10 ASPMX.L.GOOGLE.com.
@ MX 20 ALT1.ASPMX.L.GOOGLE.com.
@ MX 20 ALT2.ASPMX.L.GOOGLE.com.
@ MX 30 ASPMX2.GOOGLEMAIL.com.

The customers who I receive autodiscover hits for are indeed all web clients who have email hosted elsewhere. These are the User Agents that hit us in the past hour for nine different clients...

ExchangeServicesClient/15.00.0913.015 
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Access 16.0.13628; Pro) 
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Excel 16.0.10371; Pro) 
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Excel 16.0.13628; Pro) 
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.13530; Pro) 
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.13628; Pro) 
Microsoft Office/16.0 (Windows NT 10.0; Microsoft PowerPoint 16.0.13628; Pro) 
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Word 16.0.10371; Pro) 
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Word 16.0.13127; Pro) 
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Word 16.0.13628; Pro)

Thanks!

Mik MullerMontague WebWorks

Douglas Foster Replied

2/23/2021 at 11:29 AM

Yes to the first question. The autodiscover result is used for an HTTPS connection, so if it returns an iP address, the user will get a certificate error. Because CNAME returns a host name, the HTTPS connection uses a host name and the certificate can be validated.

Whether you use a client-specific domain name or hosting service domain name does not matter, you just need to ensure that a certificate is compatible certificate is installed on each port.

I understand that SM allows you to configure a unique webmail hostname for each domain, but I don't see how you configure a unique certificate for each client on each port unless the domain name is constant. I think you can use clientname.hostingservice.com as the site name and *.hostingservice.com as the certificate. I don't see a viable way to use mail.clientdomain.com as the hostname. Someone else may be able to explain another option.

For autodiscover of non-email clients, you just ignore the incoming autodiscover requests that hit your website using "hostname.domain". Since your website cannot answer the request, it should be returing a normal error status that will cause the remote autodiscover process proceed to the next attempt based on autodiscover.hostname.domain.

Of course, if you manage DNS for the client, then they need to provide you with the information for their autodiscover A and SRV records for their mail service.

Montague WebWorks Replied

2/23/2021 at 12:05 PM

We use a single domain for email hosting for that very reason. One SSL to rule them all.

I'll update all zone files with the CNAME.

Ok, I'll ignore the autodiscover requests on my webserver.

Thanks, Douglas!

Mik MullerMontague WebWorks

Kyle Kerst Replied

2/23/2021 at 4:26 PM

Employee Post

Please note that leveraging CNAMEs to redirect mail.customer-domain.com to mail.my-domain.com will generate certificate warnings during MAPI account set up in Outlook, and in most cases will cause account set up to fail.

Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com

Douglas Foster Replied

2/24/2021 at 5:00 AM

Kyle raises an interesting concern. I have not tried cross-domain autodiscover.

The Microsoft Connectivity Analyzer says that is tests

https://domain/...

which will require a certificate for domain or *.domain

then it tries

https://autodiscover.domain/...

which will also require a certificate for domain or *.domain

If this is the whole story, then an A record would be preferable

My experience (mostly with Office 2010 and an internal server) has been that CNAME is preferable.

I scanned a few known domains and find a mix of A and CNAME, including some CNAME that seem to redirect to other domains.

Nothing in the test process explains how the SRV record is used. Perhaps to do cross-domain, the SRV record must be used and the autodiscover DNS record should be removed.

Please test and let us know if your testing clarifies the issue.

Montague WebWorks Replied

2/24/2021 at 9:47 AM

Hmmm... well, since I don't support MAPI, perhaps it's not an issue for me.

Kyle, which of the two do you suggest I use. I'm currently still using the A record method in my customers' DNS zone files, but could fairly easily switch to the CNAME method if that's better for POP and IMAP.

Please note the error I received when I tried to load the autodiscover page in my browser. Perhaps it happened because I was in a browser and not an email client. I don't know enough about this stuff.

This is what I have for MX in a typical zone file for a web customer I also host email for:

; MAIL records (export) --------------------------
@ IN MX 10 mail.my-domain.com.
@ IN MX 20 mail.back-domain.com.
@ IN TXT ("v=spf1 ip4:xxx.xxx.xxx.xxx ip4:yy.yy.yy.yy ip4:zz.zz.zz.zz  -all")
autodiscover IN A xxx.xxx.xxx.xxx
autoconfig IN A xxx.xxx.xxx.xxx
_autodiscover._tcp SRV 0 0 443 mail.my-domain.com.
dkimcert._domainKey	IN TXT ("v=DKIM1; k=rsa; p=MIGfMA0GCS[...]AQAB")

Mik MullerMontague WebWorks

Back to Community Threads

Please leave this box unchecked

8 Replies

Reply to Thread

Tags

Related Knowledge Base Articles