I work in tech support for a company that has an email inbox integration. Users can input IMAP and SMTP host names and ports and we will attempt to open a connection with those ports and host names so we can allow them to send emails from their email addresses via our software. Oftentimes, when customers try to connect via IMAP, we see "Unauthorized" errors, where customer' email servers reject our connection due to the information entered not being accepted.

Customers usually do not know why their servers are not allowing us to connect, and ask me for further insight. To troubleshoot why a connection is being dropped, I usually use

nmap imap.theirserver.com

to take a look at the unfiltered ports on their server. Other commands I use are:

openssl s_client -connect imap.theirserver.com:port
openssl s_client -crlf -showcerts -starttls imap(or smtp) -connect imap.theirserver.com:port  (if the port is unencrypted)

I occasionally use dig to see information about their domain/DNS. These commands give me information about whether their ports are properly encrypted (if they have null ciphers, if ports 143/587/25 are running starttls when they should, if the ports are unfiltered, if the IMAP and SMTP certificates match, and if our connection is outright rejected.) That's about it.

I know information I can find here is limited because, for security reasons, a server that isn't mine isn't going to openly tell us why the connection was rejected. But could anyone help me build my troubleshooting strategies/tactics for this to help the customers connect their inboxes? Are there other commands I can use to determine why a connection may be rejected, or that can help me determine if they have a firewall/other security measure in place, or if there is a proxy, or if the ports simply aren't open? (or if anyone knows of any other reasons why a connection may fail, that would be extremely helpful!)

Ex: I often see something along the lines of

140735820493760:error:0200203C:system library:connect:Operation timed 
out:crypto/bio/b_sock2.c:108: 140735820493760:error:2008A067:BIO 
routines:BIO_connect:connect error:crypto/bio/b_sock2.c:109:  

and I am not sure what the implications of a timeout are in us being able to connect to their server.

I don't have a technical background before this job, so I apologize if any of these questions are obvious to someone with more computer science knowledge, or if any of my terminology is off! And if any of this is too vague, I'm happy to provide more details. Any educational resources on this would also be extremely helpful, since I have had a lot of difficulty finding them. Thank you!

  • 2
    I believe you have already quite an extensive tooling and I applaud your skills and your learning, with a very well written question! I would just suggest to try a command line imap client that you can put in verbose mode to have more debug. This article on email autodiscovery might be useful: web.archive.org/web/20120828065248/http://moens.ch/2012/05/31/… – Patrick Mevzek Dec 14 '17 at 16:13
  • 1
    Scanning servers using nmap is probably not the best idea... it's a good way to get your IP address blacklisted or dropped at the server's firewall. – RubberStamp Dec 14 '17 at 16:58
  • 1
    You could probably use nmap (while I agree with @RubberStamp) but restricting yourself to known ports used for IMAP(S)/SMTP(S), and not touching the others. – Patrick Mevzek Dec 14 '17 at 21:26
  • 1
    MXToolbox should provide you with most of the information you require. You can do port scans, look up DNS records, and verify most configuration parameters for email servers. The use of a web tool offloads the reputation damage risk of your domain or IP address. – RubberStamp Dec 14 '17 at 21:32
  • 1
    Yes you could use mutt I guess or even going lower levels like fetchmail that handles multiprotocol and does a log of debugging as needed (make sure not to delete emails from the server when testing! see its configuration file). For SMTP smtp-cli seems useful (no direct experience with it). offlineimap could do too, imapproxy probably. As for the second part, it shows that you can, sometimes, discover a provider email setup by just passively using HTTPS/DNS data without active probes. – Patrick Mevzek Dec 20 '17 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.