SharePoint is a complex platform, so working with SharePoint often requires working with an array of non-SharePoint related software products, such as Simple Mail Transfer Protocol (SMTP). SharePoint leverages these technologies to add features and increase functionality- in this case SMTP for email delivery.
Sometimes SMTP can be a ‘pain point’ for SharePoint Administrators since it’s not directly related to SharePoint. But when you encounter email delivery problems in SharePoint, resolving the problem frequently involves SMTP troubleshooting. So where does one start in attempting to diagnose an SMTP error or a possible SMTP problem? On many occasions I’ve used Telnet for this purpose, and it has saved me a ton of time and effort. I will discuss the steps in detail in hopes that it can help someone else in similar circumstances.
We will essentially be using a well-known method of using Telnet to send an email, but utilizing it specifically to help diagnose SharePoint SMTP issues and uncover the root cause of any problems. Telnet is one of the best and most reliable tools for troubleshooting email problems in SharePoint because it saves time and narrows down the possible places that a problem may be occurring.
For this process, we will need four things:
- The public IP address for the mail server
- A valid email address that SMTP should be able to relay to (in this case this will be an email-enabled Library in SharePoint 2010)
- An external mail account, such as a Hotmail account
- Telnet client enabled on our local workstation
When I first started working with SharePoint, I would frequently encounter problems with email-enabled Lists or Libraries. The troubleshooting process would typically involve me sending an email to said List or Library and waiting for a Non-Delivery Report (NDR) when it didn’t work. This takes forever though, as your email will attempt to send repeatedly until it “times out”. As a result, this could take days to accurately troubleshoot. Using Telnet, we can get these same NDR codes, but have them returned immediately.
So for this walk-through, I have found our four requirements in advance:
- Public IP for the mail server: 220.127.116.11
- SMTP relay mail address: [email protected]
- External email address: [email protected] (please don’t spam me)
- Telnet enabled on my workstation
First, we’ll use Telnet to gain access into the default SMTP port for our mail server. If successful, this will tell us two things:
- That SMTP is listening on the port
- The port is opened in the firewall
The command looks like this below:
If you are unable to connect, then you need to check both #1 and #2 above before moving any further. We are assuming that neither of these problems exists in this case.
Once connected, you can essentially “craft” an email for the mail server. This is done by the following commands, (keep in mind that you cannot Backspace in this session, so any mistypes will require you to re-type the entire line):
You must first recognize the server by typing ‘ehlo’
Which will return the following:
Now that the formalities are taken care of, we can start our diagnostics.
First we will pick the email we are sending from – this is our external mail account that should be able to send emails to this server, (in our case [email protected]), and use this in our session. See the following screen shot for the syntax, and remember to attempt to avoid typos.
Using mail from:[email protected] tells the session what email address this email is “coming from” and is, in fact, mimicking what would happen if you actually send from this email address.
You can encounter problems in this step depending on your configuration. If you are returned an error, then this is where your troubleshooting starts and you should skip the next step and begin troubleshooting based on the code returned and the NDR list, (this can be found below just keep reading).
Now to tell the server where the mail is going, (in this case this is our email enabled List or Library):
Using rcpt to:[email protected] tells our mail server where this email will be sent to.
This step is typically where you will find any problems that are present. If this operation is allowed, then the 250 response above is returned. So, if a 250 response is returned when NO problems are detected, what is returned when problems ARE detected? This is where the diagnostics come in. Here is an example:
Instead of using my List or Libraries address, we will attempt to relay to another server I know it will definitely NOT have permissions to relay to, [email protected].
So we perform the same as everything listed above, except for the rcpt to, which we will use “rctp to:[email protected]” and are returned an error as seen below:
As you can see, not only are we told ‘Unable to Relay’, but the command returns an error (code 5.7.1) as well.
This error code will actually correlate to the same NDR code you would have received had you sent this email the “normal” way. A list I commonly use to correlate these codes can be found here:
In the reference, we find that error 5.7.1 indicates a permissions problem. The reference guide also offers some possibilities into where the problem may exist. This method can be used to troubleshoot virtually any SMTP error. And you’ll have a good starting point to narrow down the potential problem almost immediately. In this case, I would need to check the SMTP Relay permissions and would see that the mail server indeed does not have permissions to relay to the [email protected] email address.
*A side note is that I realize that 5.5.4 is not on the list of NDR response codes. This error is usually the result of a typo.
Now for fun you can use Data and type an actual email, but that tends to enter the realm of mischief more that goes way beyond diagnosing errors.
Happy troubleshooting! Have questions? Please leave a comment below.