As a software developer and/or someone who is involved in the support of software, it is often useful to prove to a client that the software is not at fault. This is doubly important if your application manages emails, given the business relevance email systems have in modern times.
As a developer who may have developed Microsoft Office based Applications in VBA, you may know that if Office get’s stuck waiting on a bit code to complete or some part of the application is taking considerable time to process something, it will appear to freeze. "DoEvents" and some sort of progress windows is always advised, but not always possible if the thing that is being processed is out-with your control.
An example of this would be if you have an Microsoft Office based Application that receives, files and controls emails. If there is a problem with a clients email server, or the pop3 is running very slow, a Microsoft Office based Application would appear to freeze as you cannot process the incoming email on a separate thread.
Other applications based on other languages would be less likely to freeze as the developer will likely have the opportunity to run such processes on a separate thread to the main application. As such the end user would most likely be completely unaware that slow connection or problem with their ISP existed. The developer would have the opportunity to cancel a process after a set timeout if it continued to fail to respond and report it to the user. Even so the client may still assume the blame is with the software rather than their service provider.
It therefore becomes essential to prove your case to a client.
One of the easiest and effective ways of proving your application is not at fault is to use a telnet client.
A telnet client is often overlooked as a tool, as people might assume it is only used to connect to a telnet service but it is very useful tool if you wish to check your email connectivity or even if you just want to see how many emails are waiting for you.
NOTE: Windows has always had it’s own telnet client built in, accessible via the command prompt. As of Windows Vista, it is now an optional component, that you must switch on (via the "Turn Windows Features On or Off" window in "Programs and Features", which is accessed via the control panel).
To run telnet simply open the command prompt on your system and type TELNET and press return.
You will then be in the telnet client. To connect to an email server you must use the OPEN command, ensuring you use the correct port number. The format of the command is: –
open mymail.myserver.com portnumber
Email port numbers, by default, are port 25 for sending and port 110 for receiving emails.
Retrieving emails using Telnet client (POP3)…
So if you wanted to check your incoming mail from your ISP you could type: –
open popmail.ispserver.com 110
You should then get a response code 220 followed by some server details, if your connection was successful and the server is available.
NOTE: Most servers will disconnect quite quickly if you do not submit a request.
To check your inbox you must then authenticate yourself. This is done using the USER command followed by your login name. Once you get an OK response from the server for the user name you must then enter your password with the PASS command. For example: –
user myemail@mydomain.com
Response comes back along the lines of +OK
pass mypassword
Response comes back along the lines of +OK
NOTE: Most basic telnet clients (including the Windows one) do not like it when you use the delete or backspace buttons. So if you miss-type a command you must re enter it, not just delete and type over. This is because the delete character is sent with the command rather than deleting the content you just typed.
Once connected there are several commands you can use, some are: –
LIST
This will show a list of all the emails in your inbox, often only showing the email ID and the size.
RETR +
Where + is the email ID number will retrieve an email (i.e RETR 1 will retrieve email id 1).
DELE +
Where + is the email ID number will delete an email (i.e DELE 1 will delete email id 1).
QUIT
Will close your connection to the server.
If there is a problem with a pop3 server running slow you can use the RETR command to demonstrate the download response of the server when collecting an email. It is not unusual for a pop3 server to slow considerably, it may be a hardware problem, it may be backing up to a backup device, it may even be a DoS (Denial of Service) attack against the server. When using the RETR command the response time is visible as you can see progressively how long it takes for the message to be received as each chunk of data is received and displayed.
Sending emails using Telnet client (SMTP)…
Similarly you can use telnet to check the availability of a clients SMTP server for sending emails.
From the telnet client type: –
open smtpmail.ispserver.com 25
You should get a 220 response message back.
Then you will need to declare where you are sending from, this should really be the fully qualified domain name as seen by the outside world. To do this you must use the HELO command (sometimes EHLO). For example: –
HELO mydomain.com
You should get a 250 response back.
This much tells you if your SMTP server is available.
It gets a bit more complicated if your SMTP server requires authentication, as you must first encode your username and password as Base64. There are some tools online that can do this (though I would never recommend supplying your username and password to one), as well as a few tools you can download.
In the example I use below the base64 encoding of the word username is dXNlcm5hbWU= and of the word password is cGFzc3dvcmQ=
If your SMTP server did require authentication and your username was username. Then the command would be: –
auth login dXNlcm5hbWU=
From which you should get a 334 response back asking for password, if your password was password you would simply respond.
cGFzc3dvcmQ=
From which you should get a 235 response.
Once connected, with ESMTP if required or without if not, you can test the ability to send messages. To send a message you must use the MAIL FROM command, the RCPT TO command and the DATA command. For example: –
MAIL FROM: myemail@mydomain.com
Response should come back as a 250 message.
RCPT TO: myrecipient@theirdomain.com
Response should come back as a 250 message.
DATA<press return>
Subject: My Test Email<press return>
<press return>
My test message goes here.<press return>
.<press return>
The final response you should get back is another 250 message saying it has been sent or queued.
Now obviously if you can send and receive emails with telnet and not your application, and you are certain the problem is not with your application then the cause of your original problem would more likely be some firewall or anti-virus software blocking your application.
Paul B
MCP
Paul Bunting • Software Architect 