Customers and partners may encounter issues when sending emails from Sage CRM. Depending on the availability of logging within the customer's mail server software, it may be difficult to determine the cause of these issues.
This article describes how to test a customer's SMTP connection using Telnet. This test may be used to confirm whether emails can be sent using SMTP from the Sage CRM Server. It is especially useful where other complicating factors are involves, such as the use of an SSL proxy.
Preparing for the test:
On its most basic level, this test can be carried out using the following items:
- A Telnet client
- The SMTP server name and port
- The CRM SMTP username and password
- The email address of the user who you want to send the email as
- One or more recipient email addresses. At least one of these should be outside the organisation
If you are troubleshooting a specific set of reproduction steps, then you should use the same details (recipient email address, sender email address etc) as were being used when the issue was reported.
1: Installing Telnet:
By default, Telnet is not installed on current client or server versions of Windows. You can check whether or not Telnet is installed by opening a command line window (Start | Run | enter cmd | Click OK), typing telnet and hitting the Return key. This should return something similar to the following:
Once you have confirmed that Telnet is installed, you can exit from it by typing quit, then hitting the Return key.
Typically, the Telnet installer is packaged with Windows. If you need to install it, you can use one other following methods:
- On client versions of Windows, go to Control Panel | Programs and Features | Turn Windows features on or off. The Telnet client can be installed by ticking the option in the list, then hitting OK.
- On server versions of Windows, the Telnet client can be added to the server as a Windows feature.
More details regarding how to install the Telnet client are available here:
2: SMTP server name and port
If you are testing a live instance of CRM, then you can find these details can be found in CRM by navigating to Administration | E-mail and Documents | E-mail Configuration.
If you have access to the database, but not a CRM login, then you will find the details by checking the Custom_Sysparams table for the SMTPServer and SMTPPort entries. When checking these details, you should confirm whether a customer is using SSL tunneling software (such as stunnel) or not. If so, you will typically find that these details have been set to a machine other than the mail server. In many cases the SMTP server name will point to the CRM server itself; the expectation here is that the tunneling proxy will forward the all requests to the mail server.
3: CRM SMTP username and password
The SMTP username being used is also available in CRM, on the Administration | E-mail and Documents | E-mail Configuration screen. The username is stored under the SMTPUserName entry on the Custom_Sysparams table. If you do not know the SMTP password, then you should request it from either the customer or their IS administrator.
4: Sender email address
It is important that you use an email address for whom an issue has been reported. Ideally, this email address will be different from CRM's SMTP username. One common SMTP issue is caused by this account not having the "Send As" right, allowing it to send emails as other users on the system. This right is required, since CRM will always only send emails using a single username nad password.
5: Recipient email addresses
Indeally, you will use two email addresses, one inside and one outside the organisation. The reason for this is because test emails are often only sent to other mailboxes within the current organisation. Typically, mail servers (such as Microsoft Exchange) will not require authentication for emails sent within the organisation. Thus, by sending out two emails, you will be able to confirm whether a problem is potentially being caused by an authentication issue.
Sending a test email
1: Open a command line window.
2: Using Telnet, open a connection to your SMTP server. The syntax here is telnet <hostname> <port>.
On connecting you will be presented with some form of greeting screen. This may or may not include the name of the host you are connected to, as well as information about the mail server. It will differ depending on the mail server software in use, as well as its administrator's specific configuration.
4: Send the ehlo command to request a specific domain. The syntax for this is ehlo <domain name>. This returns a number of machine-readable attributes of the server. The server's hostname is always on the first line.
5: You will generally need to authenticate as a user in order to send an email outide of the current domain. In order to do this, send the AUTH LOGIN command. The mail server will respond with a Base64-encoded request for the username (VXNlcm5hbWU6). You are expected to provide a Base64-encoded username in response.
In this example, our username is email@example.com. This results in a Base64 encoding of Y3JtQHBhbm9wbHktdGVjaC5jb20=.
Once you have entered the username, the server will request the password, again as a Base64-encoded string (UGFzc3dvcmQ6). In response, you must provide the user's Base64-encoded password.
Once you have supplied the server with a correct username and password, you will be given some form of comfirmation that you are authenticated.
A free, safe, Base64 encoder is provided in knowledgebase article 492-17225.
6: Once you are authenticated, you can send an email. Enter MAIL FROM: <email address> to set a sender, then hit Return. Remember that you will generally want to test this using an email address other than the one used to authenticate.
Enter RCPT TO: <email address> to set a recipient, then hit Return.
Enter DATA then hit Return in order to write the mail body.
Generally, you will want to set a mail subject. You can do this by entering Subject: <your subject here>. If you do not set a subject, your mail may be identified as spam.
You can then freely write an email. You can terminate the email by hitting Return, entering a full stop, then hitting Return again. Once this is done, you should see that hte mail is queued for sending.
The entire process should look a little like this:
To disconnect from the SMTP server, enter the quit command.
There are a number of variations that you can use in order to troubleshoot issues. these can include (but are not limited to)
- Authenticating in as a different SMTP user, or not authenticating in at all.
- Setting the sender as being the same as the CRM SMTP user.
- Setting the recipient to be the same as the SMTP user.
Each of these may be used at different stages, depending on what kind of issue you may be facing.
Further to the above, you should be very careful when entering commands. SMTP does not contain a provision for correcting misspelled commands, so the Backspace key will not work.