autodiscover.xml || Invalid XML Request - Error: User does not exist.

Question asked by John C. Reid - 6/10/2021 at 10:51 AM

Unanswered

I really need to get autodiscover working. I have attempted this twice, and given up twice. Everything seems to be in place, but it just doesn't work. I think I am making progress though because I found something new I didn't see before.

First, what works. DNS is setup and everything seems to resolve ok. I have Certify the Web providing wildcard certs so anything coming in for a supported domain has a valid cert. The bindings are working in IIS as I can get to the login page using any of my host headers. The settings in SmarterMail are pretty default, at this point I am still only worried about IMAP, POP, and SMTP. I will license and add MAPI/EWS and EAS once I can get this working.

What I have found and I didn't find before is that when I went looking for the autodiscover.xml so I could see what it contained, I could not get to it. I started by going to https://autodiscover.mydomain.tld/autodiscover.xml because it is my understanding the webroot of the domain is where Outlook looks first. I got a 404 not found for that request. I then tried https://autodiscover.mydomain.tld/autodiscover/autodiscover.xml and this time I got a basic authentication dialog. Well, this is progress but it is also where I am stuck.

If I enter an invalid username and password combination the Basic Authentication dialog just resets and give me another try. Typically with basic auth you shoudl get 3-5 attempts and then a 401 error, but this seems to let me try indefinitely, which might be a security issue as it allows for automated brute force attempts at password guessing.

If I enter a valid username and password instead of getting the expected autodiscover.xml document, I get this:

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

John C. Reid / Technology Director
John@prime42.net / (530) 691-0042
1300 West Street, Suite 206, Redding, CA 96001

8 Replies

Reply to Thread

echoDreamz Replied

6/14/2021 at 9:06 AM

What version of SM are you running?

John C. Reid Replied

6/14/2021 at 9:12 AM

SmarterMail Enterprise 100.0.7817.31698 (May 27, 2021)

John C. Reid / Technology Director John@prime42.net / (530) 691-0042 1300 West Street, Suite 206, Redding, CA 96001

echoDreamz Replied

6/14/2021 at 11:05 AM

Same error here on our installation.

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

I tried using various app passwords for IMAP, EAS, EWS/MAPI. All resulted in the above error.

John C. Reid Replied

6/14/2021 at 11:12 AM

So I am assuming you have autodiscover working, and this just confirms that the behavior is normal? If so, I guess it is back to the drawing board for me on figuring out why it is not working for me.

John C. Reid / Technology Director John@prime42.net / (530) 691-0042 1300 West Street, Suite 206, Redding, CA 96001

J Lee Replied

6/14/2021 at 11:42 AM

This function stopped working for me in Feb, this was my workaround. You basically need an SSL on mail. for login and autodiscover. for Outlook Desktop.

The suggestion above is the supported solution. Outlook leverages an account discovery service (at Microsoft) to probe the account and server, and so requires the following criteria are met for best results:

1. https://mail.customer-domain.com should be reachable without security warnings from the client's PC on a browser.
2. https://autodiscover.customer-domain.com should be reachable without security warnings from the client's PC on a browser.
3. SRV record should be reachable in DNS from client PC and should reference
mail.customer-domain.com on port 443.

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

echoDreamz Replied

6/14/2021 at 12:01 PM

We've not heard of any issues with autodiscovery, but it is odd the call is failing. It may have something to do with calling directly via browser and not from an email client.

John C. Reid Replied

6/14/2021 at 12:04 PM

I wasn't this specific in the second paragraph of the OP, but all of this is in place an working fine.

1. https://mail.customer-domain.com should be reachable without security warnings from the client's PC on a browser.
2. https://autodiscover.customer-domain.com should be reachable without security warnings from the client's PC on a browser.
3. SRV record should be reachable in DNS from client PC and should reference
mail.customer-domain.com on port 443.

You can visit the https:// versions of points 1 and 2 and see the valid certificate upon successful page load. Also, I checked the certs using nmap and they show as valid. For point 3 I did a DNS query of the the SRV record for _autodiscover._tcp.customer-domain.com and it returns "0 0 443 autodiscover.customer-domain.com"

Are you saying there should also be a SRV Record for mail.customer-domain.com?

John C. Reid / Technology Director John@prime42.net / (530) 691-0042 1300 West Street, Suite 206, Redding, CA 96001

Douglas Foster Replied

7/5/2021 at 6:11 PM

Please review the results of my AutoDiscover research, which is at the end of this post

https://portal.smartertools.com/community/a93872/streamlining-autodiscover.aspx

It explains how you can use registry settings to indicate which of approximately seven different connection methods are used. If you do nothing, it will attempt all of them in sequence.

You must use HTTPS and a valid certificate, so if you are trying to do this without a certificate, that is your problem.

To avoid certificate errors during connection setup, have your autodiscover record point to a CNAME which matches your certificate, rather than to an IP address. Certificates never validate to an IP address. Certificate errors should not prevent the connection from completing, but they are another obstacle for your users and undesirable. We do not want users trained to ignore certificate errors.

If you use the flags in my document to disable Office365 searches, you MAY be able to avoid publishing your network to Microsoft. I got mine working with autodiscover published, and now I am afraid to take it back out, although I would very much like to do so. If you succeed without publishing Autodiscover to the Internet, please let us know. At minimum, the flags will certainly speed up the autodiscover process, which is a big win.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text